Transcript Yahoo! Experiences with Accessibility (a11y), DHTML, and Ajax in Rich Internet Applications Nate Koechley [email protected] http://nate.koechley.com/blog Refresh 06 Orlando, Florida2006.11.16

Yahoo! Experiences with
Accessibility (a11y), DHTML, and Ajax
in Rich Internet Applications
Nate Koechley
[email protected]
http://nate.koechley.com/blog
Refresh 06
Orlando, Florida
1
2006.11.16
Hello, World
• Nate Koechley
– Charter member of Web Development team
– In the trenches and in management
– Yahoo! User Interface (YUI) Library team
• Senior Front-End Engineer, Technical Evangelist,
Design Liaison, YUIBlog Editor
• Responsible for Yahoo! Browser Support specs
• Role: Strategy and Direction
2
What’s Happening?
4
Browser vs. Desktop
5
Web 1.0 vs. Web 2.0
6
7
“Getting It Right The
Second Time”
– matt sweeney
8
Getting it Right the Second Time
• Use technology as designed
H1, LI, P
• Not corrupt layers of the stack
Bad: class=“red-button” and href=“#”
• Create platforms. Evolvability
– Encapsulation, Flexibility, Mashups,
Services, Portability
• Preserve opportunity & availability
9
How do you move to RIAs?
10
Definitions
13
Definitions:
DHTML / Ajax
• Is NOT a specific technology
14
Definitions:
DHTML / Ajax
• Is NOT a specific technology
• Is NOT inherently inaccessible
15
Definitions:
Rich Internet Applications (RIAs)
• RIAs are:
– web apps with features and functionality of
traditional desktop applications
– can be created in various languages: Flash,
JavaScript, Java
• today’s talk is focused on JavaScript RIAs
16
Definitions:
Accessibility
• Accessibility is:
– “A general term used to describe the degree
to which a system is usable by as many
people as possible without modification”
(cite: wikipedia)
• Often, our focus is on enabling screenreaders specifically
– However, the resulting work in generally
more far-reaching
17
Accessibility = Availability
Accessibility is
Availability
18
Accessibility = Availability
Accessibility is
Availability
19
Accessibility = Availability
Accessibility is
Availability
20
“Rich” isn’t new, so what
about desktop accessibility?
21
Accessibility on the Desktop
• OS provides a11y API
– Microsoft’s Active Accessibility 2.0 (MSAA)
– Sun’s Java Access Bridge
– Accessibility Toolkit for Linux (ATK)
• Assistive Technology talks to OS API
• Result: nearly ubiquitous a11y
22
So desktop accessibility is
nearly ubiquitous, but what about
web accessibility?
23
Accessibility on the Web (1)
• Some information is provided to the
desktop API
– The Document Object Model (DOM)
provides static information via semantic
elements and attributes
• Form elements announce focus
(sometimes)
24
http://www.w3.org/Consortium/Points/
“One of W3C's primary goals is to make
these benefits available to all people,
whatever their hardware, software,
network infrastructure, native language,
culture, geographical location, or physical
or mental ability. “
25
Accessibility on the Web (2)
• So the picture isn’t fully bleak
… but the depth of necessary information is
missing:
• Role, state, actions, caret, selection, children,
relations, changes…
– Input and output communication is missing
too:
• Keyboard, focus, blur, change, updates.
• Clunky, see data table and speadsheets
26
So how can we move
forward?
27
Characteristics of Techniques
• Don’t make it worse
• Provide alternatives
• Learn from other technologies
• Prepare for when a11y tech improves
• Support improvement of a11y tech
28
Four Techniques – Use Them All
1. Standards-based development
2. Redundant interfaces
3. Faithful and Predictable Ports
4. WAI ARIA aka “Accessible DHTML”
29
Standards-Based
Development
Don’t miss the opportunity
30
Approach 1:
Standards-Based Development
• Overview and Definition
• Create and stand upon a strong foundation
• Subsequent layers enhance meaningful and
structured markup
• Progressive and unobtrusive enhancement
• Don’t contaminate the neighborhood
• Be generous – it’s your last chance!
31
Standards-Based Development
Example: Y!News Tab Panel
• Example: Tab-Panel box: complete
32
Standards-Based Development
Example: Y!News Tab Panel
• Example: Tab-Panel box: no CSS
33
Standards-Based Development
Example: Y!News Tab Panel
• Example: Tab-Panel box: no JavaScript
34
Standards-Based Development
Example: Y!News Tab Panel
• Notice:
• Tab box is really anchored links and lists –
well marked up content, available to all
• Unobtrusive JavaScript doesn’t Hijax links
when it shouldn’t
• Stretching semantics to provide clues
• Microformats enrich date, and provide
predictable hooks for add-ons
35
Standards-Based Development
Ex: Y!Photos Ratings & Tags
http://nate.koechley.com/talks/2006/11/refresh06/RIA_Accessibility/photos-nocss.avi
36
Standards-Based Development
Example: Y!Games
http://nate.koechley.com/talks/2006/11/refresh06/RIA_Accessibility/games-nav.avi
37
Standards-Based Development
Example: Y! Home Page
http://nate.koechley.com/talks/2006/11/refresh06/RIA_Accessibility/da11y-fp-searchtabs.avi
38
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)
39
Standards-Based Development
Drawbacks
• Doesn’t solve every problem
• Perceived overhead
• Unobtrusive JavaScript and Hijax are still
less familiar techniques
– Be careful not to step on event handlers
– Only trap clicks when appropriate
– Server must reply to both partial and
complete requests from the client
40
Redundant Interfaces
Offer flexible interactions
41
Approach 2:
Redundant Interfaces
• Overview and Definition
• Multiple means of input
• GUI input vs. char input
• Direct movement of objects vs. configuration-based
movement
• Plain text vs. Auto Complete
• Tab vs. Arrow Keys
42
Approach 2:
Redundant Interfaces
• Overview and Definition
• Multiple means of manipulation
• Keyboard vs. Mouse
• Esc vs. Cancel
• Drag-drop vs. form-based
• Ajax vs. HTTP
43
Redundant Interfaces
Example: 1D Slider
http://developer.yahoo.com/yui/examples/slider/index.html
• Simple support for vertical and horizontal
sliders as a direct-manipulation
alternative to input boxes
• Enhances the basic input box, but need
not replace it.
http://nate.koechley.com/talks/2006/11/refresh06/RIA_Accessibility/Slider-basic.avi
44
Redundant Interfaces
Example: 2D Slider
http://developer.yahoo.com/yui/examples/slider/rgb2.html
45
Redundant Interfaces
Example: Date Selector
http://developer.yahoo.com/yui/examples/calendar/intl_japan/
46
Redundant Interfaces
Example: YUI Menu from Markup
http://developer.yahoo.com/yui/examples/menu/leftnavfrommarkup.html
47
Redundant Interfaces
Example: YUI Panel from Markup
• Motion Protection
– http://developer.yahoo.com/yui/examples/con
tainer/panel-aqua.html
• Technology Protection
– http://yuiblog.com/blog/2006/09/22/yahoodevday-schedule/
48
Redundant Interfaces
Example: Yahoo! home page
http://nate.koechley.com/talks/2006/11/refresh06/RIA_Accessibility/frontpage-nojs.avi
49
Redundant Interfaces
Ex: Drag-n-Drop vs. Edit Flow
http://nate.koechley.com/talks/2006/11/refresh06/RIA_Accessibility/my-change-layout.avi
50
Redundant Interfaces
Benefits
• Better for everybody
– Keyboard is important for ALL users
– Let users choose from multiple task flows
• Transfer the complete set of expectations
from the desktop to the browser
• Works today
51
Redundant Interfaces
Drawbacks
• Insufficient communication with
accessibility APIs on the desktop
• Dual experiences/interfaces may
pressure goals of parity
• Requires development of two
experiences
• But not 2x effort!
• Can actually benefit development
process
52
Faithful and Predictable
Preserve the illusion
53
Faithful and Predictable Ports:
Faithful and Predictable Ports
• Overview and Definition
• We must capture this moment in time
• Learnability
• Discoverability
• Completeness is critical
54
Faithful and Predictable Ports:
Example: Full Selection Model
http://photos.yahoo.com/
http://nate.koechley.com/talks/2006/11/refresh06/RIA_Accessibility/photos-selection.avi
55
Faithful and Predictable Ports:
Ex: Full Keyboard Control
56
Faithful and Predictable Ports:
Ex: Full Keyboard Control
Example:
Slider fortified
with keyboard
http://nate.koechley.com/talks/2006/11/refresh06/RIA_Accessibility/slider-keyboard.avi
57
Faithful and Predictable Ports:
Ex: Full Keyboard Control
58
Faithful and Predictable Ports:
Benefits
• More options for everybody
• Better discoverability
• Better usability
• Supports many working styles
• Establish the new platform
59
Faithful and Predictable Ports:
Drawbacks
• Isn’t always easy
• Seems heavier and/or more complex
• Not always the path of least resistance
60
WAI ARIA
“Accessible DHTML”
61
Rich Interfaces Require
Sophisticated Definitions
62
“Assistive technologies … requires
information about the semantics of specific
portions of a document in order to present
those portions in an accessible form.
For example, to provide reliable access to a
form element, a tool must also be able to
recognize the state of that element (for
example, whether it is checked,
disabled, focused, collapsed, or hidden).”
http://www.w3.org/2006/09/aria-pressrelease.html
63
Approach 4:
“Accessible DHTML”
• Overview and Definition
– IBM technology, now in W3C and open
• http://www.w3.org/TR/aria-roadmap/
• http://www.w3.org/WAI/PF/adaptable/HTML4/embedding20060318.html
– Allows embedded role and state metadata in
(X)HTML documents
– Uses namespace extensions to XHTML 2, but
• Techniques allow most functionality in HTML 4 documents,
as of today
– Communicate directly with the desktop API
64
The Virtual Buffer
• Screen readers “scrape” a page into a
Virtual Buffer.
• Facilitates knowledge of the page
– “20 links”, “list, 14 items”, “four headers”
65
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
66
Content has changed!
• focus on updated content
– tabindex -1
• Omits from tab order
• Not fully cross-browser
• Works, but unsophisticated
67
Role Taxonomy for Accessible Adaptable
Applications
http://www.w3.org/WAI/PF/GUI/
68
States and Adaptable Properties Module
http://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
69
“Accessible DHTML”
Example: XHTML
<html xmlns:wairole="/w3.org/2005/01/wairdf/GUIRoleTaxonomy#"
xmlns:waistate=“/w3.org/2005/07/aaa">
<span id="slider" class="myslider"
role="wairole:slider"
waistate:valuemin="0"
waistate:valuemax="50"
waistate:valuenow="33"> </span>
70
“Accessible DHTML”
Example: HTML 4
<script type="text/javascript"
src="enable.js"></script>
<span id="slider"
class="myslider myselector2
slider
valuemin-0 valuemax-50 valuenow-33"
tabindex="0" >
</span>
71
“Accessible DHTML”
Benefits
• Utilizes powerful and well-understood
desktop API
• Map controls, events, roles and states
directly to powerful and well-understood
desktop accessibility APIs
• Standard and predictable enrichment of
markup
• Allows ARIA on top of RIA
72
“Accessible DHTML”
Drawbacks
• Requires recent-version of assistive
technology software (e.g., screen reader)
• Only works in Mozilla’s Firefox 1.5+ today
– Not in Microsoft’s IE7
• XHTML required for full power
– HTML does not allow multiple states, for
example
73
Need Your Help
• This is an important development
– Thanks for IMB/Mozilla/W3C
• Becky Gibson
• Aaron Leventhal
– We can thank them with adoption and a
steady commitment
– We can help these small companies.
74
Availability and Browser
Support
“Graded Browser Support”
75
The Dirty Truth
• The Web is the most hostile software
engineering environment imaginable.
– Douglas Crockford
76
Binary Browser Support
• Do I need to support ___ on this project?
77
Graded Browser Support:
Two Key Ideas (1)
1) Support != Same
Expecting two users using different browser software
to have an identical experience fails to embrace or
acknowledge the heterogeneous essence of the
Web.
78
Graded Browser Support:
Two Key Ideas (2)
2) Support must not be binary!
Our primary goal is availability.
– Don’t exclude anyone
– Welcome all visitors
79
http://developer.yahoo.com/yui/articles/gbs/gbs.html
80
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%)
81
http://developer.yahoo.com/yui/articles/gbs/gbs_browser-chart.html
82
Final Thoughts
• It’s possible to give the new richness to
everybody, and morally correct.
– More users + good PR = win win
• There’s no excuse for not doing this, plus
it’s not that hard.
• Together we’ll get there faster.
83
Thanks!
nate.koechley.com/talks/2006/11/refresh06/RIA_Accessibility/
• Nate Koechley:
– [email protected] | [email protected]
– http://nate.koechley.com/blog
• Yahoo! Developer Network and Y! UI Blog:
–
–
–
–
–
http://developer.yahoo.com
http://developer.yahoo.com/yui
http://developer.yahoo.com/ypatterns
http://www.yuiblog.com
http://groups.yahoo.com/group/ydn-javascript
• Creative Commons Photos from Flickr:
– http://www.flickr.com/photos/tgray/48830193/
– http://www.flickr.com/photos/macwagen/90472902/
– http://www.flickr.com/photos/zen/157658496/
84
We’re Hiring!
Josie Aguada: [email protected]
Usual suspects:
JavaScript, PHP, CSS, HTML, ActionScript…
85