An Introduction to WAI-ARIA

Dan JacksonWeb Team Leader

City University London

About this session

1. What is ARIA? What does it do?2. Why do we need it?3. Roles, States and Properties,

keyboard navigation, Live Regions4. Where ARIA we with ARIA?* Problems

& Issues5. Best practice

* All my puns are rubbish.

Get the acronym out of the way early doors....

Web Accessibility Initiative. Accessible Rich Internet Applications.

It’s at ‘Final Call’ draft stage, i.e. it’s not a formal specification (yet).

What does ARIA do?

W3Cese

“This specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information in document-level markup, to an assistive technology.”

(http://www.w3.org/TR/wai-aria/)

English

It’s a W3C specification that defines a way to make Web content and Web applications more accessible to people with disabilities.

Why do we need ARIA?

Some background...

HTML is so, like, 1999:• very limited set of interface controls.• difficult communication model

JavaScript is bitchin’:• dynamic interactions (drag & drop, sorting,

resizing) • widgets (date pickers, sliders, tabs, progress

bars, etc) • AJAX

Why do we need ARIA?

So what’s the problem?1. Widgets are inaccessible - Assistive

Technologies (AT) don’t know what they do.

2. Widgets are rarely keyboard accessible.

3. Content updated using AJAX is not reported to AT.

ARIA to the rescue!

ARIA provides semantic meaning, dynamic content updates and consistent keyboard support to AT users.

RolesStates and PropertiesKeyboard accessLive Regions

The technical part

Roles

Roles define widgets and page structure.

2 categories:Landmark Roles Widget and Element Roles

Landmark Roles

““The skip-links killer”Define the role of sections in the structure of a web page, e.g.:

<div id=”header” role=”banner”><div id=”content” role=”main”>

Gives AT instant access to major page components

Landmark roles

Widget & Element Roles

To describe GUI widgets, elements common on desktop but not native to HTML.

Examples:

grid menuprogressbarslidertabtoolbartree

States and Properties

Provide AT with information about how elements & widgets are configured, e.g.:

has a button been pressed? <button aria-pressed=”true”>

is an input field required? <input aria-required=”true”>

how much of my file upload is complete? <div role=”progressbar” aria-valuetext="0%" aria-valuenow="0" aria-valuemax="100" aria-valuemin="0">

Accessibility isn’t just about screen readers....

Throw away your mouse.

Keyboard access

ARIA extends the use of HTML’s tabindex attribute.tabindex = “0”: allows all elements to be accessed using keyboard.tabindex=”-1”: allows elements to be given programmatic focus without adding them to the tab order.

Eh?

This is a good thing. Why?

• Easier navigation through document, i.e. one ‘tab stop’ per UI control.

• Gives keyboard access to widgets.• Manages keyboard control within widgets.• Establishes relationships between elements

within widgets (e.g. parent/child/sibling in tree-view navigation).

Live Regions Are Way Cool

Solves the problem of how to announce content updated by AJAX to screen reader users.

Properties:

aria-live = off | polite | assertive | rude

aria-atomic = true | false

aria-busy = true | false

aria-relevant = additions | removals | text | all

Problems, issues:The V-WordARIA vs. HTML 5Is it supported?ComplexityWill AT users adopt it?

Where aria we with ARIA?

Issue #1: The V-Word

Any Validation Nazis in the room?

ARIA won’t validate with HTML 4.01, XHTML 1.0. What to do?

• Put up with it.• Inject attribute values using JavaScript.• Create a custom DTD!• Use HTML 5!?

Issue #2: ARIA vs. HTML 5

ARIA

Landmark Roles<div role=”navigation”>

ARIA Properties and States <input name=”email” aria-required=”true”>

HTML 5New structural elements<nav>

HTML 5 form attributes <input name=”email” type=”email required”>

But...Many ARIA roles that have no HTML5 equivalent, e.g. application, banner, main.And…Argument over structural elements in HTML 5 = major shit-storm.

Issue #3: Is ARIA supported?

To use ARIA you need a browser that both supports ARIA and is supported by a screen reader that also support ARIA.

ARIA-aware OS/browser/AT combinations are some way off becoming the norm.

Browsers:Firefox 1.5+, Opera 9.5+, IE8, WebKit

http://www.paciellogroup.com/blog/aria-tests/ARIA-SafariaOperaIEFF.html

Issue #3: Is ARIA supported?

Screen readersZoomText 9+JAWS 7.1+NVDA (free!)VoiceOver (free!)FireVox (free!)Orca

JavaScript LibrariesJquery UI

YUIDojoExtJSGWTGlow (BBC)

Issue #4: Complexity

...it’s not exactly plug’n’play!

It’s a task just to set up the development environment.

Key board navigation requires complex JavaScript coding.

Issue #5: Do AT users update?Screen reader?Mostly.

Browser?Questionable.

http://www.webaim.org/projects/screenreadersurvey/

...it’s not all doom and gloom

Support is growing.

You can use ARIA to improve your website right now. (Landmark Roles, Live Regions)

Best practice

• WAI-ARIA is just one ‘layer’ of accessibility.

• Don’t withhold content from users without JavaScript (use HIJAX).

• Best practice techniques for front-end web development, & layer ARIA on where possible.

Resources

• http://dev.opera.com/articles/view/introduction-to-wai-aria/Probably the best introductory article online .

• http://wiki.codetalks.org/Excellent set of ARIA test cases.

• http://paciellogroup.com/blogGreat all round accessibility resource, with emphasis on ARIA.

• http://www.w3.org/WAI/intro/ariaUnderstandable W3C introduction to ARIA.