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 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.
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
<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.
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>
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.
Do not use
aria-hidden="true" on a visible, focusable element.
All interactive elements must have an accessible name.
<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.
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.
- WAI-ARIA basics on Mozilla Development Network
- A look into: ARIA web standards and HTML apps accessibility
- List of useful resources by Mozilla.
- List of design patterns and widgets giving examples of how WAI-ARIA can be used for each e.g. accordions.
- The WAI ARIA roles model.
- What is WAI-ARIA, what does it do for me, and what not?
- Easy ARIA tip #4 landmarks.
- Using WAI ARIA landmarks.
- From WAI-ARIA to HTML5 and back…or maybe not?
- Advanced ARIA tip #1: tabs in web apps.
- Easy ARIA tip #6: making clickables accessible.
- WAI-ARIA cheat sheet
- WAI-ARIA basics