Using ARIA to Increase Digital Accessibility

In our modern world, as society evolves, more people rely on technology at home, at school education, and at work. Meanwhile, according to the World Health Organization, around 15% of the world’s population lives with some form of disability.

“For most people, technology makes things easier. For people with disabilities, technology makes things possible.” —Mary Pat Radabaugh, Director of IBM National Support Center for Persons with Disabilities.

To access and interact with digital products and software, like websites and applications, people with disabilities use assistive technology, including screen readers. A screen reader is an assistive technology that helps blind and visually impaired people use a digital product by converting text and images to speech. Namely, people who cannot see screens, access information on computers and phones by using screen readers to help them.

As many people rely on screen readers to use their computers and mobile devices, it’s essential for companies—and their developers—to keep this in mind to ensure they meet digital accessibility requirements and have an inclusive product.

In order for assistive technologies like screen readers to extract information and convert it to speech, they look to semantic HTML elements for help. However, when native HTML cannot manage accessibility issues, ARIA is there to assist and bridge the gap. But what is ARIA and why is it important for accessibility? Let’s find out.

What is ARIA?

ARIA—Accessible Rich Internet Applications—is a set of roles and attributes that define how websites and applications can be more accessible and usable for people with disabilities. They can be added to HTML elements and can be used in many different ways to make sure that users with disabilities who rely on assistive technologies can easily access the information they need.

Why is ARIA important?

ARIA is essential to making sure all users can access websites and applications. And having a well-implemented ARIA will ensure that assistive technologies can successfully extract and convert information. In doing so, companies can rest assured they are providing an equal experience to all their users as well as following accessibility rules and regulations.

Using ARIA to write HTML code for screen readers

Screen readers convert semantic information about elements from the HTML code and this is where ARIA is useful for developers. Specifically, ARIA is an extension of HTML that provides enhanced accessibility for end-users. It provides screen reader users with greater context and interactivity with the content. Adding ARIA to your HTML elements is one of the best HTML accessibility practices. But at the same time, you should be mindful of the first rule of using ARIA as recommended by W3C (World Wide Web Consortium):

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

So, should you use ARIA or not? The answer is simple—it is a balancing act. Native elements have rich semantics of their own. ARIA should be applied when native HTML cannot solve accessibility issues. For example, complex web controls that couple together or web page content that changes. ARIA tags help inform screen reader users about the relationships between elements and changes in content so using them in such cases is advised.

Examples of recommended practices for ARIA use

As mentioned above, native HTML elements, if handled properly, have implicit semantics, including the properties they will have. For example, using the <select> tag provides the following information about the element:

Role: pop-up button
Name: defined name of the drop-down list
State: collapsed/expanded
Value: default or currently selected item

Screen reader users get all this information, and if an action performed, the accessibility tree is updated. Developers do not have to worry about focus, native interactive elements are automatically focusable without adding the tabindex attribute. Moreover, keywords in native elements are more discoverable by customers than keywords in non-semantic elements like <div> tags.

No ARIA is better than bad ARIA

It is important to understand that sometimes poor ARIA implementation can cause more problems than it can solve, making the content less accessible. This can happen because of a lack of knowledge of how and when to use ARIA. In any case, this is not a reason to abandon such a valuable tool—you only have to understand the basics of using ARIA before implementing it in your product.

Developers should use WAI-ARIA carefully and steer clear of the following mistakes:

Avoid redundancy. For example, if you use the <button> element, you do not need to add in the attribute role="button". The addition of the role does nothing since the role is already explicitly defined by the HTML code.
Using an invalid role-attribute combination. For example, if a developer assigns the ARIA attribute aria-selected=”true” to a link element, the property will not be announced by a screen reader because they are not combined.

Incorrect WAI-ARIA syntax. There are several examples of incorrect syntax usage, including:
- Roles are created in upper case (e.g., role=”LINK”). Since roles are case-sensitive, they should only be created in lowercase letters.
- ARIA attributes are misspelled (e.g., “aria-lable” instead of “aria-label”) or invalid (e.g., role=”error”). Correctly written and current ARIA attributes should be applied as defined in the WAI-ARIA 1.1 W3C recommendation. Otherwise, the attribute will not perform the accessibility function.
- Incorrect role declarations. Using aria-role=”” instead of role=”” is another common mistake. Screen readers cannot recognize such an element.

When is the use of ARIA justified?

There are some reasons why developers should use ARIA attributes and include them in their products.

Using an aria-label to provide alternative text to form controls that do not have text labels. For example, a shopping cart icon without a text label. Adding an ARIA label provides screen reader users with information about the name of an element.
ARIA can express semantics and UI patterns that do not yet exist in HTML. For instance:
Setting role="alert", aria-live="assertive", or aria-atomic="true" to communicate an update message that requires immediate attention from a user (an invalid value entered in a form field, the user login session is about to expire, etc.).
Using role=tree to create a tree widget with child elements. It is only possible with ARIA as there is no tree tag in native HTML.
If custom controls are created to have a different role and/or function than usual, then ARIA must be used to provide information for assistive technologies about the role, property, and state of the element, and the tabindex attribute must be added to include an interactive element to the sequential tab order.
ARIA attributes are essential when there is additional functionality added to native elements. For example, if a link or button has a hidden submenu, the aria-haspopup attribute would provide assistive technologies with a hint that the submenu exists. Without this particular attribute, users who rely on assistive technologies would not receive this information.
Using the aria-describedby attribute to add description text available only to assistive technology. For example, providing extra text for a screen reader when the link text is not descriptive enough.

Key takeaways

Assistive technologies are an important part of making digital content accessible to people with various disabilities, either temporary or permanent. For assistive technologies, like screen readers, to extract information and convert it to speech, developers should consider adding accessibility information to HTML elements using the ARIA specification.

Using ARIA roles and attributes in complex site structures is highly recommended, especially if any of these statements is relevant to you:

There are custom controls created to give them additional functionality on your website.
The elements on your website are more complex than just parent-child relationships.
There are dynamically changing parts of the page that change over time or through user interaction.

To make your product more accessible to more people by adding ARIA attributes where needed, make sure you are familiar with WAI-ARIA practices and follow the rules. If you’re not too sure about the correct usage of ARIA or need help improving accessibility and meeting accessibility standards, we strongly suggest working with quality assurance experts who have experience with accessibility testing and the latest accessibility guidelines.