Applying WAI-ARIA to Yahoo! Mail

Yahoo◦ Global Internet services company providing vast

range of products, including a Web 2.0 email client

TPG◦ Provides accessibility related consultancy,

development and auditing

Yahoo Mail◦ Provides a rich, desktop like experience◦ Highly dependent on clientside scripting◦ Interface based on customized controls and

interaction model◦ Advanced, integrated features, such as

Instant messaging Text messaging RSS feeds

Solves a major accessibility problem with webapps: Role and state information

Role: what is the type of this widget? Examples: Slider Tree Tab menubar

State: What are it’s current features, what properties does it have? Examples: Expanded Selected disabled readonly

◦ This information is Exposed to AT (e.g. Screen readers) AT can correctly convey the control to the user, as if it was

a desktop based control

Yahoo Mail is an ideal candidate for ARIA◦ Highly dynamic◦ Highly Customized

TPG contractor was brought in as an experimental project◦ Assess accessibility requirements◦ Make necessary changes for ARIA to work◦ Apply ARIA roles and states

Three months were spent at Yahoo Sunnyvale

Results: It’s a start, but not there yet.

Up to 7 years old Not standards compliant Not geared towards accessibility in any way Not build from the ground up, but

constantly evolving Mainly targeted at performance and X-

browser compatibility Why not fundamental accessibility first?

◦ Yahoo mail classic◦ Would have to be redone from the ground up.

With ARIA it wouldn’t.

Focus in Yahoo Mail is mostly simulated◦ Visually something appears to have focus◦ Programmaticaly, neither the browser, OS or AT

are aware◦ For ARIA to work, proper focus must be applied:◦ Solution: Setting tabindex value:

tabindex=“0”: element becomes part of the tab order

Tabindex=“-1”: element just becomes focusable (through scripting or clicking)

Focus loss often occurs due to ◦ Rerendering of interface components

Destruction and recreation of currently focused control.

◦ Loading of external (out of our control) content. Tracking focus globally, forcing it back if needed.

Tab key used in different ways◦ Pane to pane navigation◦ Control to control navigation◦ Default (element to element) tab navigation is

suppressed.◦ Tab key currently loops main segments and

toolbars Toolbars considered too many stops by some,

possibly moving to shortcuts. Discoverability vs. Efficiency?

Arrow keys are used for subpart navigation Rich text editor tab trap

Yahoo Mail overrides some browser –native shortcuts, e.g. ◦ Closing tabs◦ Searching in messages

Set of shortcuts is provided for fast keyboard interaction.

Paradigm conflict: ◦ webpage pretends to be a desktop application,

but is in fact running inside another desktop application

Namespacing difficulties (no longer an issue since FF3)◦ Content handled as partial HTML text strings,

difficult to determine where it becomes action DOM content

Controls are drawn multiple times◦ Roles and states are destroyed everytime, will

have to be reapplied Library was created similar to enable.js

◦ Class based approach vs direct assignment◦ Apply to single or root container element:

performance risk

Both column and row navigation Table header announcement problematic

◦ JAWS: no announcement at all in PC cursor mode◦ WE: Correct heading announcement, breaks at

focusable rows Checkbox type cells Selection announcement (alert role)

Targeted at JAWS 9.0 beta & WindowEyes 6.1

Designed for non-virtual mode (browse mode off)

Difficult to get a clear idea of compatibility◦ Ertratic behavior◦ Few ‘real world examples’

Biggest issues:◦ Role = document vs role = application◦ Cell navigation

Cheats sometimes chosen:◦ Describedby

YUI components are sometimes used in Yahoo Mail, e.g. In Menu component

Currently ARIA is manually applied Next upgrade will include built in ARIA for

YUI