By Rafay Saeed Ansari

Avoiding Redundancy with WAI-ARIA in HTML Pages

By Rafay Saeed Ansari

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.

  • William H

    Adding these ARIA attributes allow non-HTML5 user agents to understand. Maybe in a few years, but removing accessibility when the repetitiveness doesn’t harm non-AT users is not a good move.

    • Steve Faulkner

      The point is that no UAs need ARIA to fill in the gaps for the majority of HTML elements.

      • William H

        While I understand most HTML elements are implicit, almost 40% of screen reader usage is in IE9+ where most HTML5 elements are not implicit. As I understand it, removing ‘role=article’ from ‘article’ will result in 40% of screen reader users not being exposed to the default semantics. Whereas adding the role does not affect non-AT users.

        I promise I am not trying to debate. I’m just making sure I have the correct information. I respect your knowledge on this and I have learned so much from your vast contributions.

  • Here is a way how it is possible to get paid 65 dollars an hour… After being unemployed for half-a-year , I started working over this site and today I possibly can not be happier. @# 3 months have passed since being on my new job and my income is around five-thousand $/a month -Check internet-website i use on MY~DISQUS~

  • Is there a tool that can parse the HTML or DOM of a page and identify (A) where ARIA is redundant and (B) where ARIA is missing?

  • Leanna Bailes

    Here is something to pay attention , a great opportunity for work for those who want to use their free time to make money using their computers… I have been doing this since last two years and I am making 40 to 70 dollars per hour … In the last week I have made 12,245 for almost 18 hours sitting ….

    ?There are no special skills required just basic typing and an internet connection ….

    ?There are no time constraints … You may do this any time when you are free ….

    ?Here is what I’ve been doing….

    < ->>w­w­w­.­y­o­u­c­a­n­a­l­s­o­c­h­a­n­g­e­y­o­u­r­f­a­t­e­l­i­k­e­o­t­h­e­r­s­a­r­e­.­b­l­o­g­s­p­o­t­.­c­o­m >


  • This is something very interesting that is worth paying your extreme attention ,a very good chance to work for those people who want to use their free time so that they can make some extra money using their computers… I have been working on this for last two and half years and I am earning 60-90 dollar/ hour … In the past week I have earned 13,70 dollars for almost 20 hours sitting ….

    Any special qualification, degree or skills is not necessary for this, just keyboard typing and a good working and reliable internet connection ….

    Not any Time limitations to start work … You may do this work at any time when you willing to do it ….

    Just know how I have been doing this…..….see this (webiste-Iink) on my !profile!` to know how I am working` on this`


Get the latest in Front-end, once a week, for free.