Presentation Description

No description available.


Presentation Transcript

Yahoo! / TPG Case Study : 

Yahoo! / TPG Case Study Applying WAI-ARIA to Yahoo! Mail

Introductions: Yahoo & TPG : 

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 Introductions: Yahoo & TPG

Introductions: Yahoo Mail : 

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 Introductions: Yahoo Mail

Introductions: ARIA : 

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 Introductions: ARIA

Introductions: the Project : 

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. Introductions: the Project

Challenges: Codebase : 

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. Challenges: Codebase

Challenges: Focus : 

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) Challenges: Focus

Focus (ctd.) : 

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. Focus (ctd.)

Challenges: Focus order : 

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 Challenges: Focus order

Challenges: Keyboard Shortcuts : 

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 Challenges: Keyboard Shortcuts

Challenges: Applying ARIA : 

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 Challenges: Applying ARIA

Challenges: Message Table : 

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) Challenges: Message Table

Challenges: Screen Readers : 

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 Challenges: Screen Readers

Components : 

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 Components

authorStream Live Help