Last week I did a five-minute lightning talk about ARIA, at Sydjs. The main point was to illustrate a secondary benefit to using ARIA, beyond the primary purpose of accessibility: taking advantage of the standardised definition of state.

If you already have to define state and declare element relationships for your JavaScript, why not use ARIA attributes instead of generic classes or data attributes?

The technique of using ARIA to attach behaviour is something we've been trying in the Atlassian frontend team. We have some components (and component options) which only work when the required DOM states and relationships are declared using ARIA. Leave out the ARIA attributes and they simply don't work. To put it another way: ARIA is part of the API.

Note this is an experimental technique, the main downside is if we need to modify our ARIA implementation we are effectively changing the API. Of course that's no different to changing any other attribute- or markup-based API and we use templating to lessen the impact. I'm simply calling out the point as maintenance impacts should be considered before you decide to roll out any technique in your own scenario! Also you must remember that including ARIA attributes doesn't guarantee accessibility - you must still test it works (and re-test after changes).

If you have an established API, you are of course totally free to add ARIA in your scripts. For example, if you already declare an equivalent to aria-owns, you should add in aria-owns when your JavaScript processes it. It's a small cost to pay for making your rich internet application accessible.

Anyway, here are the slides from the lightning talk, plus a more detailed transcript than the one generated by Slideshare.


(View ARIA (SydJS lightning talk) on slideshare)


Slide 1

SydJS lightning talk, 2013.03.20
Ben Buchanan / @200okpublic

Slide 2

"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." - Tim Berners-Lee, 1997


  • You've probably seen this quote before. It gets used a lot because it demonstrates the fact Tim Berners-Lee's vision for the web has always been one of inclusivity.
  • Quote source: or if you prefer.

Slide 3

(Photo of "This is for everyone" tweet from Olympics opening ceremony.)


  • During a recent speaking tour, he said accessibility has come a very long way (when considered over a decade-long period – big picture). But he also warned that JS-heavy applications were a great risk to that progress.
  • Image source:
  • TimBL paraphrased from a Q&A session at UNSW, 2013.02.01

Slide 4

This is relevant to your interests.


  • As the people writing those JS-heavy applications, this is relevant to your interests...
  • For a long time, accessibility was touted as a bluntly JS-on or JS-off dichotomy. That misled many people into thinking accessibility was too hard; or that if you wanted to do cool stuff you were excused from accessibility.
  • That of course is bullshit. You can do all the JS ninja stuff you want and still make it accessible.


  • Accessible Rich Internet Applications
  • Enhances the DOM
  • Describes richer interactions


The basics are still pretty easy: test the keyboard, check the colours, ensure there's alt text. It's the richer DOM work that is harder: updating the DOM, linking elements, elements behaving like other elements. The problem with screen readers they were built to meet a load once, render once paradigm; but DOM changes weren't picked up. ARIA describes the state of the DOM in ways assistive tech can read, basically bolting accessibility back on where it had fallen off.

Slide 6

Reasons to use it

  • Obviously, because a11y is good
  • But also its freakin useful


The cool thing though is you should also think about using ARIA purely because it's frickin useful.

Slide 7

State reinvented over and over and over



People reinvent state, over and over and over. Disabled, enabled, on, off, active, hidden...

Slide 8

...and over



No matter how you're bunging this stuff into the DOM, you're still having to define and implement it all; and document it for the next person.

Slide 9

"What meaningful properties does this object have at this time?" -


What's interesting is all this information is the same information assistive technology needs. In order to describe rich interaction, ARIA had to define it.

Slide 10

Description requires definition


This gives us a standardised list of common interaction states, element attributes and roles... AND it makes that accessible to assistive technology.

Slide 11

Link elements
<div class="tooltip" id="foo">Not announced</div>


A quick example here is a tooltip. The second element is often generated from title text, but the title has to be suppressed to avoid double up. So once you turn it into a tooltip it's no longer available to assistive tech. There is no link between these two elements in the DOM, the DIV is commonly appened to BODY and positioned with JS.

Slide 12

Link elements
<a aria-describedby="foo">Trigger</a>
<div role="tooltip" id="foo">Announced</div>


Simply by changing the class to a role; and using described-by, you can solve these problems. The elements are linked in the DOM and assistive tech knows that random DIV is actually tooltip (which is a defined widget type). I can vouch this works as I've tested it, while creating a pull request that's been ignored for going on six months now... (we've since forked that library).

CAVEAT: presumes there is a role="application" or "document" higher up the DOM.

Slide 13

Side by side
<div class="tooltip" id="foo">Not announced</div>

<a aria-describedby="foo">Trigger</a>
<div role="tooltip" id="foo">Announced</div>

And just a quick side by side to make it easier to see how similar the code is. While ARIA can be a little verbose, it's quite readable.

Slide 14

  • Dont overdo it...
  • Use core HTML where valid: <input type="checkbox" disabled />
  • ARIA fills in the gaps: <span role="checkbox" aria-checked="false" tabindex="0" id="chk1"></span>


The ARIA spec itself is very clear on this: use ARIA when there is a gap that needs to be fixed. That includes gaps you've put in yourself ;) Checkbox code from

Slide 15

Separate your functional CSS




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


What's interesting is once you start using ARIA states like this, you can separate the CSS that's not concerned with how things look. Many widgets have a small amount of functionality-related CSS; so you can attach that to the same attributes you're using for behaviour.

Slide 16

Support (chart showing good cross-browser support)


Screenshot from

Slide 17

Careful! Browsers may rock at ARIA, but suck at assistive tech. eg. Firefox + NVDA = good Chrome + NVDA = bad


Just be aware that not all combinations are equal. This is not cause to panic, just test with the right stuff. Webaim have a great guide for this:

Slide 18

To summarise: Rejoice! ARIA means Javascript no longer kills kittens!


You already define state and manipulate the DOM. Use ARIA to do it and make your stuff accessible!

(this was the end of the actual lightning talk, more info slide just for sharing)

More info


One little home truth about ARIA is the specs are really hard to read. Seek out these dev-friendly options instead of the raw specs!