Yahoo! Experiences with Accessibility in DHTML and RIA Nate Koechley Senior Engineer & Designer, Yahoo! User Interface (YUI) Library Team Platform Engineering Group Yahoo! Inc. Slides Contact Web Builder 2.0 Las Vegas

Browser vs. Desktop

Web 1.0 vs. Web 2.0

Sure, but how?

Study the History of the Desktop Adapted from Alan Cooper’s “About Face 2.0” Book

[compounds] [idioms] Connection Manager (Ajax) Event Utility Dom Collection Drag & Drop Animation Logger Control Menu Control Slider Tree Control Calendar Control AutoComplete The Yahoo! User Interface (YUI) Library DHTML Windowing CSS Reset, Fonts, Grids TabView

Some Definitions

Definitions: DHTML / Ajax It’s NOT a specific technology

Definitions: DHTML / Ajax It’s NOT a specific technology It’s NOT inherently inaccessible

Rich Internet Applications (RIAs) are: Features and functionality of desktop apps online Built with Flash, JavaScript, Java, etc…

“Degree to which a system is usable without modification” (wikipedia)wikipedia Accessibility is

Accessibility = Availability Accessibility is Availability

Accessibility = Availability Accessibility is Availability Accessibility is Availability

Accessibility = Availability Accessibility is Availability Accessibility is Availability

How is “Richness” made accessible on the desktop?

Accessibility on the Desktop OS  API  AT Result: Nearly ubiquitous accessibility.

If it works on the desktop, what’s the problem on the Web?

The Bad News Only some info is passed to desktop API –Yes: Basic semantics (lists, headers) Basic i/o (page load, links) Basic interaction (form elements) –No: Compound elements (tab panels) Delayed and asynchronous i/o (ajax) Complex and detached interactions (drag-n-drop)

The Good News “One of W3C's primary goals is to make these benefits available to all people, whatever their... physical or mental ability. “

So how do we move forward?

Characteristics of Techniques Don’t make it worse Provide options Using existing conventions Move in the right direction Support emerging a11y tech

Four Techniques – Use Them All 1. Standards-based Development 2. Redundant Interfaces 3. Predictable Ports 4. W3C’s WAI ARIA (aka “Accessible DHTML”)

Standards-Based Development don’t miss the opportunity

“Getting It Right The Second Time” – matt sweeney

“Getting it Right the Second Time” 1. Use technology as designed H1, LI, P 2. Don’t corrupt layers of the stack Bad: class=“red-button” Bad: href=“#” and href=“javascript:” 3. Create platforms and EvolvabilityEvolvability Encapsulation, Flexibility, Mashups, Services, Portability 4. Preserve opportunity & availability

Approach 1: Standards-Based Development Build a strong foundation Progressive enhancement Unobtrusive enhancement Don’t pollute Best chance to be generous.

Standards-Based Development Example: Y!News Tab Panel Example: Tab-Panel box: complete

Standards-Based Development Example: Y!News Tab Panel Without CSS

Standards-Based Development Example: Y!News Tab Panel Without JavaScript

Standards-Based Development Example: Y!News Tab Panel Embrace simplicity: Anchored links and lists meaningful and available to all Links always work sometimes Hijax with Unobtrusive JSHijaxUnobtrusive JS Stretching semantics to provide clues; Microformats

Standards-Based Development Ex: Y!Photos Ratings & Tags

Standards-Based Development Example: Y!Games

Standards-Based Development Example: Y! Home Page

Standards-Based Development Benefits Should be doing this regardless “With the grain” of web technologies Truly available to all The foundation of better things A step toward a semantic web Here to stay (10+ years)

Standards-Based Development Drawbacks Doesn’t solve every problem Perceived overhead Unobtrusive JavaScript and Hijax are still less familiar techniques

Redundant Interfaces offer flexible interaction

Approach 2: Redundant Interfaces GUI and character input Direct and configuration-based Static entry and AutoComplete Tab and Arrow Keys

Approach 2: Redundant Interfaces Keyboard and mouse Esc. and Cancel Drag-drop and multi-page Ajax and HTTP

Redundant Interfaces Example: 1D Slider Sliders are redundant to text inputs. Progressively enhances direct manipulation.

Redundant Interfaces Example: 2D Slider

Redundant Interfaces Example: Date Selector

Redundant Interfaces Example: YUI Menu from Markup

Motion Protection – aqua.htmlhttp://developer.yahoo.com/yui/examples/container/panel- aqua.html Drag and Drop Constrained to Viewport Technology Protection – without JS and CSS without JS or CSS with Keyboard with Mouse Redundant Interfaces Example: YUI Panel from Markup

Redundant Interfaces Example: Yahoo! Homepage

Redundant Interfaces Ex: Drag-n-Drop vs. Edit Flow

Redundant Interfaces Benefits Better for everybody –Let users choose –Keyboard is important for ALL users Works today

Redundant Interfaces Drawbacks Insufficient communication Not “unified” Requires two experiences But not 2x effort! Can actually benefit development process

Faithful and Predictable Ports Faithful and Predictable Ports give users all of what they expect

Faithful and Predictable Ports: Faithful and Predictable Ports Support wholesale transfer of skills –Learnability –Discoverability Capture this moment in time –Completeness is critical

Faithful and Predictable Ports: Example: Full Selection Model

Faithful and Predictable Ports: Example: Full Keyboard Control

Example: Slider with keyboard control

Faithful and Predictable Ports: Example: Full Keyboard Control Click “close” or press Esc

Faithful and Predictable Ports: Benefits If we match users expectations, there’s a quantum leap in discoverability, comfort, and expectations for free.

Faithful and Predictable Ports: Drawbacks Isn’t always trivial –(but it’s build into YUI)

WAI ARIA W3C: “Accessible DHTML”

Rich Interfaces Require Sophisticated Definitions Rich Interfaces Require Sophisticated Definitions we can’t act on information we don’t have

“AT requires information about the semantics of specific portions of a document in order to present those portions in an accessible form.”

Approach 4: ARIA Communicate directly with desktop API IBM, now in W3C and open – – htmlhttp:// html Embeds “role” and “state” metadata –Uses namespace extensions to XHTML 2, but Techniques allow most functionality in HTML 4 documents, as of today

What’s the Virtual Buffer?

The Virtual Buffer and Script Handles basic script: –click, keypress, mouseover –For these, new content is exposed Ajax content isn’t natively exposed in reaction to these events For example, doesn’t know onreadystatechange

ARIA Architecture Overview

Base Roles –Input, textbox, select, range, section, sectionhead, window Widget Roles –Link, combobox, option, checkbox, checkboxtristate, radio, radiogroup, button, menuitemradio, menuitemcheckbox, progressbar, secret, separator, slider, spinbutton, textarea, textfield, tree, treegroup, treeitem, status, alert, alertdialog, dialog Structural Roles –Presentation, application, document, group, imggroup, directory, region, liveregion, log, grid, gridcell, tabcontainer, tab, tabpanel, tablist, table, td, th, rowheader, columnheader, list, listitem, menu, toolbar, menubar, menuitem, breadcrumbs Role Taxonomy

States and Adaptable Properties Module checked iconed disabled readonly multiselectable domactive zoom expanded selected pressed important required haseffect valueNew valueMax valueMin step invalid describedby labeledby hasparent haschild haspopup alternatestyle tabindex flowto flowfrom controls controlledby subpageof

“ARIA” Example: XHTML <span id="slider" class="myslider" role="wairole:slider" waistate:valuemin="0" waistate:valuemax="50" waistate:valuenow="33">

“ARIA” Example: HTML 4 <span id="slider" class=“foo bar slider valuemin-0 valuemax-50 valuenow-33" tabindex="0" >

ARIA Benefits Uses well-understood, powerful desktop API Map controls, events, roles & states directly Standard and predictable Progressive Enhancement

ARIA Drawbacks Requires recent-versions of AT Mozilla’s Firefox 1.5+ only today –But good things happening XHTML required for full power

We Need Your Help This is an important development –Thanks are due to IMB/Mozilla/W3C Becky Gibson Aaron Leventhal Our adoption –Multiplies their efforts –Reduces costs for small AT companies

Availability and Browser Support Availability and Browser Support Graded Browser Support

Binary Browser Support Do I need to support ___ on this project?

Graded Browser Support: Two Key Ideas (1) 1) We need a realistic definition of Support “Support” does not = “identical”. “Support” means “content is available” “Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web.”

Graded Browser Support: Two Key Ideas (2) 2) “Support” is not binary. There are grades of support.

Graded Browser Support: General Best Practice Three Grades of Browser Support C-grade support (core support, 2%) A-grade support (advanced support, 96%) X-grade support (the X-Factor, 2%)

ok

Final Thoughts It’s a win-win opportunity, and we’ll get there fastest together.

Thank you Photo Credits: – – –

We’re hiring! (Josie Arguada: )

Questions?

I don’t know.