19
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 Building Rich Yet Accessible Sakai Tools

Antranig Basman , CARET, University of Cambridge Aaron Zeckoski , CARET, University of Cambridge

  • Upload
    carson

  • View
    51

  • Download
    0

Embed Size (px)

DESCRIPTION

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. - PowerPoint PPT Presentation

Citation preview

Page 1: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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

Building Rich Yet Accessible Sakai Tools

Page 2: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

Overview

• JavaScript and DHTML Accessibility• The challenges to making Web 2.0 accessible• The potential for improvement• ARIA and UI semantics

Page 3: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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

Page 4: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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?

Page 5: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

Accessibility Challenges

• Opaque user interface markup• Non-mouse accessibility• Live regions

Page 6: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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

Page 7: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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?

Page 8: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

Opaque Markup: An Example

• A DHTML menu bar without semantics:

<div id=“myMenuBar”>

<div id=“Edit”/>

<div id=“Cut”’/>

<div id=“Paste”/>

</div>

Page 9: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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

Page 10: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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

Page 11: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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>

Page 12: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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

Page 13: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

ARIA Illustrated (Badly)

Page 14: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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

Page 15: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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

mouse control strategies:– On-screen keyboard

– Single switch

– Voice control

Page 16: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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

Page 17: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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+

Page 18: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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?

Page 19: Antranig Basman ,  CARET, University of Cambridge Aaron Zeckoski ,  CARET, University of Cambridge

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