Using Shared Libraries

Use existing libraries wherever possible, and choose ones where the author has made a point to add accessibility: Don’t assume that just because a library on the whole cares about accessibility (as jQuery does) that all widgets written with that library and available for use have built-in accessibility. Very few, if any JavaScript libraries require accessibility in all of their shared modules. Check the accessibility of the widgets you are using; widgets that make an effort to be accessible will usually include information in their documentation about their accessibility features. Many JavaScript libraries have made some of the most basic widgets available in accessible versions.

Trigger events

Trigger events “onFocus” as well as “onHover”, to keypress events as well as mouseclick events, and to focus exiting and entering as well as hover entering and exiting. The former only pays attention to when the mouse is hovering over an element; the latter also recognizes keyboard focus, and allows keyboard navigation of your site. It is a very low effort way of making a huge improvement.

Fake page elements (e.g. buttons, links)

Ideally, you should be using native HTML elements (such as buttons, links, lists, etc.) instead of rolling your own wherever possible. If you must artificially create HTML elements using CSS and JavaScript, use WAI-ARIA roles in order to specify appropriate page elements. This way, screen readers, voice users, or keyboard-only users can access those page elements. In general, we should avoid creating a custom UI element (e.g. using div or span) if something built-in will work just as well and can be styled the way we need it to be (e.g. button). Adding accessibility to custom UI elements is always going to be more difficult than using the built-in accessibility of native HTML.

For example:

<span style="background-color: #ddd; border: medium outset white;"
role="button" tabindex="0"
onkeydown="if(event.keyCode==13 || event.keyCode==32) alert('You activated me with the keyboard');"

onclick="alert('You clicked me with the mouse');" >Push Me</span>

Without the WAI-ARIA attribute role=”button” and the HTML attribute tabindex=”0″, this button won’t be accessible to screen reader or keyboard users. role=”button” tells the browser to treat this span as if it were a button; tabindex=”0″ makes sure that it’s accessible via the keyboard (since under normal circumstances, a plain span would not be).

This video shows how difficult navigation becomes when the website relies on fake page elements without using the correct WAI-ARIA roles.

Capturing focus

Capturing focus into a search box on page load when there are other things someone with the keyboard might be doing, so any keyboard commands are instantly captured into the search box, ESPECIALLY if you don’t let the search box give it the focus. Similarly, capturing all keystrokes for your own keyboard built-ins, without any way to turn that off, so keyboard usage is impossible. (Rememberthemilk is an example of this — the site is actually completely unusable without a mouse, because there is no way to turn off the capture of all useful keystrokes.)

Dynamically updating pages

Use WAI-ARIA to tell screen reader users when the page is updating: Dynamic webpages often update sections of the page based on user events. It’s important to let users of screen readers, whose text-to speech engine might be reading them a section of the page far from automated update, know that the page has changed. There are WAI-ARIA roles to indicate the importance of a changed section, ranging from an urgent alert (e.g. “you typed your password wrong”) to an unimportant update (e.g. the clock changed on the top of the page). Section 4.7 has more details.</p>

More information:

Adobe Flash

Despite the problems Flash can introduce for screen reader users, there are techniques to make Flash content and navigation more accessible, such as text equivalents and keyboard accessibility. See WebAIM’s Creating Accessible Flash Content

Note: Because Flash is not supported on many mobile devices, the use of Flash should be limited to those circumstances where there is no alternative.