Yahoo!%20Experiences%20with%20Accessibility%20in%20DHTML%20and%20RIA

1
Yahoo! Experiences with Accessibility in DHTML
and RIA
Web Builder 2.0 Las Vegas
Nate Koechley Senior Engineer Designer, Yahoo!
User Interface (YUI) Library Team Platform
Engineering Group Yahoo! Inc. Slides http//na
te.koechley.com/talks/2006/12/webbuilder/ Contact
http//yuiblog.com natek_at_yahoo-inc.com http//dev
eloper.yahoo.com/yui
2
Browser vs. Desktop
3
Web 1.0 vs. Web 2.0
4

• Sure, but how?

5
Study the History of the Desktop

• Adapted from Alan Coopers About Face 2.0 Book

6
idioms
Slider
Tree Control
AutoComplete
TabView
Menu Control
Calendar Control
compounds
Logger Control
DHTML Windowing
Drag Drop
Animation
Connection Manager (Ajax)
Event Utility
Dom Collection
CSS Reset, Fonts, Grids
7
Some Definitions
8
Definitions DHTML / Ajax

• Its NOT a specific technology

9
Definitions DHTML / Ajax

• Its NOT a specific technology
• Its NOT inherently inaccessible

10
Rich Internet Applications (RIAs) are

• Features and functionality of desktop apps online
• Built with Flash, JavaScript, Java, etc

11
Accessibility is

• Degree to which a system is usable without
  modification
• (wikipedia)

12
Accessibility Availability
Accessibility is Availability
13
Accessibility Availability
Accessibility is Availability
14
Accessibility Availability
Accessibility is Availability
15

• How is Richness made accessible on the desktop?

16
Accessibility on the Desktop

• OS ? API ? AT
• Result Nearly ubiquitous accessibility.

17

• If it works on the desktop, whats the problem on
  the Web?

18
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)

19
The Good News

• One of W3C's primary goals is to make these
  benefits available to all people, whatever their
  . . . physical or mental ability.
• http//www.w3.org/Consortium/Points/

20

• So how do we move forward?

21
Characteristics of Techniques

• Dont make it worse
• Provide options
• Using existing conventions
• Move in the right direction
• Support emerging a11y tech

22
Four Techniques Use Them All

• Standards-based Development
• Redundant Interfaces
• Predictable Ports
• W3Cs WAI ARIA
• (aka Accessible DHTML)

23

• Standards-Based Development

dont miss the opportunity
24
(No Transcript)
25
Getting It Right The Second Time
matt sweeney
26
Getting it Right the Second Time

• Use technology as designed
• H1, LI, P
• Dont corrupt layers of the stack
• Bad classred-button
• Bad href and hrefjavascript
• Create platforms and Evolvability
• Encapsulation, Flexibility, Mashups, Services,
  Portability
• Preserve opportunity availability

27
Approach 1Standards-Based Development

• Build a strong foundation
• Progressive enhancement
• Unobtrusive enhancement
• Dont pollute
• Best chance to be generous.

28
Standards-Based DevelopmentExample Y!News Tab
Panel

• Example Tab-Panel box complete

29
Standards-Based DevelopmentExample Y!News Tab
Panel

• Without CSS

30
Standards-Based DevelopmentExample Y!News Tab
Panel

• Without JavaScript

31
Standards-Based DevelopmentExample Y!News Tab
Panel

• Embrace simplicity
• Anchored links and lists
• meaningful and available to all
• Links always work
• sometimes Hijax with Unobtrusive JS
• Stretching semantics to provide clues
• Microformats

32
Standards-Based DevelopmentEx Y!Photos Ratings
Tags
http//nate.koechley.com/talks/2006/12/webbuilder/
ria_accessibility/photos-nocss.avi
33
Standards-Based DevelopmentExample Y!Games
http//nate.koechley.com/talks/2006/12/webbuilder/
ria_accessibility/games-nav.avi
34
Standards-Based DevelopmentExample Y! Home Page
http//nate.koechley.com/talks/2006/12/webbuilder/
ria_accessibility/da11y-fp-searchtabs.avi
35
Standards-Based DevelopmentBenefits

• 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)

36
Standards-Based DevelopmentDrawbacks

• Doesnt solve every problem
• Perceived overhead
• Unobtrusive JavaScript and Hijax are still less
  familiar techniques

37

• Redundant Interfaces

offer flexible interaction
38
Approach 2Redundant Interfaces

• GUI and character input
• Direct and configuration-based
• Static entry and AutoComplete
• Tab and Arrow Keys

39
Approach 2Redundant Interfaces

• Keyboard and mouse
• Esc. and Cancel
• Drag-drop and multi-page
• Ajax and HTTP

40
Redundant InterfacesExample 1D Slider

• http//developer.yahoo.com/yui/examples/slider/ind
  ex.html
• Sliders are redundant to text inputs.
• Progressively enhances direct manipulation.

http//nate.koechley.com/talks/2006/12/webbuilder/
ria_accessibility/Slider-basic.avi
41
Redundant InterfacesExample 2D Slider

• http//developer.yahoo.com/yui/examples/slider/rgb
  2.html

42
Redundant InterfacesExample Date Selector

• http//developer.yahoo.com/yui/examples/calendar/i
  ntl_japan/

43
Redundant Interfaces Example YUI Menu from
Markup

• http//developer.yahoo.com/yui/examples/menu/leftn
  avfrommarkup.html

44
Redundant Interfaces Example YUI Panel from
Markup

• Motion Protection
• http//developer.yahoo.com/yui/examples/container/
  panel-aqua.html
• Drag and Drop Constrained to Viewport
• Technology Protection
• http//yuiblog.com/blog/2006/09/22/yahoo-devday-sc
  hedule/
• without JS and CSS
• without JS or CSS
• with Keyboard
• with Mouse

45
Redundant Interfaces Example Yahoo! Homepage
http//nate.koechley.com/talks/2006/12/webbuilder/
ria_accessibility/frontpage-nojs.avi
46
Redundant InterfacesEx Drag-n-Drop vs. Edit Flow
http//nate.koechley.com/talks/2006/12/webbuilder/
ria_accessibility/my-change-layout.avi
47
Redundant InterfacesBenefits

• Better for everybody
• Let users choose
• Keyboard is important for ALL users
• Works today

48
Redundant InterfacesDrawbacks

• Insufficient communication
• Not unified
• Requires two experiences
• But not 2x effort!
• Can actually benefit development process

49

• Faithful and
• Predictable Ports

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

• Support wholesale transfer of skills
• Learnability
• Discoverability
• Capture this moment in time
• Completeness is critical

51
Faithful and Predictable PortsExample Full
Selection Model
http//nate.koechley.com/talks/2006/12/webbuilder/
ria_accessibility/photos-selection.avi
52
Faithful and Predictable PortsExample Full
Keyboard Control
53
Faithful and Predictable PortsExample Full
Keyboard Control

• Example
• Slider with
• keyboard control

http//nate.koechley.com/talks/2006/12/webbuilder/
ria_accessibility/slider-keyboard.avi
54
Faithful and Predictable PortsExample Full
Keyboard Control

• Click close or press Esc

55
Faithful and Predictable PortsBenefits

• If we match users expectations, theres a quantum
  leap in discoverability, comfort, and
  expectations for free.

56
Faithful and Predictable PortsDrawbacks

• Isnt always trivial
• (but its build into YUI)

57

• WAI ARIA

W3C Accessible DHTML
58

• Rich Interfaces Require
• Sophisticated Definitions

we cant act on information we dont have
59

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

http//www.w3.org/2006/09/aria-pressrelease.html
60
Approach 4 ARIA

• Communicate directly with desktop API
• IBM, now in W3C and open
• http//www.w3.org/TR/aria-roadmap/
• http//www.w3.org/WAI/PF/adaptable/HTML4/embedding
  -20060318.html
• Embeds role and state metadata
• Uses namespace extensions to XHTML 2, but
• Techniques allow most functionality in HTML 4
  documents, as of today

61
Whats the Virtual Buffer?
62
The Virtual Buffer and Script

• Handles basic script
• click, keypress, mouseover
• For these, new content is exposed
• Ajax content isnt natively exposed in reaction
  to these events
• For example, doesnt know onreadystatechange

63
ARIA Architecture Overviewhttp//www.w3.org/WAI/P
F/roadmap/
64
Role Taxonomy http//www.w3.org/TR/aria-role/

• 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

65
States and Adaptable Properties
Modulehttp//www.w3.org/WAI/PF/adaptable

• 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

66
ARIAExample XHTML
lthtml xmlnswairole"/w3.org/2005/01/wai-rdf/GUIRo
leTaxonomy" xmlnswaistate/w3.org/2005/07/aaa"
gt ltspan id"slider" class"myslider" role"wai
roleslider" waistatevaluemin"0" waistatevalu
emax"50" waistatevaluenow"33"gt lt/spangt
67
ARIAExample HTML 4
ltscript type"text/javascript" src"enable.js"gtlt/s
criptgt ltspan id"slider" classfoo bar
slider valuemin-0 valuemax-50
valuenow-33" tabindex"0" gtlt/spangt
68
ARIA Benefits

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

69
ARIA Drawbacks

• Requires recent-versions of AT
• Mozillas Firefox 1.5 only today
• But good things happening
• XHTML required for full power

70
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

71

• Availability and
• Browser Support

Graded Browser Support
72
Binary Browser Support

• Do I need to support ___ on this project?

73
Graded Browser SupportTwo 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.

74
Graded Browser SupportTwo Key Ideas (2)

• 2) Support is not binary. There are grades of
  support.

75
http//developer.yahoo.com/yui/articles/gbs/gbs.ht
ml
76
Graded Browser SupportGeneral 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)

77
http//developer.yahoo.com/yui/articles/gbs/gbs_br
owser-chart.html
78

• ok

79
Final Thoughts

• Its a win-win opportunity, and well get there
  fastest together.

80
Thank you.

• natek_at_yahoo-inc.com
• http//nate.koechley.com/talks
• http//developer.yahoo.com/yui
• http//yuiblog.com
• http//nate.koechley.com/blog
• Photo Credits
• http//www.flickr.com/photos/jacqueline-w/56107224
  /
• http//www.flickr.com/photos/grimreaperwithalawnmo
  wer/191890428/
• http//www.flickr.com/photos/jasonmichael/4126695/
  

81

• Were hiring!
• (Josie Arguada jaguada_at_yahoo-inc.com)

natek_at_yahoo-inc.com http//nate.koechley.com/talks
82

• Questions?

natek_at_yahoo-inc.com http//nate.koechley.com/talks
83

• I dont know.

natek_at_yahoo-inc.com http//nate.koechley.com/talks