Just announced: Level Access and eSSENTIAL Accessibility agree to merge! Read more.

This is important.

There are 3 critical aspects of accessibility for interactive web technologies:

  1. Keyboard Accessibility
  2. Screen Reader Accessibility
  3. Cognitive Accessibility

With keyboard accessibility the concept is simple, if you cannot Tab to the feature, activate it in an intuitive manner such as pressing Enter on it, use Tab or the Arrow keys to navigate it, or use a simple means to close or invoke it from the keyboard, then the feature is not accessible.

For example, the following span tag is styled as a link, and a ‘click’ event has been added dynamically to make it act like a link when clicked:

< span class=”link”> Do something… </span>

So first, this is not keyboard accessible. To make it keyboard accessible you have to add tabindex like so:

< span tabindex=”0″ class=”link”> Do something… </span>

Now you can Tab to the span tag as you would with a link.

However, you cannot activate it by pressing Enter. This is because in the browser, a span tag is a ‘non-actionable’ element, unlike a button or an A tag for example, which you can expect to activate by pressing Enter when a ‘click’ event is attached.

To make this simulated link fully accessible from the keyboard, you have to attach both a ‘click’ and a ‘keyDown’ event to the tag in order to cover both mouse and keyboard interaction.

So now it’s accessible right? No actually, since screen reader users will have no idea that this element is supposed to be a link. To a screen reader this simply looks like static text in the page, as is every other span and div tag.

This is where ARIA comes in, which provides the right type of feedback for screen reader users.

In this case, the ARIA attribute role=”link” can be added to make this element accessible for screen readers that support ARIA, like so:

< span role=”link” tabindex=”0″ class=”link”> Do something… </span>

This is just a simple example to illustrate the point. I’ve recently submitted an issue for the Readium project at https://github.com/readium/readium/issues/166 which outlines all of these considerations and provides precise coding guidance for implementing simulated radio buttons. All of the above concepts are applied here as well.

This is very important when designing complex component types like sliders, which can be made keyboard accessible, but are useless to screen reader users without the use of ARIA at the same time. (e.g. http://whatsock.com/modules/aria_slider_module/demo.htm)

The last one, regarding cognitive accessibility, is making sure that the font-sizing, page format, coloration, layout and behaviors are as easy to understand and use as possible for all people. This also covers color contrast and low vision considerations.

So to summarize, to make an interactive web component fully accessible, it must be fully accessible from the keyboard, it must have proper textual equivalents for screen reader users, and it must be intuitive.

If you can only do one or two of these three things, the component is not accessible.

A few last notes about ARIA:

ARIA is awesome! Nevertheless, it doesn’t need to be used for everything.

For example, if you have an A tag with an href attribute, it is already a link, you don’t need to add role=”link”, etc.

The point here is that there are many backwards compatible ways to make standard component types fully accessible without using ARIA. ARIA should be used to bridge the gaps when it’s not possible to provide the same level of feedback for screen reader users as is conveyed visually.

Lastly, adding an ARIA role to an attribute doesn’t magically change the element type in the browser. This is very important to keep in mind.

A span tag for example, remains a span tag regardless whether you add role=”button” or role=”link” to it, and these attributes have absolutely no benefit to anyone who is not using a screen reader.