On modern websites, interface controls such as show/hide and controls to select personal preferences are very common. However, these types of features are often inaccessible to users who can’t use a mouse or an alternate pointing device — typically screen reader users.

A screen reader understands standard HTML code very well but interface controls (also called rich internet applications) are created using JavaScript or Ajax. These technologies have no standard way to tell another program, like a screen reader, what that behaviour is.

This is where ARIA (Accessible Rich Internet Applications) comes in. ARIA is used to give meaning, or semantics, to interface controls so a screen reader can use them. As we become more familiar with these kinds of interactive controls and start to expect them, these features become crucial for being able to use a website, so it’s extremely important that they are made accessible.

On the other hand, ARIA uses specific commands to tell assistive technology, such as screen readers, what’s going on. For example, if an event happens on a webpage such as an updated sports score, the assistive technology program being used to help a person with a disability will notice the change and provides the user with access to the new content.”

ARIA solves these main areas of accessibility problems with web applications:

Adding focus to any HTML element

The problem

Some Rich Internet Applications have content or functionality that cannot be accessed by assistive technologies. For example, most online forms for signing up to newsletters require the user to enter a correctly formatted email address. A validation error message is triggered if the email entered doesn’t fit the correct pattern. However, pop-ups like these may not be visible to a screen reader and so the user won’t know why they can’t complete the mailing list signup and that all they have to do is change the email address they entered.

The solution

When a keyboard user uses the Tab key to navigate through a webpage, usually a screen reader only stops on links and form elements. Using the previous example of an incorrectly formatted email error message, if the developer coded it as text instead of a link, a screen reader user couldn’t use the Tab key to get to it.

Using the extended ARIA tabindex property, any element can be placed in the tab order of the document and receive focus, and then a screen reader user can access them via the tab key.

ARIA thus allows far more access to different page elements by enabling them to receive focus.

Conclusion

ARIA improves the web for users with a disability, particularly screen reader users, by helping them understand the structure of sites so they can navigate them more effectively, allowing them to access previously hidden content by placing any element in a page’s tab order, gives users more control over dynamic content updates and makes widgets as accessible as normal page elements.

This is the last article in a four-part series by Richard Corby, co-founder and former partner at Webbism.