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:
It is recommended to test Javascripts using a combination of manual tests and tools.
The best way to manually test Javascripts is to use them with a screen reader, If that is not possible, simply using them with a keyboard will allow you to check that:
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.
Most tools are not useful for testing Javascripts, The ways in which JavaScript can modify a web document are almost limitless, and events can be used to dramatically change the operation and appearance of the content. Because of this, most automated tools are not very useful handle testing web documents that feature a lot of JavaScript.
Deque’s Worldspace Sync and the FireEyes plugin however, does test JavaScript-driven modifications to the DOM. Testers can structure use case tests that take advantage of this ability to test such DOM changes. Even with out building use cases, Deque’s Worldspace Sync and the FireEyes will pick up on many errors, such as: Clickable controls all have labels and widget roles, scripted widgets are focus enabled, widgets all have accessible name and role, roles match the states required, event handlers are device independent and numerous other 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 |
|
With... |
...add |
Mousedown |
Keydown |
Mouseup |
Keyup |
Click [1] |
keypress [2] |
Mouseover |
Focus |
Mouseout |
blur |
Notes :
1 The traditional JavaScript onClick event handler works with mouse click as well as keypress events. Although click is in principle a mouse event handler, most HTML and XHTML user agents process this event when the control is activated, regardless of whether it was activated with the mouse or the keyboard. In practice, therefore, it is not necessary to duplicate this event. It is included here for completeness since non-HTML user agents do have this issue.
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')"
onmouseout="swapImageOff('menu')" onblur="swapImageOff('menu')">
<img id="menu" src="menu_off.gif" alt="Menu" />
</a>
1. Use FireEyes to identify JavaScript event handlers that have mouse event handlers.
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.
While providing JavaScript events and keyboard actions to a simulated control make sure there is not a keyboard trap. The user should be able to navigate to the control, into it, interact with any actionable items within the new control, and leave that control – all while using the keyboard alone.
1. None
Note: Due to browser inconsistencies, test this with multiple browsers
People who have limited vision or those who are keyboard only users can make use of a visual focus indicator to track their location on the page. Some browsers do not provide this by default and when it is provided, it is often an outline of the focused object. In many cases – particularly cases where the control is an image or image-based icon/ button, it is best that the developer take additional steps to make sure focus is obvious. When JavaScript developers create new custom widgets on a page – particularly those which can be acted upon by users – one aspect often overlooked is providing visual feedback whenever the actionable item has focus from the keyboard. Visual feedback, if provided at all, often occurs when the mouse pointer is hovered over the item. This same visual feedback must be provided when focus occurs via keyboard
The tab order of a page is normally dictated by the location and order – within the document source – of the HTML controls and links on the page. When CSS and/ or JavaScript can be used to place objects anywhere on the page visually, sometimes the controls and links on the page appear in the tab order in a different order the user is expected to interact with them. A keyboard-only user will use the Tab key to move from one actionable item (such as links or form fields) to the next. If this order is different from the visual order of the page, the user will often not be able to easily interact with or understand the page. (Maybe imagine what it would be like to randomly reading links in a page out of order.) The tab order should to be the same as the visual order of the page, or at least logical and useful. The tabbing order must preserve meaning and operability.
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)
The onChange JavaScript event handler allows the author to change the page or other context when an item in a form is changed/updated and it’s use is often a sign that this checkpoint has been violated. When a form is submitted automatically without pressing the submit button, it can be confusing by users of some assistive technology. A screen reader user expects to push a button or link in order to submit the form. If it happens automatically, it can lead to a user incorrectly filling out the form, or not understanding that the form has been submitted. It can also cause a loss of focus and disorientation.
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.
Using the A element for links is strongly preferred over using elements such as DIV and SPAN, as the A element natively receives focus via both keyboard and mouse and would supply proper name and role information to assistive technologies. If you do use a DIV and SPAN as a link then you must use aria roles and states as needed, and set the keyboard focus using tabindex. Additionally, using a hypertext reference (href attribute) which points to a valid URI is also preferred. In this case, doing so means the link works with or without JavaScript support on the part of the user agent. In addition, the “#” symbol is used as a “fragment identifier separator”, which means its intended purpose within the href attribute is to precede a string of text which identifies a fragment within the page (a named anchor or an ID on the page). The use of “#” as the hypertext reference essentially means that the anchor points to nothing. In some browsers this may “point” to the entire document or to the top of the page and will cause an unexpected change in focus.
A <div> should not be represented as a link as is the case in the code that follows:
<div onClick=”location.href=’url’”>content</div>
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:
<div id=”style-this”>
<a href=”someurl”>content</a>
</div>
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.
Using JavaScript, it is possible to create items which appear and act like controls, widgets or even full applications. Some examples include select menus, tab panels, live regions. In many cases, developers will use JavaScript libraries such as UniformJS to replace existing form markup with scripted controls due to a desire to adhere to a specific visual design, as cross-platform CSS support for styling form controls is inconsistent. When custom scripts are preferred test that ARIA has been used correctly for role, state relationships properties and focus.
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.
JavaScript developers sometimes bind events to elements that are not typically able to receive focus, such as binding events to TH elements to create sortable tables. Because these elements are not actionable by default, they are also not placed in the tab order. The solution for such cases is to provide the tabindex attribute on the element. Using tabindex=”0” places the item in the tab order, while not altering the actual order of tabbing through other items on the page.
1. http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html
1. None
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.
When possible, interface widgets often created by JavaScript are should mimic standard controls – controls that the user is familiar with and know how to use.
For example, for checkboxes a spacebar or click event normally toggles selection. If the user has to press an arrow key to toggle the selection they will not know how to use it. :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.
Frequently, JavaScript is used to dynamically modify the presence of non-text content. One such example is an image or video carousel which either changes automatically or changes at a user’s request. If JavaScript is used to change such content, you must ensure any associated alternative text is also changed at the same time.
1. http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html
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
When using JavaScript to update or insert content into an HTML table, make sure the correct table structure is maintained.
1. http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html
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. http://www.w3.org/TR/wai-aria/states_and_properties#attrs_liveregions
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.
JavaScript developers often show and hide content in a document by dynamically manipulating CSS properties. If any content is intentionally hidden from sight, then it is important to make sure it is hidden from assistive technologies also. Doing so necessitates the use of display:none on the content to be hidden or aria-hidden or HTML5 hidden attribute.
1. http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html
1. None
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
1. None
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
1. None
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. http://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-required-behaviors.html
2. http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/SCR16
1. Web page that automatically logs the user out
On a Web page that has a time limit controlled by a script: