fully. Seek out and evaluate an LMS’s accessibility documentation to better understand its
features. Look for third-party accessibility reviews if you can find them, and be wary of the
statements of the developers or vendors of a particular LMS as your sole source for information.
Use your experiences and that of colleagues, the tips and tools contained here, and a review of
the e-learning environment you are choosing or currently using to help determine a system’s
accessibility to all your potential learners, authors, and instructors. This section highlights some
areas for your consideration when assessing the accessibility of your online courses or LMS.
For many learners, keyboard access is the only way they can navigate web content. For
example, a person who is blind will not likely ever use a mouse because s/he cannot see the
location of the mouse pointer on the screen. Some quick manual checks (such as those
described in this paper’s Testing Web Content Accessibility section) can be used to determine
whether all functional elements in your web-based courses are keyboard operable. If you find
elements you cannot access with a keyboard, or are unable to operate, look for alternate ways
to access these features; if none are available, you should avoid use of these features.
The students who rely on a keyboard to access web content will also need ways to navigate
within pages of the LMS. Strategies that can be used to provide within-page navigation include
using HTML heading markup (to represent topic structure and not to produce large bold font);
adding bypass links to skip over repetitive navigation elements or menus; and using ARIA
landmarks to identify key navigation points in the LMS’s interface.
Building on the instructions, stated earlier, for setting up the ChromeVox screen reader with the
Chrome web browser, you can list the headings on a page by pressing the assigned
ChromeVox modifier key + l + h (e.g., alt + l + h), then use the arrow keys to move between
headings. Similarly, you can press the modifier key + l + semi colon (alt + l + ;) to list the ARIA
landmarks on the page (e.g., set roles for regions such as banner, navigation, and search).
Some LMSs use bypass links to provide within-page navigation. They are normally found in the
top left corner of a page, and are often not visible but accessible when using a screen reader.
When followed, these links lead to key navigation points in the interface of the LMS, and
reposition the page so the user can continue navigating from that point. If you place your mouse
cursor in the location bar of your browser and press the Tab key repeatedly until the cursor
enters the content of the browser window, you can look at the status bar at the bottom of the
browser to check if the bypass links are present. You will see something such as “#content”
attached to the end of the web address (URL) that appears in the status bar. Notice the hash
mark “#” that indicates a link to a location within the current page. In some cases, bypass links
will become visible when they receive keyboard focus, depending on how they were created.
If your LMS does not provide at least one of these strategies to allow navigation within pages, it
will be difficult to use for some students using assistive technologies.
Logical Tab Order
For keyboard users, the Tab key is once again the main way they will move through web
content, pressing the key repeatedly to move through links, buttons, and form elements. A
common problem occurs when a particular link or button is clicked and a new window or
perhaps a dialog box opens that is not immediately keyboard accessible. Frequently after
opening a dialog box, the user has to press the Tab key repeatedly to reach the end of the
content underneath the box before reaching the content of the dialog itself. When the dialog box
is opened, the cursor should be focused in the box; when the box is closed, the cursor should
return to the location from which the dialog box was originally opened.
Another common problem occurs when the cursor’s path through the interface is not the usual
left to right and top to bottom. For those who may have magnified the screen and are navigating
by keyboard, the cursor can often move out of view. In this instance, when a system follows a
logical tab order, the user can usually predict the cursor’s location; however, when the system
does not follow a logical tab order, the user will have experience difficulty locating the cursor.
Many older learners or learners with poor vision will need to magnify the screen multiple times
to increase the size of text in order to be able to read. As a result, some elements may be
“pushed” off the visible screen. If these learners are using a keyboard to navigate and the focus
leaves the visible area, they will often scroll to bring hidden areas back into view and search for
the cursor’s location on the screen; if they cannot easily find the cursor, navigating web content
increases in difficulty. When navigating by keyboard, the process of following the cursor’s
location through elements on a web page should always be made as easy as possible.
The standard focus indicator is a dashed border that appears when an element receives
keyboard focus; while it is an acceptable focus indicator, it can be difficult to follow, even for
learners with good vision. To accommodate learners with poor vision, you should use a more
enhanced focus indicator that, for example, would apply a background color or perhaps a more
prominent border when elements receive focus.
Labelled Forms with Instructions
When using a screen reader to navigate through forms, the text nearest to the form element is
usually read if form elements have not been explicitly labelled using the HTML Label element.
This, however, is not always sufficient. For example, if forms are setup in a table, with text in
one cell and input fields in another, a screen reader will often announce “edit text” or something
similar, and not indicate the expected input described in the nearby text – unable to make the
association between the input field and the visually apparent, though separated label in an
adjacent table cell. Using the HTML Label element helps to ensure that form elements are
properly described, regardless of where their text labels might be located.
Another accessibility feature of the Label element is that it makes the label clickable. For some
people with motor impairments, positioning a mouse pointer over a tiny form element can be
difficult. Using a Label element provides a larger target area for the user to click on to activate
these form elements.
You can test for the presence of the Label element by clicking on the text next to a form field; if
the form field becomes active, the Label element is present.
In some cases, it would be helpful to provide text instructions in addition to a Label that
describes the expected input in more detail. A login name and password field in a registration
form is an example where additional information might be associated with form elements. In the
form’s input element, using the HTML “title” attribute, you might add title=“password must be at
least eight characters made up of numbers, letters, and special characters.” Although this
information is often found near a password field, it can go unnoticed by AT users. Explicitly
associating the information with the form input element using the title attribute ensures that all
users have access to the same information.
You can test for the existence of title text with most web browsers by holding a mouse pointer
over a form element and see if a small tooltip appears.
Feedback and error messages have been a challenge for developers to create accessibly and a
challenge for AT users to access. But with ARIA, feedback can be made accessible by simply
adding a role=“alert” attribute to the HTML element containing the feedback. The ARIA “alert”
role is a type of live region that, when updated, announces changes to assistive technologies. In
addition to presenting accessible error feedback, it also provides accessible success feedback,
letting the user know that s/he has successfully completed an action.
Without this feedback, AT users might not know whether errors have occurred or, conversely,
whether they have successfully completed a form. One past strategy to make feedback more
accessible was to locate it consistently at the top of the main content area, immediately
following the location of the #content bypass link (see this paper’s Within-Page Navigation
section). Assistive technology users could then predict where the feedback would appear and
jump directly to it when a page loads; however, this strategy does not work when feedback is
dynamically injected into a web page without reloading the page.
You can test for the existence of ARIA-enabled feedback using Chrome and ChromeVox. In
your LMS, generate an error message by, for example, filling out a form in the system and
leaving out a required field. If the feedback message is ARIA-enabled, ChromeVox will
announce the error automatically.
With the introduction of AccessForAll, there is now a standardized way to define personal
preferences that allow learners to modify the environment and the content to their specific
needs. (For more information on AccesForAll, see Accessibility in e-Learning: Standards and
Specifications.) Typical personalizations might include selecting a high-contrast display for a
person with limited vision, replacing visual elements with text alternatives for a person who is
blind, or adding captions to video for a person with a hearing impairment. Most LMSs have
some personal preference settings, though AccessForAll support is still fairly new and not yet
When evaluating an LMS, evaluate its preference settings. There should be a range of settings
to allow learners to personalize the environment to suit their needs, including:
● Font types and font sizes.
● Font colour and background colour.
● Navigation elements such as breadcrumbs, sequence links, and table of contents.
● Topic numbering to organize content numerically.
● Form focus for pages where the main content is a form.
● Ability to turn context sensitive help on and off.
● Choice of themes.
● Preferred content type (see AccessForAll).
The ATAG guidelines (see Accessibility in e-Learning: Standards and Specifications) provide a
standard way to implement authoring tools that will produce accessible content. The authoring
tool itself must first be accessible, conforming with the WCAG guidelines. It must provide a way
to add accessibility features, such as the ability to affix text alternatives when inserting images
into content. The tool should also alert authors if they are creating content that may not be
accessible. For example, if an image is saved without a text alternative, the authoring tool
should prompt the author to include one.
In a typical LMS, content can be created through a number of features, such as a content editor
for creating learning materials, a forum for communication, a news feature for posting
announcements, and assessment tools for producing tests and test questions. All these tools,
and others, must be able to produce accessible content.
To assess the authoring tools in an LMS, first determine if all the elements of the editor are
keyboard accessible. Place the cursor’s focus on an element in the editor, and then press the
Tab key and follow the cursor’s path; it should position itself in the toolbars across the top.
Press the Tab key repeatedly to be sure that all the buttons receive focus, and press the Enter
key to be sure that each button is operable (see Figure 3 for a typical editor interface).
Documents you may be interested
Documents you may be interested