Introduction to WAI-ARIA

Read on to learn how this specification works and how you should use it in your web accessibility processes to create and maintain an inclusive website experience.

What is WAI-ARIA?  

WAI-ARIA refers to the Web Accessibility Initiative – Accessible Rich Internet Applications. WAI-ARIA is a technical specification written by the World Wide Web Consortium (W3C). The specification is most commonly used by developers to build interactive website content that is accessible to people with disabilities.

Website owners can use the WAI-ARIA specification to ensure that interactive content meets WCAG success criteria. Interactive content includes commonly used widgets and web applications such as drag-and-drops, accordions, and sliders. While popular, the drawback of building a website using this type of content is that it can wreak havoc for people who use assistive technology to access your web pages. The result can be a website that is inoperable for people with certain types of disability.

So, what are these disabilities? WAI-ARIA’s target group is relatively narrow when compared to WCAG. It aims to increase website functionality for two groups in particular:

1. People with visual disabilities who use screen readers to access your web content
2. People who can’t operate a mouse and use speech instructions to control their devices

You should know that ARIA does not make dynamic website content accessible on its own – it is not an out-of-the-box accessibility solution. Instead, it outlines the steps required for making dynamic content and advanced user interface controls that have been developed with existing technologies – such as JavaScript, HTML, and Ajax – more recognizable to assistive technologies.

This is how it works: ARIA is the name of the set of attributes that can be inserted into your website’s HTML code to convey information about exactly how dynamic content should be understood by these assistive technologies and therefore, their users. For example, it might inform a screen reader that a widget should be interpreted as a slider. It supplements rather than replaces your website’s HTML code.

A key point to note is that the WAI-ARIA specification is primarily targeted at developers and is very technical. This means that while an understanding of WAI-ARIA is desirable for website managers, the actual implementation of ARIA should fall to those with specialist coding knowledge. 

What are the different WAI-ARIA versions?  

As of February 2021, there are two completed versions of WAI-ARIA:

• WAI-ARIA 1.0 was published as a completed W3C Recommendation in 2014.
• WAI-ARIA 1.1 was published as a completed W3C Recommendation in 2017.
• WAI-ARIA 1.2 is currently under development and will include multiple new features.

Should I be using WAI-ARIA?  

Whether you’re already using WAI-ARIA, or are still evaluating the merits of adding it to your website code, it is a good idea to consult W3C’s guide to ARIA use in HTML. In this document, W3C lists five simple rules for effectively implementing ARIA on your website:

1. Use native HTML features wherever possible. ARIA is not a replacement for HTML. Opt for semantic HTML that adheres to WCAG standards, except in the following cases:

• If the HTML element has no accessibility support. Stay updated on which HTML5 features currently enjoy accessibility support
• If the feature isn’t available natively in HTML. You can refer to this list for ARIA roles and properties not available in HTML
• If the design of an HTML element means it can’t be styled as required

2. Avoid changing HTML semantics. The default HTML semantics will almost always work best.

3. Ensure all interactive ARIA controls are navigable with a keyboard

4. Never use role="presentation" or aria-hidden="true" on a visible focusable element. This can lead to some of your website visitors focusing on nothing, leading to a poor user experience for screen reader users.

5. Give all interactive elements an accessible name. Achieve this by adding a value to the interactive element’s (<input>) accessible name property.

If you’re still uncertain about whether you should use ARIA, a good rule of thumb is to refer to rule one: only use ARIA when you absolutely need to. In most cases, HTML combined with user experience best practices allow your content to be accessible without using WAI-ARIA. Reserve ARIA for tackling accessibility issues that can’t be fixed with semantic HTML. Think of it as your last resort for filling these accessibility gaps.

Remember, the target group for ARIA is relatively small and it’s not a ‘one-size-fits-all’ accessibility solution, so you also need to consider additional ways of making all your website content inclusive.

How does ARIA work?

First; If you’re unsure about whether you’re already using ARIA on your website, check your HTML code for anything that begins with ‘aria-’, for example, aria-label. This is a sure sign that it’s already in place.

To understand what each ARIA attribute means, you will need to refer to the WAI-ARIA specification. There are three key components listed in the WAI-ARIA documentation: Roles, properties, and states. This is what they mean.

WAI-ARIA Roles

Describe what an element is or what it does. ARIA can define roles that are not available in HTML and can also override the default roles of HTML element. There are four categories of ARIA roles:

• Landmark. Helps assistive technology users navigate and identify different parts of a web page, e.g. banners, forms, applications.
• Document. Describes the structure of the web page’s content, rather than the whole page, e.g. headings, articles, lists, images.
• Widget. Describes (mainly) JavaScript-based user interfaces, e.g. checkboxes, buttons, alerts.
• Abstract. The role that other WAI-ARIA roles are built upon. Think of abstract roles as the foundations.

WAI-ARIA States 

Define the current status of an element, for example if it is busy, disabled, selected, or hidden. They are dynamic and can change on their own or as a result of a user interaction.   

WAI-ARIA Properties

Provide additional context or semantics to user interface elements not supported by standard HTML. They tend not to change once set.  

ARIA is supported by all the leading browsers and many assistive technologies.

How to make widgets accessible with ARIA

Widgets are interactive website elements that are created and controlled through scripts, such as JavaScript. Using certain widgets on your web pages can result in accessibility barriers for people with disabilities, specifically those who cannot see a screen. 

This is because there isn’t normally enough semantic information in the code to describe the widget’s form and function, which can lead to it being unrecognizable to assistive technologies.

Common examples of website widgets include:

• Sliders
• Checkboxes
• Radio groups
• Carousels
• Alerts
• Breadcrumbs
• Drop-down and fly-out menus
• Tree systems
• Drag-and-drop controls
• Auto-completing text boxes
• Dialog windows
• Tooltips
• Date pickers
• Window splitters

WAI-ARIA provides recommendations for enhancing the accessibility of your widgets by applying the relevant ARIA attributes. By adhering to the specification, developers can make otherwise inaccessible widgets accessible by adding descriptive, machine-readable ARIA attributes to a website’s code.

In practice, the ARIA role defines the purpose of the widget that isn’t available in HTML, for example, a slider. The properties then describe the characteristics of the widget, and the states describe the interaction state of the widget presently – such as if a checkbox has been ticked. When implemented correctly, ARIA attributes are recognized automatically by the website visitor’s browser and then interpreted by the visitor’s assistive technology.

WAI-ARIA and Siteimprove 

As a W3C-recommended specification for eliminating digital accessibility barriers, Siteimprove can help you scan your website for WAI-ARIA conformance.

When used incorrectly, WAI-ARIA can actually introduce accessibility barriers for your website visitors, so website managers should use Siteimprove Accessibility to regularly check that any existing or new WAI-ARIA attributes have been implemented correctly.