ARIASydJS lightning talk, 2013.03.20Ben Buchanan / @200okpublicweblog.200ok.com.au

"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: http://www.w3.org/Press/IPO-announce or http://www.w3.org/standards/webdesign/accessibility if you prefer.

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: http://www.pocket-lint.com/news/46694/sir-tim-berners-lee-olympic-tweetTimBL paraphrased from a Q&A session at UNSW, 2013.02.01

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.

ARIA

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.

Reasons to use it

Obviously, because a11y is good

But also it's freakin useful

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

State reinvented over and over and over

class="disabled"class="enabled"class="on"class="off"class="ticked"class="checked"class="focus"class="active"class="hidden"

People reinvent state, over and over and over.

Disabled, enabled, on, off, active, hidden...

...and over

data-my-awesome-namespace="disabled"data-my-awesome-namespace="enabled"data-my-awesome-namespace="on"data-my-awesome-namespace="off"data-my-awesome-namespace="ticked"data-my-awesome-namespace="checked"data-my-awesome-namespace="focus"data-my-awesome-namespace="active"data-my-awesome-namespace="hidden"

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.

"What meaningful properties does
this object have at this time?"- http://www.w3.org/TR/2010/WD-wai-aria-primer-20100916/#properties

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.

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.

Link elements

Bad:Trigger
Not announced

A quick example here is a tooltip.

The second element is often generated from title text, but the title has to be supprssed 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 floated.

Link elements

Good:Trigger
Announced

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...

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

Side by side

Bad:Trigger
Not announced

Good:Trigger
Announced

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.

Don't overdo it...

Use core HTML where valid

ARIA fills in the gaps

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 https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_checkbox_role

Separate your functional CSS

DOM: aria-hidden="true"

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.

Support

Screenshot from http://caniuse.com/#feat=wai-aria

Careful! Browsers may rock at ARIA, but suck at assistive tech.
eg. Firefox + NVDA = goodChrome + 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: http://webaim.org/articles/screenreader_testing/

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!

More info

"Using WAI-ARIA in HTML"
https://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/index.html

"WAI-ARIA 1.0 Authoring Practices"
http://www.w3.org/WAI/PF/aria-practices/

ARIA on MDN
https://developer.mozilla.org/en-US/docs/Accessibility/ARIA

ARIA posts on TPG blog
http://blog.paciellogroup.com/category/wai-aria/

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!

Click to edit the title text format