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




Expanded
Selected
disabled
readonly
 State: What are it’s current features, what properties does it
have? Examples:
◦ 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 Xbrowser 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