Avoiding Redundancy with WAI-ARIA in HTML Pages

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:

<label>title</label>
<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