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.
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.
| Device-dependent (mouse) |
Device-dependent (keyboard) |
Device-independent |
|---|---|---|
| onmouseover | onkeyup/onkeydown | onfocus; onblur |
| onmouseout | onchange; onselect | |
| onhover | onclick (use with form controls and "real" links only) |
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.
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.
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.)
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.
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.
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 programmatically focusable and can't be activated from a keyboard. In some browsers an empty href may cause programmatic 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 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 programmatic 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:
Test the you can navigate the page and all widgets using only the keyboard:
