An Introduction to WAI-ARIA

Share this article

It might come as a shock, but I tell you: The web has changed! The last eight years have seen the rise of Ajax, JavaScript, HTML5, and countless front-end frameworks. Consequently, the internet is no longer a place of static HTML pages, as funny as they sometimes are. Rather, it has become a playground for complex, almost desktop-like web applications, each with their own widgets, controls, and behavior.

Most of us take this for granted and push web development to the limit. However, there is also a non-negligible number of people with disabilities who still struggle with these new techniques. This is not due to disabled JavaScript or insufficient capabilities of current assistive technology (AT). On the contrary, in 2012 WebAIM found that over 98 percent of screen reader users had JavaScript enabled. Additionally, ATs like screen readers or refreshable Braille displays are getting better every year.

The problem lies with HTML’s limited ability to mark up web applications that make heavy use of JavaScript and produce a huge amount of dynamic content. Four key obstacles can be identified when ATs deal with JavaScript applications:

  1. Unknown functionality of components
  2. Unknown states and properties of components
  3. Unreported change of dynamic content
  4. Bad keyboard accessibility



ARIA, as it is sometimes referred to, stands for Accessible Rich Internet Applications. It is a technology specification that was designed by the Web Accessibility Initiative (the WAI part that completes the acronym) in the W3C (the World Wide Web Consortium) and it is now a W3C recommendation.

You could think of ARIA as a suite of attributes to be included in your usual HTML code. These additional semantics help ATs to identify properties, relationships, and states in your user interfaces. That way ARIA tackles the accessibility challenges mentioned above and allows developers to make advanced web applications more usable for people with disabilities.

Let us now take a look at Bootstrap’s tab panel widget and explore in detail how ARIA helps us augment the given HTML structure to make it more accessible. We will address each of the aforementioned key problems along the way.

1. Functionality via Roles

ARIA provides a rich role taxonomy that enables you as a developer to classify otherwise meaningless tags. That prepares the tags for ATs by revealing the functionality or the part they play in the overall web document.

Bootstrap uses an unordered list to mark up its tabbed navigation. The framework also uses the ARIA roles tablist and tab correctly.

<ul id="myTab" class="nav nav-tabs" role="tablist">
    <li class="active">
        <a href="#home" role="tab" data-toggle="tab">Home</a>
        <a href="#profile" role="tab" data-toggle="tab">Profile</a>
        <a href="#articles" role="tab" data-toggle="tab">Articles</a>

Those roles override the usual list and list element type and expose this HTML snippet to represent a tab list. We should take this one step further than Bootstrap. Here’s the HTML for the panels, within which we’ll add the correct ARIA roles:

<div id="myTabContent" class="tab-content">
    <div class="tab-pane fade in active" id="home" role="tabpanel">
    <div class="tab-pane fade" id="profile" role="tabpanel">
        <p>My profile.</p>
    <div class="tab-pane fade" id="articles" role="tabpanel">
        <p>My articles.</p>

Note: Please ignore class names like active and tab-pane; they belong to Bootstrap and are for presentational purposes only.

Roles help set a solid foundation, but that is not the whole story.

2. States and Properties

ARIA states and properties offer the user further information on how to interact with a particular widget. This is all about revealing the relationships and states of our application to users on keyboards and screen readers. Mercifully, the W3C provides us some detailed WAI-ARIA best practices to follow.

So far, we have a tab list and a number of panels. However, the connection between them only exists because Bootstrap’s JavaScript ties them together. In other words, there is no inherent relationship. ARIA comes to the rescue with the aria-controls and aria-labelledby properties.

The aria-controls property is used to associate a control with the region it controls. The aria-labelledby property is used to indicate the element that works as a label for the element.

Here is the improved markup for the tab:

<li class="active">
    <a id="tab1" href="#home" role="tab" aria-controls="home" data-toggle="tab">Home</a>

And here is the new markup for an individual panel:

<div class="tab-pane fade in active" id="home" role="tabpanel" aria-labelledby="tab1">

Note how these elements are connected by using the value of the respective id attributes.

What else should we describe explicitly? We could say that at any moment in time, only one tab is selected and only the corresponding panel is visible. Fortunately, aria-selected and aria-hidden are here to save the day! They are Boolean and can be set to true or false. These can be changed using JavaScript on the appropriate tabs and defaults can be set in the markup to begin with.

3. Live Regions for Dynamic Content

Discovering dynamically updated content without page reload is one of the biggest obstacles for screen readers, especially in the days of Ajax, Node, and single-page applications. How should these be handled? Should the whole page be spoken again? Or should the AT do nothing, risking that the user will miss important updates?

Even something as simple as our little tab list can be tricky. Imagine we use a timer function to loop through our tabbed interface (similar to an image slider). This will lead to different content displaying depending on the currently selected tab.

To fill this gap, ARIA established the concept of live regions that allow ATs to be notified whenever there are changes in that particular part of the document.

Let’s implement a live region in the div that contains the currently visible tab panel:

<div id="myTabContent" class="tab-content" aria-live="polite">

Setting the aria-live property to polite means the screen reader will wait to announce the change only when the user is not busy doing another task on the page. A value of assertive would notify the user immediately.

4. Enhanced Keyboard Navigation

In the old days of HTML4, the only elements that could receive keyboard focus with the TAB key were links and form elements. This had some serious implications for people who were forced to operate a web page without a mouse. How are they supposed to navigate to span or div elements that might pose as tabs or drop-down menus?

As a result, ARIA enabled every HTML element to receive keyboard focus by extending the tabindex attribute. Today, this is part of the HTML5 specification.

Adding some JavaScript concludes our example and makes Bootstrap’s tab panel widget keyboard-accessible. Check out the CodePen demo and try to operate the widget with the TAB and arrow keys only.

See the Pen BeplL by SitePoint (@SitePoint) on CodePen.

Note: You can use a negative number as a tabindex value. Elements with a negative tabindex cannot be reached with the TAB key but only with JavaScript. This comes in handy when you want to reveal functionality as the user progresses through your application.

Make sure to read the section on Keyboard Navigation on the Mozilla Developer Network for more best practices.


HTML5 (also called the living HTML standard) has added several useful, semantic tags, and attributes to the language, e.g. the progress and nav element, and the required attribute. Nowadays it is not always recommended to add ARIA code when HTML has you covered.

The following examples are considered bad practice:

<div role="navigation"></div> <!-- don't repurpose, use <nav> instead -->
<h2 role="button"></h2> <!-- don't change semantics, use <button> -->

If there is a suitable HTML element or attribute already implemented, but the accessibility support is not yet available, it is of course allowed and encouraged to use ARIA.

There are still a lot of situations where ARIA proves useful. Do not miss the opportunity to read accessibility mastermind Steve Faulkner’s thoughts on that topic — more than 4 years old, still valid!

Can I use ARIA without Risk?

Absolutely! ARIA was designed to be recognized only by assistive technology and does not affect the DOM or your styling in any way. This does not mean, however, that you cannot leverage ARIA roles and properties with CSS to style your application accordingly:

.button[aria-hidden="true"] {
    display: none;

In terms of browser support, you are safe to start using ARIA right now.


ARIA was designed to be supportive while being easy to implement. It won’t restrict your workflow in any way, instead providing you a set of roles, attributes, and semantics to build feature-rich yet accessible web sites.

In case you need a little more convincing, try this screen reader simulation and experience how it feels to be dependent on your assistive technology and thus on properly implemented web applications. We as responsible developers have to step in and pave the way!

Frequently Asked Questions (FAQs) about WAI-ARIA

What is the difference between WAI-ARIA 1.0 and WAI-ARIA 1.2?

WAI-ARIA 1.2 is an updated version of WAI-ARIA 1.0. It includes new features and improvements to enhance the accessibility of web content. For instance, it introduces new roles, states, and properties that can be used to make web applications more accessible to people with disabilities. It also provides more detailed guidance on how to use ARIA effectively.

How does WAI-ARIA improve web accessibility?

WAI-ARIA provides a framework for adding roles, states, and properties to HTML content in order to make it more accessible. These additions provide information about the behavior and purpose of interface components, making them more understandable to assistive technologies like screen readers. This helps users with disabilities to interact with web content more effectively.

Can WAI-ARIA be used with any programming language?

WAI-ARIA is not tied to any specific programming language. It is a set of attributes that can be added to HTML content to improve its accessibility. These attributes can be added to HTML content regardless of the programming language used to create the web application.

What are some common mistakes to avoid when using WAI-ARIA?

Some common mistakes include overusing ARIA, using incorrect or unnecessary ARIA roles, states, or properties, and not testing with actual assistive technologies. It’s important to remember that ARIA should be used as a supplement to good semantic HTML, not as a replacement.

How can I test the effectiveness of my WAI-ARIA implementation?

There are several tools available for testing the accessibility of your web content, including automated testing tools, manual testing tools, and assistive technologies like screen readers. It’s also important to involve users with disabilities in your testing process to ensure that your web content is truly accessible.

What are some resources for learning more about WAI-ARIA?

The W3C’s WAI-ARIA documentation is a comprehensive resource for learning about ARIA. Other resources include the Mozilla Developer Network’s guide to WAI-ARIA, and various online tutorials and courses.

Is WAI-ARIA only for web applications?

While WAI-ARIA is primarily used for web applications, it can also be used to improve the accessibility of other types of digital content, such as eBooks and digital documents.

Can WAI-ARIA be used with HTML5?

Yes, WAI-ARIA can be used with HTML5. In fact, many of the new semantic elements introduced in HTML5 have corresponding ARIA roles, states, and properties.

What is the role of WAI-ARIA in WCAG 2.1?

WAI-ARIA plays a key role in meeting many of the success criteria in WCAG 2.1. It provides a way to add necessary information to web content to make it more accessible, helping to meet WCAG’s principles of perceivable, operable, understandable, and robust.

How does WAI-ARIA support dynamic content?

WAI-ARIA provides a way to communicate changes in dynamic content to assistive technologies. This includes changes in state (such as a button being pressed), changes in content (such as a live feed updating), and changes in context (such as a new dialog opening).

Stephan MaxStephan Max
View Author

Stephan is a Dublin-based developer originally from Germany. Holding a degree in computer science and being a code wrangler at heart, he works as a technical cloud adviser inside the IBM Bluemix team by day and moonlights as a front-end developer and JavaScript engineer. He loves traveling, writing, music, and building stuff that helps people.

accessibility introaria rolesLouisLwai-ariawai-aria roles
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week