Introduction to Aria

Nick Towers

For some, the word aria might summon up images of Pavarotti or Paul Potts, in the world of digital accessibility, however, it plays a different tune. aria provides a way to produce an accessible experience for users of all abilities, allowing developers to work towards WCAG compliance without compromising on the look and feel of their site.

What is ARIA?

Accessible Rich Internet Applications (ARIA, often written aria) is an international standard which defines a programmatic way to describe the structure, roles and behaviour of elements in a web application so that accessible technologies (such as JAWS or Dragon), can read the page, helping users understand and interact with the app consistently and clearly. As such, aria can play a vital role in ensuring that your site or app complies with the latest WCAG standards.

Though aria is designed to work with a range of web technologies, I’ll primarily be discussing websites written using HTML, in a browser such as Edge or Chrome.

One of the strengths of aria is that, while web technology and browsers advance, providing new ways for webpages to display and manage content, aria can provide a solid foundation, allowing accessible technologies to interface with familiar roles and attributes, which will allow for a much better consistency, particularly if using older versions of e.g. JAWS. This is not to say that the aria standard is out of date, the latest standard ARIA 1.2 was released in June 2023 and the latest draft version (1.3) was released in January of this year.

Limitations of ARIA

Though I’ve been singing the praises of aria, it’s still important to understand its limitations. aria can only provide hints, and - particularly on large, complex or poorly structured pages - it may not always be possible for accessible technology to understand all the necessary information required for a UI element, leading to unpredictable behaviour and inaccurate information, even with thorough and consistent use of aria.

This leads to the golden rule of accessible web design – use inbuilt HTML elements, it may not always be possible, depending on the project, but it will, in general, be easier to make a consistent and accessible solution than developing custom widgets. Standard HTML is going to be better supported by any browser than almost any bespoke widget, plus it makes it easier for accessible technologies to read and parse, even without aria. For example, using a standard button element will almost universally work for accessible technology users, using a styled div, on the other hand, will not be usable by out-of-the-box, it would need additional keyboard functionality, as well as a new aria role (more on that later) to even approximate the same level of accessibility and useability.

On the other end of the spectrum, it’s possible to overuse aria. There is a fine balance of providing enough information so that a user can understand and use the page effectively, but not too much that it ruins a user’s experience of a page, which can severely affect how – or even if – they will use your website.

The structure of ARIA

aria provides information to accessible technology in two main forms – roles and attributes, each of which can be used to customise the behaviour and output to best help the user.

An aria role describes the purpose of an element in the page, it not only refers to visual elements such as buttons and links, but also refers to the more structural elements of the page, such as a navigation bar, or even items in a list. Using aria roles, assistive technologies can tailor their behaviour depending on what a user might expect from the role, for example, in a table, a screen reader may help a user to navigate column by column and read out the column titles.

aria then divides these roles into six further categories, depending on the purposes of each role:

  1. Abstract roles – These roles are used just used to help build the logic of aria, and should never be used.
  2. Widget roles – These are used to describe elements which a user interacts with, such as a button or combo box.
  3. Document Structure roles – These are used to describe the structural elements of a page, including headings and tables.
  4. Landmark roles – Used to signify specific regions of a page, such as a list of site links or a page footer.
  5. Live region roles – areas of the page that may change or update automatically, such as an alert toast. Without this role, many users may be unaware of important changes in the page.
  6. Window roles – windows, such as confirmation dialogues which appear on the screen.

An aria attribute describes some state or property of an element. States, such as aria-checked, often reflect some frequently-changing state of an element. They can be particularly useful for screen readers, as states can often be indicated using some visual sign, and may not otherwise be obvious to the user. Properties, by contrast, are less likely to change, and can often reference a relationship to other elements. A very commonly used property is the aria-label attribute, which has been discussed in a previous blog.

Like roles, the aria specification has split attributes into 3 categories:

  1. Widget attributes – These describe the state interactive components, such as the checked status of a checkbox, or whether a text box is unavailable.
  2. Live region attributes – These attributes allow you to define elements of the page as live regions, and loosely determine which parts of the region are recognised as live.
  3. Relationship attributes – These describe how different elements may relate to each other, making it possible to link two, perhaps visually related, elements which aren’t necessarily near each other in the document structure.

There is a fourth category – Drag-and-Drop – which is in the process of being updated, and there are currently no applicable attributes.

Adding aria to HTML

If a site uses standard HTML (including button and input elements) as intended intended purpose, accessible technologies will be able to infer any relevant roles and attributes without the explicit use of aria, so it may not even be needed, especially for simpler sites. That said, it is always worth testing with relevant accessible technologies to make sure that they work as intended with your site.

Adding aria to HTML is simple. To add an aria role, you would need to add the property “role” to an element with the appropriate role name as the value, to add an aria attribute add the name of the attribute, using one of the the allowed values. In the simple button example below, the button has been given a “role” property with value “button”, and the attribute aria-label with value “click to test this button”. This is a simplified example, and there are better ways (such as providing the label as text inside the button) to make a button accessible, but this should demonstrate how easy adding aria to your site can be.

<button role="button" aria-label="click to test this
button"></button>

Conclusion

aria can be a powerful tool in ensuring site is WCAG compliant and is a vital part of any web designer’s arsenal, but, like many tools, it’s easy to use, but hard to master. Too little aria can lead to confused users, who may not harm than good. Too little aria can lead to confused users, who may not even be able to use even the most basic parts of your app, overuse can ruin the user experience, sometimes leading to more confusion than if it hadn’t been used in the first place. Striking the fine balance between the two can sometimes require a lot of trial and error, but the results are often well worth the effort.

If you need help in making sure your site is WCAG compliant, need help with your accessibility infrastructure, or have any other questions, feel free to contact us.