Yahoo! Experiences with Accessibility, DHTML, and Ajax in Rich Internet Applications

1. Yahoo! Experiences with Accessibility, DHTML, and Ajax in Rich Internet Applications CSUN, March 23rd, 2006 Victor Tsaran – Accessibility Project Manager, Yahoo! Inc. Nate Koechley – Senior Engineer & Design Liaison, Yahoo! Inc.

2. Agenda • Changing Landscape • Definitions • Four Approaches • Standards-based development • Redundant interfaces • Thorough, fortified interfaces • “Accessible DHTML” • Looking Ahead

3. About Us • Victor Tsaran • Accessibility Project Manager • Nate Koechley • Senior Frontend Engineer • Technical Architect and Design Liaison • Presentation Platform Team

4. What’s Happening?

5. Browser vs. Desktop

6. Web 1.0 vs. Web 2.0

7. Yahoo’s “Alan Cooper” Model

8. Definitions

9. Definitions:DHTML • DHTML is • markup and style made interactive and dynamic through script • Generally, DHTML is JavaScript modifying CSS, HTML and the DOM • DHTML is not • a specific technology • inherently inaccessible • new

10. Definitions:AJAX / Ajax • Asynchronous JavaScript and XML • the ability to talk to the server without tearing down the existing page • the ability to update part of the page • Ajax is not • a specific technology • inherently inaccessible • new • No server requests = it’s not Ajax • AJAX is a subset of Ajax

11. Definitions:Rich Internet Applications (RIAs) • Rich Internet Applications are: • web apps with features and functionality of traditional desktop applications • usable from any internet terminal – no installation required • can be created in various languages: Flash, JavaScript, Java • today’s talk is focused on JavaScript RIAs

12. 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 screen-readers specifically • However, the resulting work in generally more far-reaching

13. What about Desktop Accessibility?

14. Accessibility on the Desktop • Through various APIs… • Microsoft’s Active Accessibility (MSAA) • Sun’s Java Access Bridge • Accessibility Toolkit for Linux (ATK) • …Software communicates to the operating system, which communicates with assistive technology. • Highly effective, resulting in nearly omnipresent accessibility.

15. But what about web accessibility?

16. 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 • But…

17. Accessibility on the Web (2) • … but the depth of necessary information is missing • Role, state, actions, caret, selection, children, relations, changes… • And so are inputs and outputs • keyboard, focus, blur, change, updates.

18. So how can we move forward?

19. Four Techniques – Use ‘em All • Standards-based development • Redundant interfaces • Thorough, fortified interfaces • “Accessible DHTML”

20. Approach 1:Standards-based development • Overview and Definition • Subsequent layers enhance meaningful and structured markup • Progressive and unobtrusive enhancement • Make each layer a strong foundation • Don’t corrupt neighboring layers

21. Approach 1:Standards-based development • Examples • 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

22. Approach 1:Standards-based development • Example: Tab-Panel box: complete

23. Approach 1:Standards-based development • Example: Tab-Panel box: no CSS

24. Approach 1:Standards-based development • Example: Tab-Panel box: no JavaScript

25. Approach 1:Standards-based development • Benefits • Should be doing this regardless • Truly available to all • The foundation of better things • Works “with the grain” of web technologies • A step toward a semantic web

26. Approach 1: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

27. Approach 2:Redundant interfaces • Overview and Definition • Multiple means of input • GUI input vs. alphanumeric input • Direct movement of objects vs. form-based movement • Multiple means of manipulation • Keyboard vs. Mouse • Esc vs. Cancel • Drag-drop vs. form-based

28. Approach 2:Redundant interfaces • Example, 1D Slider Input • 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.

29. Approach 2:Redundant interfaces • Example, 2D Slider Input

30. Approach 2:Redundant interfaces • Example: Calendar Date Selector

31. Approach 2:Redundant interfaces • Benefits • Better for everybody • Keyboard is important for ALL users • Provide multiple familiar task paths • Transfer the complete set of expectations from the desktop to the browser

32. Approach 2:Redundant interfaces • Drawbacks • Cannot fully communicate with the desktop’s accessibility APIs

33. Approach 3:Thorough, fortified interfaces • Overview and Definition • Now is the time to lay a new foundation • Libraries and platforms must support all comers • Not just the mouse, not just the keyboard • Not just one key, but all keys • Must offer a faithful and complete experience

34. Approach 3:Thorough, fortified interfaces • Examples • Menu

35. Approach 3:Thorough, fortified interfaces • Example: Slider w/ Keyboard Controls • keyboard in addition to mouse controls

36. Approach 3:Thorough, fortified interfaces • Benefits • More options for everybody • Supports many working styles • Establish the new platform • My prediction: new platform will last much longer than the 10 years of the previous platform

37. Approach 3:Thorough, fortified interfaces • Drawbacks • Isn’t easy • Clients don’t always notice • Requires personal integrity and commitment • Seems more complete and heavy

38. Approach 4:“Accessible DHTML” • Overview and Definition • IBM technology, now in W3C and open • http://www.w3.org/WAI/PF/adaptable/HTML4/embedding-20060318.html • Allows embedded role and state metadata in 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

39. Approach 4:“Accessible DHTML” • Examples: XHTML 2 <html xmlns:wairole="/w3.org/2005/01/wai-rdf/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>

40. Approach 4:“Accessible DHTML” • Examples: HTML 4 <script type="text/javascript" src="enable.js"></script> <span id="slider" class="myslider myselector2 slider valuemin-0valuemax-50valuenow-33" tabindex="0" ></span>

41. Approach 4:“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 • Enriches markup in standard way

42. Approach 4:“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 IE 7, or others • XHTML required for full power • HTML does not allow multiple states, for example • Emerging technology

43. Looking ahead… • What is at risk if we don’t standardize on an accessible platform?

44. Open Questions • Is there always an alternative to a mouse-based experience? (for example, with the mouse I can reorder the toolbars in MSWord. I’m not sure if this is possible without a mouse, or even necessary.) • Partial-page updates remain difficult to communicate to the screen reader’s DOM buffer.

45. More Information • Nate Koechley – • natek@yahoo-inc.com • http://nate.koechley.com/blog • Victor Tsaran • vtsaran@yahoo-inc.com • Yahoo! Developer Network and Y! UI Blog: • http://developer.yahoo.net • http://developer.yahoo.net/yui • http://developer.yahoo.net/ypatterns • http://groups.yahoo.com/group/ydn-javascript • http://www.yuiblog.com

46. END OF TALK • NOTE: Remaining slides are candidates for inclusion, but will likely be dropped from the presentation.

47. Slider • Slider Control • Simple support for vertical and horizontal sliders as a direct-manipulation alternative to input boxes • Simple API to script onChange behavior • Support for smooth or graduated slider action • Built-in support for click-to animation of slider • Builds on top of: • Drag and Drop Utility • Position Utility • Animation Utility (optional)

48. Slider • Slider: Beyond the Obvious • Look to desktop applications for inspiration for slider applications • Generally, consider a slider as an alternative to entering values that run along a continuum; for example: • RGB values for color selection • Amplitude of different variables in a prioritization algorithm • Simple integer continuum

49. Slider

50. Calendar • Calendar • Simple date selection widget that can be implemented with only a few lines of code • Fully client-side calendar navigation • Built-in multi-select or single-select capability, in single or two-up views • Out-of-the-box rich UED-approved look-and-feel standard across the Yahoo! Network • Support for advanced implementations such as: • localization • blacked-out date sets • custom holiday formatting