- Unknown functionality of components
- Unknown states and properties of components
- Unreported change of dynamic content
- 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
<ul id="myTab" class="nav nav-tabs" role="tablist">
<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">
<div class="tab-pane fade" id="articles" role="tabpanel">
Note: Please ignore class names like
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.
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:
<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
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-hidden are here to save the day! They are Boolean and can be set to
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">
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
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.
See the Pen BeplL by SitePoint (@SitePoint) on CodePen.
Note: You can use a negative number as a
tabindex value. Elements with a negative
Make sure to read the section on Keyboard Navigation on the Mozilla Developer Network for more best practices.
ARIA and HTML5
HTML5 (also called the living HTML standard) has added several useful, semantic tags, and attributes to the language, e.g. the
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:
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!