This chapter discuses problems of accessibility with Java scrip and basic testing techniques
As discussed in the chapter on ARIA, scripting often causes accessibility problems when does not convey the information necessary to convey name, state, role, and value information and other properties to assistive technologies. In simple terms assistive technology needs to know:
With a screen reader you can also check that things are understandable, such as:
If you are not using a screen reader will need to check this via the code , via a tools that tracks the DOM (document object model).
More details on many of these tests is given in the following section on detailed tests.
Although not every possible variation is testable, Deque’s Worldspace Sync and the FireEyes plugin tests are an import part of Java script testing. More on use of these tools are available via the the Worldspace tutorial and documentation.
To run tests via FireEyes
Device-dependent events are those events that require the user to have any specific input device, such as a mouse. In this case, use additional event handlers that are triggered via the keyboard.
For example, a script may perform the same action when a keypress is detected that is performed when a mouse button is clicked.
Often it is possible for developers to provide event bindings that do not require the use of a specific device or to duplicate the even in a device independent way. For instance, instead of using events to respond to mouse movements such as mouseover or hover, the developer can use on focus or blur. Doing so would enable the interface to respond to the users actions regardless of whether or not they use the mouse.
The following table suggests keyboard event handlers to be used with mouse event handlers.
Additional keyboard event handlers
2 Since the keypress event handler reacts to any key, the event handler function should check first to ensure the Enter key was pressed before proceeding to handle the event. Otherwise, the event handler will run each time the user presses any key, even the tab key to leave the control, and this is usually not desirable.
3 Some mouse-specific functions (such as dblclick and mouseover) do not have a corresponding keyboard-specific function. This means that some functions may need to be implemented differently for each device (for example, including a series of buttons to execute, via keyboard, the equivalent mouse-specific functions implemented).
<a href="menu.php" onmouseover="swapImageOn('menu')" onfocus="swapImageOn('menu')"
<img id="menu" src="menu_off.gif" alt="Menu" />
2. Look for messages such as: Ensure any IMPORTANT functionality offered by this event handler is also available by keyboard alone. (put away your mouse, and try to activate this event with your keyboard alone).
1. Test using the keyboard only.
2. Make sure everything that is accessible to the mouse user is also accessible to the keyboard user.
a. Search for mousedown and mouseup events. Everything that is clickable with the mouse should be executable by the keyboard.
b. Onmouseover events should also have an onfocus event
c. Onmouseout events should also have an onblur event.
Note: Due to browser inconsistencies, test this with multiple browsers
In a related issue, sometimes the visual focus is the not same as the programmatic focus. This case the user will select a control while trying to select a different control. This is more likely to happen on complex widgets such as a tree of interactive controls, the user can use the up and down arrow keys to move from tree node to tree node but the highlighted focus could be out of sync.
Note that good use of tabindex, and aria-flowto and aria-activedescendant can correct these issues without requiring the author rewrite the page.
1. (test 4a) Tab through the page and make sure the tab order follows the visual reading order.
When it is not the same, make sure it is logical, and just as usable as the visual order.
2. (test 4b) Navigate through all the focusable elements on the page by using the tab key. Check that the status bar is pointing to the correct href or event that correlates to the focused item.
User interactions must not automatically cause a Change of Context unless the user has been told what is likely to happen before they use the component. Note: a change on content is not the same as a change of context. A change of context includes a new window, focus or view port. (WCAG 3.2.2)
Screen readers follow the content of the page one line at a time. If focus is moved unexpectedly, the user can find they are reading a completely different area of the page. Any change of focus that happens on a page must be the result of an action initiated by the user
1. Phone number and SSN field sets which automatically tab to the next field
Often using custom widgets gives no visual or functional advantage. In this case it is safer and simpler to use HTML widgets that already have full accessibility features built in.
A <div> should not be represented as a link as is the case in the code that follows:
Instead, you can use a <div> tag to either surround the anchor if you need additional control for styling the element as the following code illustrates:
In this section we will describe tests for custom widgets.
We will need to test:
Note: It is always advisable to test for custom widgets is always to use then with a screen reader and fulfill specific tasks without use of a mouse or screen.
As discussed in the chapter on ARIA, The typical screen reader user must start reading at the top left of a page and continue line by line until the bottom right is reached. The ARIA landmark provide a simple means for users of assistive technology to navigate though different sections of page content . ARIA Landmarks are a good substitute for skip links, and allow the user to skip not just over repetitive navigation but to move directly to the various parts of a web page.
<div id="nav" role="navigation"> Navigation Area </div>
<div id="main_content" role="main"> Main Content Area <div id="second_content" role="complementary"> Complementary Content Area </div>
<div id="footer" role="contentinfo"> Content Info/Footer Area </div>
WAI-ARIA describes how to add semantics and other metadata to HTML content in order to make user interface controls and dynamic content more accessible. For example, with WAI-ARIA it is possible to identify a list of links as a navigation menu and to state whether it is expanded or collapsed. WAI-ARIA provides a framework for adding attributes to identify features for user interaction, how they relate to each other, and their current state.
Learning to identify when ARIA states and widget roles could help is a useful part of accessibility testing. Note this test should be used with the Aria landmarks tests and with the other aria tests, to make sure aria is used properly.
Test the control with a screen reader, and using the control will test not only that the correct role, properties and states were set initially but also that the aria states change as the user changes the value of the control.
Note that often using small custom widgets gives no visual or functional advantage. In this case it is safer and simpler to use HTML widgets that already have full accessibility features built in. When possible, use the native HTML element rather than simulated controls. The native HTML elements already have built in the keyboard accessibility, screen reader compatibility, screen magnifiers, etc.
Whenever new content or widget appears on the page as a result of the user activating a control (such as a popup modal dialog window), the interaction flow must be circular so that the user returns to the place from which the interaction first started. Users without disabilities naturally continue their interaction where they left off. You need to check that users with disabilities have the same interaction and that focus is shifted back to the point where their interaction started.
When it comes to keyboard accessibility and focus control, users must able to interact with the system without being required to use a mouse because they may be either unable to see the mouse pointer or may lack the fine motor control necessary to use a mouse. Interfaces which rely on client-side scripting need to make sure interactivity from such an interface can be performed using the keyboard. Things such as simulated dialogs, simulated calendar controls, drag-and-drop interfaces, must be accessible via the keyboard and users must deal with the open them, operate them using a keyboard only
For complex widgets also see test 14 below.
For additional examples see http://test.cita.uiuc.edu/aria/radio/
For global widget design patterns see http://www.w3.org/TR/wai-aria-practices/#aria_ex_widget
List of global widget patterns for best practices.
Reference (WCAG 2.1.1 A, WCAG 2.1.3 AAA)
For global widget design patterns see http://www.w3.org/TR/wai-aria-practices/#aria_ex_widget
The following tests are for accessibility issues that frequently occur in scripted widgets. Although they relate to standard accessibility issues, they are useful to review in the context of scripts as well.
A sighted person can easily comprehend the relationships and purpose of a cell in a table by following the column up and/or a row sideways to a bolder header. People who use screen readers make use of the HTML TH to understand the relationships of each cell, such as what row and column header it is under
1. An automated train schedule that inserts new rows into a table as a new row each hour.
Automatic content changes can often be disruptive to assistive technologies or may require additional time to access and consume the information. Use aria-live to indicate that content changes may occur without the element having focus, and to provide assistive with information on how to process those content updates.
1. Navigate to the unit being tested.
2. Press the ‘Now’ button on FireEyes
3. Look for errors concerning ARIA, live regions or "Timing or Timers".
1. Look at each live region in the page. Check that the attribute is set if the region may change content. Check that it is set to "polite" UNLESS the new content has the highest priority and the user needs to know about it immediately.
Without accessible error messaging, people with disabilities may not be able to complete the form or may complete it incorrectly. Error messages, though they may be rendered in close proximity to the controls that failed validation, may not be read aloud by screen readers.
Accessible error messaging can be by utilize WAI-ARIA alert property and aria-describedby to associate the error messages with their appropriate controls.
1. A form with input validation
Unless the error message is accessible, the user of assistive technology may not be able to fill out the form, or may fill it out incorrectly. The error should be clearly identified, quick access to the problematic element should be provided, and user is allowed to easily fix the error and resubmit the form.
If an input error is detected, provide suggestions for fixing the input in a timely and accessible manner. Doing so increases efficiency and greatly increases the success of users with disabilities.
1. A form that uses validation
Users with disabilities such as visual impairments, motor impairments, or cognitive impairments may require more time to consume content or complete interactions within websites. In cases where systems require the user to complete interactions within a specified period of time, that time limit may be less time than the user needs. To handle time limits accessibly, one or more of the following approaches should be employed:
1. Give the user the ability to turn off the time limit entirely
2. Provide a user-configurable setting for how long the time limit will be (such as in the user’s profile)
3. Provide an alert that the time limit is about to expire and supply a means for the user to extend that time
Note: Certain exceptions to these requirements apply – namely for events which are real-time occurrences (such as online auctions) or where the time limit is essential to the activity. WCAG also provides an exception in cases where the time limit is longer than 20 hours
1. Web page that automatically logs the user out
On a Web page that has a time limit controlled by a script: