Site Map



Accessibility of Learning Management Systems

Like many of the products we use every day, most learning management systems were not originally designed to work universally—to work for all users, regardless of ability. Though the situation is improving rapidly, there is still a considerable lack of understanding and applying the concepts of universal design during the development process in product design. Most often, developers make assumptions that include users can see the screen, the mouse is the main tool for navigation, visual alerts can be used as signals, and that skimming the screen in a random fashion will result in logical associations to facilitate easy, intuitive use of online learning environments. The fact that a blind person may be a student using online learning tools usually meets with surprise. Yes, blind students are trying diligently to use the same tools the sighted world takes for granted but usually with great difficulty.

Common Accessibility Issues with Learning Management Systems

Learning management systems (LMS) consist of various features that could cause accessibility problems for students and teachers with disabilities if they are not designed with accessibility in mind. Depending on the features enabled for a course, a student with a disability could find that participating independently and effectively is nearly impossible. Some LMS features are more problematic than others such as Quiz, Chat, or Wikis. The following table shows accessibility issues associated with commonly used features across various LMS's. All of these accessibility issues can be easily resolved if they are considered upfront or incorporated in design modifications. If you are an LMS product developer, we urge you to consult the Appendix section for practical Accessibility Design Considerations.

LMS Feature

Accessibility Issue

Assignments:

Allows teachers to collect work from students, review it and provide feedback including grades. Students can submit any digital content (files), including for example, word-processed documents, spreadsheets, images, audio and video clips. Assignments don't necessarily have to consist of file uploads. Alternatively, teachers can ask students to type directly into an online text assignment.

There are also an offline activity assignment which can be used to remind students of 'real-world' assignments they need to complete and to record grades for activities that don't have an online component.

  • If teachers include comments in the assignment in color or hidden text, these highlighted elements need to be 'exposed' so that assistive technology (AT) can discern and reveal it.
  • If multiple commentators annotate text, this needs to be differentiated so that AT can discern the different authors.
  • One way of submitting work is to download the assignment and upload the completed assignment. Friendly and accessible Upload/Download feature needs to be provided.
  • If "typing directly into the LMS" is required by the teacher, there is a very good chance that a "Filling out Forms" (see NOTE) issue will prevent accessibility. Friendly and accessible editing needs to be provided.
  • Identifying the state of assignments such as due date, status of assignments, e.g., if it has been submitted or not, if it has been reviewed or graded, or if any comments are associated with it needs to be available.

Blogs:

A form of online journal used by millions of people around the world for self-expression and communicating with family and friends. Blogs are usually organized as a chronological series of postings created by the author of the blog. Blogs usually are written by one person, although some blogs can be authored by groups of people.

  • Many blogs do not provide good heading structures to navigate from one blog entry to another and as a result screen reader users have a very hard time finding the next entry.
  • Accessible sorting and filtering options are missing from most blogs.

Chat:

Allows participants to have a real-time synchronous discussion via the web. This is a useful way to get a different understanding of each other and the topic being discussed – the mode of using a chat room is quite different from the asynchronous forums.

The Chat module contains a number of features for managing and reviewing chat discussions.

  • Following a chat thread in synchronous mode with multiple speakers is hard to follow. When the chat software continues to identify the 'speaker' by repeating the name in the thread, this translates into AT repeating this information and creates unnecessary overhead.
  • Identifying the speaker because of the speed of the flow can overwhelm a visually impaired student that results in not knowing who is 'speaking' in the thread. The faster the conversation proceeds, the more likely the visually impaired student will become lost.
  • Composing entries and reading is difficult simultaneously.
  • Scrolling through the messages and selecting or copying desired information is not possible.
  • Preference is audio chat---audio chat is easier to follow because of the identification process in spoken text; it's easier to know who is speaking.
  • Full duplex audio chat lets all participants speak at the same time and is more natural but large groups pose problems; even with this limitation, it is the preferred mode.
  • Half duplex allow only one person at a time to speak and is the second preferred mode of audio chat.
  • "Hands up" feature for speaking and in what order is difficult to access and handle. This feature needs to be accessible—an audio signal can indicate "hands up" and a "Speaker queue list" can show the order of speakers.

Choices:

The teacher asks a question and specifies a choice of multiple responses. It can be useful as a quick poll to stimulate thinking about a topic; to allow the class to vote on a direction for the course; or to gather research consent.

  • Answering and displaying results simultaneously causes a problem for tracking the progress of the poll.
  • Prefer to answer poll questions first and then show all results. Otherwise screen reader AT can get lost.
  • If images are used in the poll or response, then providing the alternative text for those images becomes essential. The alternative text needs to be extensive enough to allow the visually impaired student to see what the sighted students sees in order to be able to analyze what is being asked or portrayed.

Databases:

Allows teacher and/or students to build, display and search a bank of record entries about any conceivable topic. The format and structure of these entries can be almost unlimited, including images, files, URLs, numbers and text among other things.

  • Any informational graphical content needs to have an alt tag.
  • If data is displayed in tables, then column and row titles need to be provided.
  • Prefer ordered list for displaying search results similar to Google Search. If table used for displaying search results, then it needs to be made accessible.
  • If a returned result from a sort exercise turns out to be a chart, map, graph or something pictorial, it needs a text equivalent or accessible info.
  • If during a sort or after a sort, some of the fields or data are grayed out and cannot be accessed but you'd only know that visually, it should indicate somehow that the info is not available.
  • "Filling out Forms" issues could easily happen in this feature.

Forums:

Successful communication and community building; common area for students to come together and discuss unlimited topics, including social activities and educational ideas.

  • "Filling out Forms" issues are a potential problem along with being able to use sort, filter, and search features.

Glossaries:

Allows participants to create and maintain a list of definitions, like a dictionary.

  • If examples of definitions are in anything other than text, it could be problematic, i.e., screen shots for example
  • Pop-ups need to identify themselves as pop-ups and then how to return to the Glossary or document is needed.
  • "Filling out Forms" for entering new definitions could be an issue.

Lessons:

In a lesson page's simplest form, the student can select a continue button at the bottom of the page, which will send them to the next page in the lesson. Lesson can deliver content in interesting and flexible ways to each student, with no direct or time sensitive action required by the teacher once the lesson has been created. Each answer to a question may send the student to a different series of pages in the lesson. The teacher's response and the next page the student will see has already been thought out by the teacher.

  • When color is used to indicate what has been read or reviewed, it needs to be 'exposed' to the student through their AT.
  • Tab-style presentation of lessons that are not designed in an accessible way, making moving between pages difficult.

Quizzes:

Allows the teacher to design and set quizzes consisting of a large variety of Question types, among them multiple choice, true-false, and short answer questions. These questions are kept in the course Question bank and can be re-used within courses and between courses. Quizzes can allow multiple attempts. Each attempt is automatically marked, and the teacher can choose whether to give feedback and/or show the correct answers.

  • "Filling out Forms" can be a big issue here.
  • Navigation between questions is needed.
  • Lack of quiz instruction and redundent instruction make interaction with the quiz page difficult.
  • Lack of accessibility of different question types is a logistical nightmare; mechanics of answering questions becomes the focus rather than answering the questions.
  • Indicating question status inline with the question can improve the interaction with the page.
  • Getting lost happens easily.
  • Feedback after the answer attempt should indicate what new info is available and what you can do about it.
  • Timed quizzes are problematic for AT users…it just takes more time to complete a quiz.
  • Individually customized extended time would be preferred.

Resources:

Pdf documents must be created accessible. Scanned documents that become pdf's are NOT accessible—they are treated like images. Only tagged pdf documents are accessible to screen reader programs.

  • Required content...any video, picture, or graphics need to be made accessible.
  • Pdf documents must be created accessible. Scanned documents that become pdf's are NOT accessible—they are treated like images. Only tagged PDF documents are accessible to screen reader programs
  • When sending students to web pages, back and forth can easily turn into "I'm lost".
  • Provide reasonable alternatives to anything off the LMS site that could be inaccessible. If it's a media file, the flash player must be accessible; many are not.

Surveys:

Provides a number of verified survey instruments which have been found useful in assessing and stimulating learning in online environments. Teachers can use these to gather data from their students that will help them learn about their class and reflect on their own teaching.

  • "Filling out Forms" big issues here.

Wikis:

A collection of collaboratively authored web documents. Basically, a wiki page is a web page everyone in your class can create together, right in the browser, without needing to know HTML. A wiki starts with one front page. Each author can add other pages to the wiki by simply creating a link to a page that doesn't exist yet.

  • Very easy to create poor HTML markup resulting in inaccessible content. Wiki systems should block use of poor coding practices and provide a mechanism that can produce more accessible content by default.
  • Lack of keyboard support for formatting toolbar prevents keyboard users from utilizing the Wiki.
  • "Filling out Forms" can be a big issue here.
  • Keyboard users can significantly benefit from better navigation system.

Grade Book:

  • For students to be able to view their grades proper data table markup is essential.

Email:

  • Due to inaccessibility of web based e-mails, most people with disabilities prefer to use their own e-mail clients. Most LMS e-mail features are not accessible.

Technical Support:

  • If there is a 'Help' button, it should go to a specific topic relevant to the content area being explored.
  • "Accessibility" as a topic in an FAQ would help with error interpretation per feature.
  • Avoid images as explanations.

Training:

  • Always have a keyboard equivalent: for mouse users do this... keyboard users do that.
  • Simulations are generally not accessible and need to be keyboard accessible or have an alternative text based presentation.
  • For consistency sake, use the LMS to present training modules so there is reduced learning curve and cognitive load.

Self Enrollment:

  • 'Filling out Forms' issues. CAPTCHA security needs a non-visual way to achieve the entry of what is requested visually; a sample solution would be to type in phone number you're at and you will be called with a CAPTCHA code that can then be entered.

Personalization/Customization:

  • Students would rather state a preference about features rather than declaring a disability, i.e., "Would you see the screen better if the screen were magnified?"
  • Unessential images should not be displayed.
  • Extended quiz time needs to be an option based on an authorized disability.

Access offsite:

  • If a significant amount of on-screen reading is required, then the text should be made available in a downloadable single file.

Portfolios:

  • Any content added to a portfolio needs to be in an accessible format if more people than the disabled student is populating the portfolio.

NOTE: The "Filling out Forms" issue discussed in the table consists of at least two components or separate HTML elements: the input field and that field's label. A typical example of this is a text box in which a user is expected to enter a first name. If the text box is not properly "labeled", the visually impaired user cannot identify the purpose of the text box. Should he/she enter a first name, last name, or birth date? Images should never be used as labels (e.g. image of a telephone for the phone number field). Labels should be clearly identified using the "label" element.

Case Study: Cal State Universities

Due to the increasing awareness about institutional, state, and federal accessibility requirements, more and more educational institutions are requiring minimum accessibility standards in their RFPs for purchasing LMS's and do not rely on a company's accessibility statement or VPAT (Voluntary Accessibility Product Template). Instead external or internal reviewers are performing independent studies on accessibility of the product in question or they refer to already existing accessibility evaluations by other entities or peer institutions.

In the spring of 2008, the California State University Chancellor's Office issued an RFP for a Master Enabling Agreement (MAE) for Learning Management Systems to be used on the CSU campuses. Accessibility was one of the criteria used to evaluate the proposals. An independent accessibility evaluation was conducted on each of the five finalists bidding on the RFP.

http://www.calstate.edu/Accessibility/webaccessibility/evaluation/index.shtml

As a result of the accessibility evaluation, only two vendors, namely Moodle and Angel, were accepted and named in the Master Enabling Agreement (MAE). Desire2Learn and Blackboard did not pass the accessibility evaluation.
Note: Link to study no longer available on Cal State's website.

A new RFP was issued in October 2008 using the same accessibility requirements with the expected result to be published in Spring 2009. Due to a lack of internal resources, CSU decided to use an external company for the re-evaluation. Meantime, both Blackboard and Desire2Learn intensified their interaction with their respective accessibility collaboration groups, dedicated development resources, and tried aggressively to address the accessibility issues in some of the commonly used features. They partially redesigned them with the help of their accessibility collaboration partners (see below). This resulted in passing the CSU accessibility requirements and entering the Major Enabling Agreement.

Background on University of Illinois Collaboration Initiative

In 2004 the University of Illinois at Urbana/Champaign along with the University of Minnesota and Ohio State University started a collaborative approach to address accessibility issues at institutions of higher learning. This new and innovative way of addressing accessibility brought higher education specialists and commercial vendor product developers from WebCT, Blackboard, Desire2Learn, Ebsco Publishing, Ex Libris, and a few more to work collaboratively with the goal of improving accessibility. This group continues to promote the idea that the best place to address accessibility and usability is in the design process and not after the fact when the product is about to be released.

Survey Reveals the Experience

It is important to note that while the accessibility improvements in Blackboard and Desire2Learn resulted in re-entering the CSU Major Enabling Agreement, it does not mean that they are fully accessible and usable by students or teachers with disabilities. A December, 2008 study released by the American Foundation for the Blind, indicated the most important and necessary features of online educational tools presented significant problems for those using assistive technology such as screen reading or screen magnification software. Nearly one third of respondents who used assistive technology to access online educational tools reported the experience as unreliable/inconsistent or no successful use/access. Open ended questions gave respondents the opportunity to share their personal stories. In nearly every instance, respondents indicated features that were inaccessible. http://www.afb.org/Section.asp?SectionID=3&TopicID=138&DocumentID=4492