Transcript Non-mouse accessibility

Building Rich Yet Accessible Sakai Tools
Antranig Basman, CARET, University of Cambridge
Aaron Zeckoski, CARET, University of Cambridge
Josh Ryan, Arizona State University
Colin Clark, Adaptive Technology Resource Centre, University of Toronto
Overview
•
•
•
•
JavaScript and DHTML Accessibility
The challenges to making Web 2.0 accessible
The potential for improvement
ARIA and UI semantics
Accessibility Advice
• Out of date accessibility standards and legislation
– Technology-specific standards go out of date easily
– Current standards impede innovation
• Strategy:
–
–
–
–
–
Embrace JavaScript
Use emerging standards: ARIA, tabindex, etc.
Degrade gracefully in the interim
Think about the use case for accessibility
Start with accessibility, don’t add it at the end
Usability and Accessibility
• What does accessibility mean here?
– Keyboard access
– Support for magnification and linearization
– Screen reader support
• Focus on the goal, not the task
–
–
–
–
Eg. re-ordering images
Doesn’t necessarily look like DnD
What alternatives are available on the desktop?
Cut and paste-style interactions?
Accessibility Challenges
• Opaque user interface markup
• Non-mouse accessibility
• Live regions
Assistive Technologies
• Used by people with disabilities to perceive and
control the user interface:
• Examples:
– Screen reader
– Screen magnifier
– On-screen keyboard
• Most assistive technologies use built-in operating
system APIs for reflecting the user interface
Opaque Markup
• Cool new Web 2.0 interfaces push the semantic
abilities of DHTML
• Complex UI behaviour is typically attached to
generic HTML elements (eg. <div> and <span>)
• Assistive technologies attempt to read the
underlying document markup
• Problem: how do assistive technologies represent
DHTML interfaces to the user?
Opaque Markup:
An Example
• A DHTML menu bar without semantics:
<div id=“myMenuBar”>
<div id=“Edit”/>
<div id=“Cut”’/>
<div id=“Paste”/>
</div>
Opaque Markup: Solution
• Provide additional semantics or metadata that describe the
role, function, and states of DHTML user interfaces
• How? ARIA (Accessible Rich Internet Application)
http://www.w3.org/TR/aria-roadmap/
http://www.w3.org/TR/aria-role/
http://www.w3.org/TR/aria-state/
• Working standard from the W3C, led by Fluid partner Rich
Schwerdtfeger
ARIA
• Attributes added to your HTML markup that describe
the function and states of your UI components
• These map to all your familiar types of UI widgets:
–
–
–
–
–
Dialog
Slider
Progress Bar
Tab Panel
Menu bar
Opaque Markup:
A Solution
• A DHTML menu bar with ARIA semantics:
<div id=“myMenuBar” aaa:role="wairole:menubar" >
<div id=“Edit” aaa:role="wairole:menuitem“
aaa:haspopup=“true” />
<div id=“Cut”’ aaa:role="wairole:menuitem" />
<div id=“Paste” aaa:role="wairole:menuitem" />
</div>
ARIA Support
• ARIA requires support across the stack:
– Metadata standard
– Browser support: bindings to desktop accessibility APIs
– Assistive technology support
• Support is growing:
– FireFox 2.0 has full ARIA support except live regions
– IE 7 support is coming in the next version
– Latest versions of JAW and Window-Eyes support
everything except live regions
ARIA Illustrated (Badly)
The Value of ARIA
• DHTML accessibility is a short-term problem
• Long-term, it has the potential to make web
accessibility much better
• Assistive technology developers have had a decade
to get desktop GUI accessibility right
• By mapping rich-client interfaces with ARIA, web
interfaces can leverage this support
Non-mouse accessibility
• Most rich Web 2.0-type interactions require the
mouse
• Standard tabbing strategy in browsers is tedious
• Keyboard bindings will enable almost all of the nonmouse control strategies:
– On-screen keyboard
– Single switch
– Voice control
Tabbing and tabindex
• Browsers used to only allow you to use tab to focus
form elements and links
• There is an HTML attribute called “tabindex” that
allows you to tell the browser how to handle tabbing
• Strategy:
– allow the user to tab to user interface widgets
– use the arrow keys allow selection within
An Example of Tabbing
• Allow focus to arbitrary DOM elements:
<div id=“myMenuBar” tabindex=“0”>
• Prevent focus on contained elements:
<div id=“myMenuBar” tabindex=“-1”>
• Add JavaScript handlers for arrow keys
• Use a toolkit for keyboard events and DOM
manipulation, it will make your life much easier!
• This is supported in FireFox 1.5+ and IE 6+
Live Regions
• A live region is an area on screen that is dynamically
updated without the page reloading
• Examples:
– Dynamic stock ticker
– Presence
– Chat
• Biggest accessibility problem for Web 2.0:
– How should the user be informed of a live change?
– When should the user be informed?
– How important is the information? Should the user’s current
task be interrupted to inform them of a change?
Solution: ARIA Live Regions
• Key design question: think about politeness:
– Polite: don’t read the updated text until the user is
finished their current activity
– Assertive: This is higher priority, but don’t interrupt
– Rude: Interrupt the user. This could be disoriented, but
may be necessary for high-priority notifications