Avoiding Redundancy with WAI-ARIA in HTML Pages

Share this article

Life’s been easy since we’ve started integrating ARIA roles in HTML code. ARIA has been providing additional semantics to help assistive technologies (ATs) and making it possible for developers to enhance the usability of web applications for people with disabilities. The fundamental question remains to date — do HTML elements need ARIA role attributes to expose their semantics?

In this article, I will cover this subject along with the new HTML5 structural elements with default implicit semantics that contest ARIA roles.

ARIA Basics and General Perceptions

WAI-ARIA (commonly known as ARIA) is a set of attributes that you can add to your HTML elements. The purpose of these attributes is simple — to communicate role, property, and state semantics to ATs by means of accessibility APIs that are present in web browsers. Stephan’s post An Introduction to WAI-ARIA is a must-read for those of you who are new to ARIA.

The general perception about ARIA in the HTML community is “don’t use ARIA code if HTML has got you covered”. The same thing can be said a little more clearly: If your HTML element is already implemented but does not have accessibility support yet, use ARIA.

Effect of ARIA Roles on Most Elements

There are some general cases in which the semantics of an HTML element can be exposed by use of an ARIA role, property, or state. A bit perplexing at first, this is known in the HTML community as the HTML element’s default implicit ARIA semantics.

However, when coding in HTML it is best to write semantically correct HTML (and thus make use of its native semantics) before setting out to integrate ARIA attributes.

ARIA roles do not add anything to the default semantics of most HTML elements.

The rule is to keep it simple — if the semantics are included in the HTML element by default then do not use ARIA. Integrating ARIA where it isn’t necessary makes for redundant code.

Does HTML4 Need ARIA Roles?

As explained by accessibility expert Steve Faulkner, all of the HTML elements that were defined in HTML4 (and earlier HTML versions) do not require ARIA roles added to uncover their default semantics because they have already been mapped.

In fact, using ARIA roles in such situations and with elements defined in HTML4 will not make a difference. If ARIA roles are used in HTML4-based code, this will necessitate extra work by you by someone reviewing your code. Therefore, it is generally advisable to not add ARIA roles to HTML elements if it can be avoided.

New Features in HTML5

According to the HTML5 Specification:

In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser.

This means that new features that have been defined in HTML5 have default implicit ARIA semantics exposed by most web browsers. Despite this fact, it cannot be assumed that the HTML element you’re using is already mapped to ARIA without looking it up first. Keeping this in mind, I suggest that you add the ARIA roles for the time being to stay on the safer side of the scale — even if it means having to write redundant code.

Redundancy in ARIA

Interactive elements in HTML5 are those that are categorically intended for user interaction (e.g. most form elements or the button element). Adding default implicit ARIA roles to HTML5 interactive elements would not have any effect on them. Doing so will not have a detrimental effect thought but, as mentioned, not adding the ARIA roles wouldn’t put it in harm’s way. Interactive elements do not require ARIA roles and it is suggested that you do not add them so as to save development time.

Interactive elements must have accessible names. This means you must give its accessibility API accessible name property some value. This can be explained better with code:

<input type="text">

The above code can be written more appropriately as:

<label for="title">title</label>
<input type="text" id="title">

In the second line of code, both the visible and accessible labels are mentioned. Inclusion of the for and id attributes makes it apparent that the label applies to the input.

Examples of Redundancy

Let’s look at some examples of redundancy when using ARIA. And please keep in mind that the examples below are examples of code you should avoid using.

Default implicit roles to Interactive Elements

<button role="button">Submit</button>

In this case, the role is unnecessary. The button element itself is enough.

ARIA role along with native HTML counterparts

<div hidden aria-hidden="true">

This example uses HTML’s hidden attribute, so the aria-hidden feature is not needed.

ARIA added to long implemented structural elements

<h1 role="heading" aria-level="1">I am a Heading</h1>

In this case, both the role and the aria-level attributes are unnecessary.

ARIA with HTML5 Structural Elements

The advent of HTML5 brought forth an all new set of structural elements and sectioning elements that have default implicit semantics mapping to the ARIA roles.

For example:

  • aside maps to role=complementary
  • article maps to role=article
  • main maps to role=main

It is important to note here that some of these aforementioned elements only map to ARIA roles under certain conditions. For example, footer maps to role=contentinfo provided that it is not within an article or section element. Similarly, header maps to role=banner provided that` it is not within an article or section element.

From these examples, it is evident that the browser will expose the default implicit semantics by itself wherever they are implemented.

Browser Support

The structural and sectioning elements that have newly been added to HTML5 are in a good place. Most widely used browsers implement default implicit semantics — or in the case of Internet Explorer, are in the process of implementation.

For more info on browser implementation of ARIA features in HTML5, HTML5 Accessibility is a great resource to get you started.

Wrapping It Up

To conclude this article, I’d like to leave you with a quick summary:

  • Do not use ARIA roles, properties, or states if the feature is defined in the HTML5 Recommendation
  • Many HTML5 elements have default implicit ARIA semantics.
  • With the exception of Internet Explorer, ARIA support is very good among modern browsers.

What are your thoughts on adding ARIA attributes to HTML elements? If there’s anything I’ve left out, please leave your suggestions in the comments.

Frequently Asked Questions (FAQs) on Avoiding Redundancy in WAI-ARIA and HTML Pages

What is the purpose of WAI-ARIA in HTML pages?

WAI-ARIA, which stands for Web Accessibility Initiative – Accessible Rich Internet Applications, is a technical specification published by the World Wide Web Consortium (W3C). It provides a framework to improve the accessibility and interoperability of web content and applications, particularly for people with disabilities. It does this by defining ways to make web content more accessible to people with disabilities, such as by providing additional semantics to help assistive technologies like screen readers understand the structure and functionality of web content.

How does redundancy occur in WAI-ARIA and HTML pages?

Redundancy in WAI-ARIA and HTML pages can occur when the same information or functionality is provided more than once. For example, if an HTML element already has an implicit role that is defined by the HTML specification, and a developer adds an ARIA role that matches the implicit role, this creates redundancy. This can confuse assistive technologies and the users who rely on them.

What is the difference between HTML hidden and ARIA hidden attributes?

The HTML hidden attribute and the ARIA hidden attribute serve similar purposes but work in slightly different ways. The HTML hidden attribute hides an element from all users, while the ARIA hidden attribute specifically hides an element from assistive technologies. If an element is marked with ARIA hidden, it will still be visible to users who are not using assistive technologies.

How can I avoid redundancy when using the listitem role in HTML?

The listitem role is unnecessary for the ‘li’ element in HTML because it already has an implicit role of listitem. Adding the ARIA role of listitem to an ‘li’ element creates redundancy. To avoid this, simply use the ‘li’ element as it is, without adding the ARIA role.

What is the impact of redundancy on accessibility audits?

Redundancy can lead to failures in accessibility audits. This is because redundant ARIA roles can confuse assistive technologies, leading to a less accessible user experience. By avoiding redundancy, you can improve the accessibility of your web content and increase your chances of passing accessibility audits.

How can I use ARIA roles effectively to enhance accessibility?

ARIA roles should be used to provide additional semantics where the HTML specification does not provide them. They should not be used to duplicate the semantics that are already provided by HTML. By using ARIA roles judiciously and avoiding redundancy, you can enhance the accessibility of your web content.

What are some common mistakes to avoid when using ARIA roles?

Some common mistakes to avoid when using ARIA roles include using them redundantly, using them incorrectly, and overusing them. Redundant use of ARIA roles can confuse assistive technologies, while incorrect use can lead to incorrect semantics. Overuse of ARIA roles can make your web content overly complex and difficult to navigate.

How can I check for redundancy in my HTML and ARIA code?

You can check for redundancy in your HTML and ARIA code by using accessibility audit tools. These tools can identify redundant ARIA roles and other accessibility issues in your code. By fixing these issues, you can improve the accessibility of your web content.

What is the role of assistive technologies in web accessibility?

Assistive technologies play a crucial role in web accessibility. They help people with disabilities access and interact with web content. Examples of assistive technologies include screen readers, which read out web content for people with visual impairments, and voice recognition software, which allows people with mobility impairments to control their computers with their voices.

How does WAI-ARIA improve the functionality of assistive technologies?

WAI-ARIA improves the functionality of assistive technologies by providing additional semantics that help these technologies understand the structure and functionality of web content. This allows assistive technologies to provide a more accurate and useful representation of the web content to their users.

Rafay Saeed AnsariRafay Saeed Ansari
View Author

Rafay is an entrepreneur, computer scientist, and professional ghost-writer for several high-traffic websites. He provides byline and ghost-writing services for digital and brick-and-mortar businesses with a focus on web development, WordPress, and entrepreneurship.

accessibilityaria roleshtml5 accessibilityLouisLwai-aria
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week
Loading form