Skip to main content

Developing with ARIA to help make your web application accessible

Wednesday, 28 September 2016
Sam CliffordFront-end developer
Advice5 min

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. 

Screenshot of a web page with containers named banner, navigation, main, complementary, and contentinfo.

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.


Check list

You’ve created a shopping list using HTML and Javascript. Good job.

Screenshot of webpage with a text box and four check boxes.

When someone clicks an item in the list, JavaScript updates the item to have an active state turning the background colour red.

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:

Add aria-checked="false" to the list item element.

Get your JavaScript to update to 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.

Dialog window

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;

‹dialog role="dialog"

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 role="checkbox".

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 ‹header›‹nav›, and ‹time›.

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 ‹main and role=”main”.

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.

Next steps

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:

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.