Download Slide 1

An Introduction to WAI-ARIA
Dan Jackson
Web 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 Regions
4. Where ARIA we with ARIA?* Problems &
Issues
5. 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
English
“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.”
It’s a W3C
specification that
defines a way to make
Web content and Web
applications more
accessible to people
with disabilities.
(http://www.w3.org/TR/wai-aria/)
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.
Roles
States and Properties
Keyboard access
Live 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
menu
progressbar
slider
tab
toolbar
tree
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" ariavaluemin="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-Word
ARIA vs. HTML 5
Is it supported?
Complexity
Will 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
HTML 5
Landmark Roles
New structural elements
<div role=”navigation”>
<nav>
ARIA Properties and States
HTML 5 form attributes
<input name=”email”
aria-required=”true”>
<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/ARIASafariaOperaIEFF.html
Issue #3:
Is ARIA supported?
Screen readers
ZoomText 9+
JAWS 7.1+
NVDA (free!)
VoiceOver (free!)
FireVox (free!)
Orca
JavaScript
Libraries
Jquery UI
YUI
Dojo
ExtJS
GWT
Glow (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
Screen reader?
Mostly.
AT users update?
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/introd
uction-to-wai-aria/
Probably the best introductory article online .
• http://wiki.codetalks.org/
Excellent set of ARIA test cases.
• http://paciellogroup.com/blog
Great all round accessibility resource, with emphasis on ARIA.
• http://www.w3.org/WAI/intro/aria
Understandable W3C introduction to ARIA.