Accessible Javascript

Basics

• Use device-independent event handlers.
• Limit the use of popup windows.
• Ensure there are no keyboard traps on the page.
• Don't use empty links.
• Use ARIA roles, properties and states to describe the type and state of a widget; to alert users to dynamic content and error messages; and to give elements keyboard focus.

In depth

Because almost all assistive devices support it and 99% of assistive device users have it enabled, WCAG 2.0 allows you to require Javascript.  However, the scripted content or interactions must be compliant with the guidelines.

Ensure that Javascript is fully accessible--that is, the functionality of the script is device independent (can be accessed via both mouse and keyboard) and all information is available to assistive technologies.

Device-independent event handlers

To ensure accessibility, use either a device-independent event handler (one that works with both the mouse and the keyboard) or use both mouse- and keyboard-dependent event handlers.

Javascript event handlers

 

onMouseOver and onMouseOut

If onMouseOver and onMouseOut presents additional information or content, such as a tooltip, these must also be made accessible to keyboard-only users.  In addition to or instead of onMouseOver and onMouseOut, use onFocus and onBlur, which are are device-independent event handlers.

onClick

Only use onClick event handlers with keyboard-navigable (real) links and form controls.  The "link" below is not really a link, can't receive programmatic focus, and is not keyboard accessible.

<p onclick="javascript:location.href='https://www.asu.edu';">Learn more...</p>

When a click is required, make sure it works with the keyboard (Enter or Return key), as well as with a mouse.  For non-link and non-control elements, the Enter key may not always trigger an onClick event.  In those cases, you'll need to detect the Enter and Space keypresses while focus is placed on them.

Pop-up windows

Limit the use of pop-up windows.  For people using assistive devices, pop ups can be confusing and difficult to navigate.  If pop ups are necessary, use aria-roles to identify the widget so an assistive device knows how to deal with it.  (See more in the WAI-ARIA best practices.)

Keyboard traps

Ensure there are no keyboard traps on the page.  Keyboard traps occur when focus becomes trapped somewhere within the screen, most often due to Javascript onBlur, onChange, onFocus or other focus issues.

• If an event handler opens a window, make sure you can use the keyboard to close the window and return focus to the trigger.
• For drop-down menus, ensure you can navigate and exit the menu with just the keyboard.

noscript

The noscript element can provide an accessible alternative for Javascript-generated content, but it is not a substitute for making a webpage or application accessible. Nearly 99% of screen reader users have Javascript enabled, so for them, it's vitally important that the page or application itself is accessible.

Empty links

Sometimes developers use "empty" links to attach JavaScript event handlers—for example: <a href="#">Do something</a>  Links without hrefs are very confusing for people using screen readers or keyboard navigation because empty links aren't programmtically focusable and can't be activated from a keyboard.  In some browsers an empty href may cause programmtic focus to shift to the top of the page.

Instead of an anchor, use the button element. Alternately, identify the anchor element as a button by adding the ARIA role=button. (See more about WAI-ARIA.)

Example:

<button>Degrees</button>

<a href="#" role="button">Degrees</a>

ARIA roles, properties and states

ARIA allows developers to add information about otherwise static HTML5 elements.  With ARIA, elements can have roles, properties and states.  In addition, tabindex or ARIA roles can give programmtic focus to previously unfocusable elements.  Users can be alerted to dynamic content changes, such as error messages, by defining ARIA live regions. See more detail on the WAI-ARIA best practices page.

ARIA is a powerful addition to HTML5 and can make even complex web applications accessible.  For more information on the full range of enhancements available with WAI-ARIA, see:

• Accessible Rich Internet Applications (WAI-ARIA) 1.1 (the specs)
• WAI-ARIA Overview
• WAI-ARIA Authoring Practices 1.1
• ARIA Techniques for WCAG 2.0

How to test

Test the you can navigate the page and all widgets using only the keyboard:

1. Click the address bar in your browser, to set the cursor there.
2. Begin tabbing through the page ensuring that:
   • You can navigate to every link, form control and button in logical order.
   • Each element you tab to visibly displays focus.
   • You can view all tooltips and navigate all tabs, popup windows, slideshows, carousels, menus and other widgets and features.

Relevant W3C WAI documents

• WCAG 2.1 Guideline 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
• How to Meet WCAG 2.1 Guideline 1.3.1

• WCAG 2.1 Guideline 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
• How to Meet WCAG 2.1 Guideline 2.1.1

• WCAG 2.1 Guideline 2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
• How to Meet WCAG 2.1 Guideline 2.1.2

• WCAG 2.1 Guideline 2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
• How to Meet WCAG 2.1 Guideline 2.4.3

• WCAG 2.1 Guideline 3.2.1 On Focus: When any component receives focus, it does not initiate a change of context.
• How to Meet WCAG 2.1 Guideline 3.2.1

• WCAG 2.1 Guideline 3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
• How to Meet WCAG 2.1 Guideline 3.2.2

• WCAG 2.1 Guideline 3.3.1 — If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
• How to Meet WCAG 2.1 Guideline 3.3.1

• WCAG 2.1 Guideline 3.3.2 — Labels or instructions are provided when content requires user input. (Level A)
• How to Meet WCAG 2.1 Guideline 3.3.2

• WCAG 2.1 Guideline 3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.
• How to Meet WCAG 2.1 Guideline 3.3.3

• WCAG 2.1 Guideline 4.1.2 — Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)
• How to Meet WCAG 2.1 Guideline 4.1.2