Developing with ARIA to help make your web application accessible
Accessible Rich Internet Applications or ARIA, is a specification created to make interactive content accessible.
Why do we need ARIA?
Websites are becoming more like desktop applications. Unique functionality is being made possible by new technologies, techniques, and devices.
Unfortunately, with the rapid pace of change on the web, visitors who can’t perform all the expected actions on a website – such as using a mouse – are being left behind.
This is why the ARIA specification was drafted – so that creators can continue to build feature-rich web applications and still support those with disabilities.
Who created ARIA?
The ARIA specification was developed by the Web Accessibility Initiative, otherwise known as WAI.
WAI is a W3C scheme sponsored by governments, businesses, and other organisations. Each is committed to making the web accessible by creating useful specifications aimed at helping those with disabilities.
According to the W3C itself:
The World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long-term growth of the Web.
W3C was formed by the fella who created the web, none other than Sir Tim Berners-Lee! It is a gang of smart forward thinking girls and guys that would like everyone to get along together. With assistance from individuals to whole companies they’ve been able to draft a whole set of guidelines that help everyone.
What is ARIA?
ARIA is a small amount of markup (HTML code) that creators can use to help specify certain rules or logic to screen readers and other assistive technologies.
When I say a small amount, it really isn’t much markup at all.
When writing ARIA markup, you just need to add one of two attributes – the role attribute and the aria-.* attribute (“.*” meaning that what follows “aria-” is a variable).
The role attribute (role="*")
Roles help give screen readers and other assistive technologies a better sense of where they are on a page.
A screen reader will announce what role they are focused on. This gives the user a better perception of the page layout and what content to expect within each role.
Each container in the screenshot below has been given an ARIA role which appropriately describes the content of that element.
Here is the markup used to render the above page:
<body> <header role="banner">banner</header> <nav role="navigation">navigation</nav> <main role="main">main</main> <aside role="complementary">complementary</aside> <footer role="contentinfo">contentinfo</footer> </body>
As you can see, it’s all very simple to implement. You have a container and you give it a purpose (or ‘role’). A list of these roles and their definitions can be found in the W3C WAI-ARIA specification.
These roles can also be nested. This means a navigation role can be within main, and so on.
States and Properties (aria-.*)
The purpose of states and properties is to let screen readers and other assistive technologies know when an element's state is being altered. So for instance when a checkbox is checked the user is made aware.
With the use of some simple markup tags like
aria-checked="true" you can tell assistive technologies when you are changing the state or the property of an element.
Unfortunately a blind person wouldn’t be able to see that or understand what just happened.
Fortunately that’s easy to resolve with an ARIA state. The answer is to:
aria-checked="false" to the list item element.
aria-checked="true” at the point that it updates the background colour.
For a full list of available ARIA roles and properties, visit the W3C website.
Let’s say you need a dialog window to open up, and this is quite a big change on a page. You are moving the focus position and need to make sure that a screen reader – and therefore the user – is aware.
Here’s the markup you should use:
<dialog role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc"> <h2 id="dialog1Title">Your personal details were successfully updated</h2> <p id="dialog1Desc">You can change your details at any time in the user account section.</p> <button>Close</button> </dialog>
Here is what the markup is doing;
Tells the browser and assistive technology that this is a dialog box / window.
Tells the assistive technology where to get the name for the dialog box / window.
Tells the assistive technology where to get a description of the dialog box / window.
Use your states and properties within a relevant role
It’s important to bear in mind that the majority of states and properties need to be related to a specific role.
So, when using
aria-checked="true",the state needs to be related to a relevant role such as
HTML5 and ARIA roles
Semantic HTML tags are now the norm in the modern HTML5 development process.
A semantic element clearly describes its meaning to both the browser and the developer. Some of the more common semantic HTML tags include
Use these as much as possible because they are awesome. Remember though that ARIA states and properties need to be related within an ARIA Role (the majority of the time).
So for example when using
‹main role=”main›, use both the HTML5 tag
There are no negative effects from using both, plus when a user is using an older user agent (I’m looking at you, IE 8) it falls back gracefully.
Checking your code
You should always check your markup. This should be done throughout development and then re-checked before publishing. There are two methods that I’d recommend you use to check if you’ve implemented ARIA correctly.
Number 1 - Validate it
When creating any page you should always validate your HTML.
The best HTML validator currently is the Nu HTML checker. Hosted by W3C, it is a free validator that checks all your markup, including ARIA, for any errors.
Wave is an accessibility tool that runs multiple checks on a page. This includes checking whether ARIA tags are available and whether they’ve been implemented correctly.
Number 2 - Give it a go
If you have a Windows PC then I would recommend installing NV Access. It’s free and open source, so it’s always being improved upon.
Macs come pre-installed with VoiceOver. It’s quite the powerhouse, but it's easy just to test a single page.
Both of the above are good, but an even simpler method is to use your mobile device.
iOS has a fantastically simple-to-use and slimmed down version of VoiceOver. It is perfect for ease of use and portability.
There is plenty more that ARIA is capable of that I didn’t touch on in this article.
I’ve compiled a list of great articles and websites that have been invaluable to me:
- An overview of WAI-ARIA from the W3C.
- The W3C's WAI-ARIA specification.
- An accessible widget and pattern library from the A11Y project.
- WebAIM's guide to testing with the NVDA screen reader.
- This Sitepoint guide to using ARIA effectively with HTML5.
- Practical ARIA examples from Haydon Pickering.
- The results of WebAIM's latest survey of screenreader users.
The major stumbling block when trying to implement ARIA into a site, is that others will often think of it as an afterthought during a project. Be sure to keep nagging and pushing for it. It really does help a significant number of the population using screen readers and other assistive technologies.