Web 2.0

1. Web 2.0 W3C Roadmap for ARIA… and beyondRich SchwerdtfegerIBM Distinguished Engineer, Chair W3C WAI PF ARIA Subteam

2. Web 2.0 Paradigm Shift • Static Documents • New Content = Page Reload • Navigation limited to tab and click • Poor Usability for PWDs • Rich desktop-like experience through the browser • AJAX reduces page reloads • Tie UI to back-end services • Content aggregation from various resources (Mashups) • Social Collaboration • Potential for increased usability • Accessibility requires anunderstanding of GUI accessibility

3. What is the ARIA Roadmap? • A comprehensive gap analysis covering the interoperability between Web Content and ATs • Plans/technologies/specifications used to fill the gaps • A common strategy for W3C/Industry to collaborate on the problem

4. Accessibility API defines a standard contract between an application component and an assistive technology Role States Actions Caret Selection Text Hypertext Value Name Description Children Changes Relations A C C E S S I B L E Assistive Technology UI Component Data UI

5. In any object-based accessibility architecture, Assistive Technologies (AT)'s communicate with all objects to render an accessible view Frame Assistive Technology Menu Item Button Text Accessible Application Components

6. The Roadmap Promise • Competitive look/feel in Web Application widgets • Feel like an installed GUI Application • Improved usability through improved keyboard navigation • Full-function interoperability with assistive technologies

7. Why you need it? • Competitive look/feel should work like platform GUI • That kind of interaction in Web pages requires scriptingand styling • Scripting breaks communication with AT through APIs (unless…)

8. Problem Analysis shows opportunity for richer accessibility • HTML Accessibility depends on tag names (mixing content and presentation) • JavaScript creates custom widgets using HTML, user input, and CSS changing their meaning and purpose within a Web application • HTML lacks the accessibility meta data to support accessibility APIs for repurposed HTML content • Keyboard usability for PWDs is poor • Almost totally dependent on tabbing • Non anchors/form elements can’t receive focus (W3C HTML browser implementation oversight) • Users needs keyboard navigation and widget behavior like a GUI • User needs consistent navigation landmark semantics to reduce usability problem

9. The “Rich Internet Application Accessibility Problem” Repurposed HTML lacks semantics and ability to give focusexample: menu wanna be • Accessibility Problems • Can’t get here effectively with the keyboard • Don’t know a menu has been activated • Usability poor as does not behave like a menu • Usability Problem extends beyond accessibility • Alternative content is expensive

10. “The Contract” AT Access to Accessible Application Information as seen by Assistive Technology today(if the user could get to Top Stories)

11. Document Navigation Problem Dependence on excessive tabbing makes keyboard access unusable • Accessibility/Usability Problems • Portal keyboard usability a problem • To get to Market report you need to tab through every link on the page • Alternatives are a hack to code sections as headers restricting UI or assign access keys • Alternative is inconsistent across web sites • Alternative provides little semantic information • Use of keyboard short cut (Access Key) introduces device dependencies

12. Filling the gaps • XHTML 1.X (Extensibility through use of XML namespaces) • New States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties) • XHTML Role attribute module • Role attribute • Common landmarks (navigation, search, main, secondary, note, seealso, contentinfo, search, banner) • States (checked, expandable, selected) and Properties (describedBy, controllerFor, live) • TABINDEX modification allowing script to set focus on all elements with or without effecting tab order) • New Roles for Accesible Rich Internet Applications (WAI-ARIA Roles) • Role (button, tabpanel, grid, etc.) • Work with User Agents (Industry) make work with ATs • Map new meta data to Accessibility API • Implement (TABINDEX=-1) to support focus to non-anchor and form elements • <div tabindex=“-1” role = wairole:menuitem waistate:disabled=“true”> • Leading to broader industry curb cuts • SVG accessibility • Device Independence (Content adaptation for devices)

13. “The Contract” AT Access to Accessible Application New Information as seen by Assistive Technology • New accessibility Information

14. Role Taxonomy – Innovation allows for extensibility • Taxonomy of Roles • Widgets (grid, menu, spinbutton, etc.) • Structure (group, presentation, application, td, th) • RDF/OWL Class hierarchy • Roles define properties • Allow for custom componentry • Allow for future discovery • Allow for future adaptation

15. States and Properties for ARIAs • Typical widget states • checked, selected, disabled, currentvalue, expanded, etc. • Relationships • describeby, controls, flowto, labeledby, owns • New AJAX properties • live (off, polite, assertive, rude) • relevant (additions, deletions, text, all) • atomic • Miscellaneous • sort (ascending, descending) • setsize, posinset • Datatype • role • tabindex

16. Demo

17. Assembling the parts to help developer and user • Reusable, Accessible Component Libraries • Producing RIAs (Dojo, Rational JWL, Oracle) • W3C has HTML implementation technique for XHTML standard • Browser support • Firefox 1.5, 2.0 (Window-Eyes support) • Firefox 3.0 to support full spec. (Windows and Linux) • MS IE members have joined WAI PF working group • ATV support • Window-Eyes, JAWS 8 beta for FF 1.5/2.0 • ZoomText in progress • Tools • University of Illinois Mozilla/Firefox Accessibility Extension • Eventually – IBM Model-based authoring tools • IBM Research - RAVEN

18. Roadmap – Declarative Markup Opportunities • XForms – Inherent accessibility features results in smaller footprint • Standard data model from which many states and properties can be mapped automatically by the browser • Support for hint text, labels, descriptions • Declarative markup means less code goes to client • XML Events and Handlers – allow for named actions • Declarative way for defining events and handlers • Handlers can be named to map to action accessibility API • XHTML 2 access element • Offers device independent alternative to access key • Offers semantic navigation using roles • Allows for a degree of backward compatability

19. Current Legislation says You will turn off JavaScript and CSS!(JavaScript/CSS is on over 50% of all web pages) Not happening; usable access is too important!

20. JavaScript/CSS adoption impacts compliance strategy while standards/legislation adapt • Some Geos still follow WCAG 1.0 • Run with JavaScript and CSS disabled • Decision based on 1999 browser technology • U.S. 508 says run without CSS • Forcing some companies to provide alternative content • New 508/WCAG 2.0 focus on • Interoperability, usability vs. technology exclusion • Harmonization between web, rich GUI • Legislation temporarily impacting business decisions

21. Going beyond current W3C standards • Consistent keyboard style guide • Accessibility API Enhancements • Rich document editing • Exposure of taxonomy class information • Personalization • New IMS Global Learning Consortium standards (ACCMD and ACCLIP specs.)

22. References • W3C Roadmap and Standards • http://www.w3.org/wai/pf • Examples • http://webally.com • http://www.weba11y.com/AjaxDemo/sample.html • http://developer.mozilla.org/en/docs/Accessible_DHTML • http://firefox.cita.uiuc.edu/test/dhtml/src/index.php • Tooling in development • U. of Illinois extension http://firefox.cita.uiuc.edu/dhtml/download.php • RAVENhttp://www.alphaworks.ibm.com/tech/raven • WAI Role Taxonomy extension tool • http://test2.ubapps.com/RolesWebApp/roles/start

23. Thank you