® IBM Software Group © 2006 IBM Corporation W3C Roadmap for ARIA … and beyond Rich Schwerdtfeger IBM Distinguished Engineer, Chair W3C WAI PF ARIA Subteam

IBM Software Group Web 2.0 Paradigm Shift  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 an understanding of GUI accessibility  Static Documents  New Content = Page Reload  Navigation limited to tab and click  Poor Usability for PWDs

IBM Software Group 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

IBM Software Group Accessibility API defines a standard contract between an application component and an assistive technology Assistive Technology Assistive Technology Role States Actions Caret Selection Text Hypertext Value Name Description Children Changes Relations ACCESSIBLEACCESSIBLE UI Component Data UI

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

IBM Software Group 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

IBM Software Group Why you need it?  Competitive look/feel should work like platform GUI  That kind of interaction in Web pages requires scripting and styling  Scripting breaks communication with AT through APIs (unless…)

IBM Software Group 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

IBM Software Group Repurposed HTML lacks semantics and ability to give focus example: 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 The “Rich Internet Application Accessibility Problem”

IBM Software Group Information as seen by Assistive Technology today (if the user could get to Top Stories) “The Contract” AT Access to Accessible Application Role (what it is) May throw this away State NameNon - deterministic Actions Parent

IBM Software Group 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 Document Navigation Problem

IBM Software Group 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   Leading to broader industry curb cuts  SVG accessibility  Device Independence (Content adaptation for devices)

IBM Software Group New Information as seen by Assistive Technology “The Contract” AT Access to Accessible Application  New accessibility Information RoleMenu Item StateSelected NameTop Stories ActionsNone ParentMenu

IBM Software Group 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

IBM Software Group 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

IBM Software Group Demo

IBM Software Group 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

IBM Software Group 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

IBM Software Group 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!

IBM Software Group 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

IBM Software Group 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.)

IBM Software Group References  W3C Roadmap and Standards   Examples      Tooling in development  U. of Illinois extension  RAVEN  WAI Role Taxonomy extension tool 

® IBM Software Group © 2006 IBM Corporation Thank you