An introduction to ARIA attributes
What is ARIA?
ARIA has become an important aspect of web development but these attributes are still somewhat of a mystery to me (and admittedly, usually an oversight). Unlike the HTML or CSS specifications, the guidelines for ARIA just aren't that memorable.
I decided to go over the basics of ARIA and work out how to apply them to my everyday work.
What does ARIA solve?
By adding this semantic information assistive technologies can determine how to react to content and provide relevant information to the user. ARIA has a W3C Recommendation containing valuable information on how it should be implemented and parsed.
Roles, states and properties
At its core, ARIA is made up of roles, states and properties. Roles dictate the purpose of a block of content, whereas states and properties provide cues on individual elements.
HTML5 introduced elements such as
<article> to bring meaning to commonly used design patterns. Assistive
technologies can see this markup and determine the role of those elements
ARIA helps to define these roles manually, as well as more complex roles such as toolbars, dialogs, tabs, forms and search bars. A full list of roles is found in Section 5.3 in the W3C recommendation.
Some HTML5 elements come with ARIA roles baked in—the ARIA role
banner is used
<header> to reduce the amount of markup. This means that the two
elements below would both be evaluated to have the same role:
<header></header> <div role="banner"></div>
ARIA sorts roles as one of six categories:
- Document Structure;
- Live Region; and
Assistive technologies are unable to detect state changes of complex DOM elements. By providing the current state of an object, the browser is able to to properly interact with it and determine how it should be used.
A common functionality of forms is to mark something as invalid. ARIA provides
attribute to indicate this state, as well as providing the option to pass a
value with the attribute for extra information.
For example, if there is a spelling error, the
can be passed to add this additional information for the browser to detect.
Where states indicate what a current object is doing, properties act like metadata by providing additional information, such as links to other elements.
An example of a property is the
attribute. This tells the browser that the element has a pop-up context menu or
sub-level menu. This could be used on a navigation list:
<nav> <ul> <li><a href="#">About</a></li> <li aria-haspopup="true"><a href="#">Services</a><ul> <li><a href="#">Reading</a></li> <li><a href="#">Writing</a></li> <li><a href="#">Administration</a></li> </ul></li> <li><a href="#">Blog</a></li> <li><a href="#">Contact</a></li> </ul> </nav>
Note that the attribute has the value of
aria-haspop can have a
value of either
false, but each property will have its own set of
possible values (which are documented within the W3C recommendation for each
Who uses ARIA?
Popular front-end frameworks and design systems are already integrating these techniques into their codebases.
For example, ZURB Foundation 6's pagination component uses ARIA roles and properties, and so does Bootstrap v3's pagination component, and Salesforce's Lightning Design System makes use of them across the different states of its button component.
These additions appear minimal but provide valuable information to those using assistive technologies. It is good to see popular frameworks putting accessibility as a priority.
I would recommend checking out the always-useful MDN as it has an entire section on ARIA techniques.
Although not complete, I find it goes into enough detail and provides enough examples to provide a good understanding of how ARIA works.