Making web pages more accessible with WAI-ARIA

Thursday 1 December 2016

We are currently reviewing the elements of our digital pattern library to ensure they are accessible. By ‘accessible’ we mean do our patterns work for disabled users who are using assistive technology such as screen readers?

The following article gives an overview of WAI-ARIA and how it can be used with HTML to make web content and web applications more accessible. A future blog post will give detailed examples of how we are using WAI-ARIA to make our patterns more accessible.

The Web Accessibility Initiative – Accessible Rich Internet Application (WAI-ARIA) defines a way to make web content and web applications (especially those developed with Ajax and JavaScript) more accessible to people with disabilities. In March 2014 WAI-ARIA 1.0 became a World Wide Web Consortium (W3C) recommendation, which means that it became an official web standard.

The syntax of HTML doesn’t always allow developers to describe elements properly, to identify their roles, and specify the relationships between them. This can impede assistive technology users from understanding what is happening on the screen and exploring their options. This is where WAI-ARIA helps using:

landmark roles to define the purpose of elements.
aria-* attributes to describe the nature of elements.

Aria-prefixed attributes have two types: properties that describe features less likely to change throughout the page life-cycle, and states that provide information about things that may frequently change due to user interaction.

WAI-ARIA is implemented in most popular browsers and screen readers, but adding WAI-ARIA roles and attributes to HTML is complex. The following is a summary of recommendations on the use of WAI-ARIA in HTML.

Rules of WAI-ARIA use in HTML

The following is an extract from using WAI-ARIA in HTML.

Rule one

If you can, use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

There are a few circumstances where this may not be possible.

If the feature is available in HTML but it is not implemented or it is implemented, but accessibility support is not.
If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.
If the feature is not currently available in HTML.

For example, if HTML5 semantic tags such as <button> or <form> are used, modern web browsers add the appropriate ARIA semantics by default. In this case, there is no need to add the ARIA landmark roles separately.

If there is already a hidden HTML attribute to a form input, it is unnecessary to add the aria-hidden state as the browser includes it by default.

Rule two

Do not change native semantics, unless you really have to.

For example: developer wants to build a heading that’s a button.

Do not do this:
<h1 role=button >heading button</h1>
Do this:
<h1><button>heading button</button></h1>

Rule three

All interactive WAI-ARIA controls must be usable with the keyboard.

If you create a widget with which a user can interact (click, tap, drag, drop, slide or scroll) a user must also be able to navigate to the widget and perform an equivalent action using the keyboard.

All interactive widgets must be scripted to respond to standard key strokes or key stroke combinations where applicable.

For example, if using role="button" the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS) or return (MAC OS) and the space key.

Rule four

Do not use role="presentation" or aria-hidden="true" on a visible, focusable element.

Rule five

All interactive elements must have an accessible name.

For example: <label for="username">user name</label> <input type="text" id="username">

What does adding a role do to the native semantics?

Adding a WAI-ARIA role overrides the native role semantics in the accessibility tree which is reported via the accessibility API, and therefore ARIA indirectly affects what is reported to a screen reader or other assistive technology.

Adding a WAI-ARIA role will not make an element look or act differently for people not using assistive technology. It does not change the behaviours, states and properties of the host element but only the native role semantics.

WAI-ARIA validation

The easiest method is to use HTML5 doctype with ARIA markup and validate using the W3C Nu Markup Checker. Note the checker is a work in progress.