Web 2.0 Accessibility Section 508 Coordinators Training Conference

1. Web 2.0 AccessibilitySection 508 Coordinators Training Conference Rich Schwerdtfeger DE, SWG Accessibility Strategy and Architecture Chair: W3C WAI-ARIA standards effort

2. Early Assistive Technology – December 1991 Byte Magazine

3. Early innovation paved way for first accessibility API • Convert what was drawn to text model • Reverse engineered semantics • Reverse engineering led to inaccuracies • Learned what author needed to provide “Reading the Tea Leaves”

4. First Accessibility APIs – Author Supplied Accessibility • 1995 Microsoft Active Accessibility • 1998 Java Accessibility API (Sun and IBM) • Importance of Interoperability Frame Assistive Technology Menu Item Button Text Accessible Application Components

5. 1997 Accessibility Divergence caused Problems for Web Access • Web – Rudimentary access • Keyboard access – not usability • Don’t change HTML • Anything we don’t understand prohibit • No planning for future developer innovation • Rich Desktop platform accessibility • Real issue is interoperability with assistive technology • Development of richer platform accessibility APIs • Leverage usability of desktop applications to manage information • Keyboard accessible and usable • Inability to address web interoperability causing web accessibility criteria to hurt accessibility

6. Web 2.0 Paradigm Shift: Opportunity for Usable Access • Static Documents • New Content = Page Reload • Navigation is mouse centric • Tab and Click Navigation • Can be accessible but Poor Usability for People with Disabilities • Rich desktop-like experience • Ajax incremental updates • UI tied to back-end services • Rich Desktop experience through use of CSS and JavaScript • Rich Desktop allows for information management – increased usability for the web • Accessibility requires an understanding of desktop accessibility

7. 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

8. Problem Analysis shows opportunity for richer accessibility • HTML Accessibility depends on tag names (mixing content and presentation) • JavaScript creates custom widgets usingHTML, 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. WAI-ARIA – delivers semantics and desktop keyboard functionality to provide full interoperability with ATs’ • Typical widget states • aria-checked, aria-selected, aria-disabled, aria-currentvalue, aria-expanded, etc. • Relationships • aria-describeby, aria-controls, aria-flowto, aria-labelledby, aria-owns • New AJAX Live Region properties • aria-live (off, polite, assertive) • aria-relevant (additions, deletions, text, all) • aria-atomic • Drag/Drop • aria-grabbed • aria-dropeffect • Miscellaneous • aria-sort (ascending, descending) • aria-setsize, aria-posinset, aria-level • Role (widgets and navigational landmarks) • Widgets: (tree, grid, button, checkbox, menu, dialog, etc.) • Structural: (directory, list, header, etc.) • Landmarks: (main, navigation, complementary, banner, contentinfo, form, search, etc.) • Tabindex <div tabindex=“-1” role = “menuitem” aria-disabled=“true”>

10. Web application roles and regional landmarks <div role=“navigation” aria-labelledby=“hdr”> <div role=“header”” aria-level=“1” id=“hdr”>My Quicklinks</div> <div role=“search”> <div role=“tablist”> <div role = “tab”> Featured </div>… </div> <div role=“tabpanel” <div role=“main”> <div role=“complementary” … > </div>

11. Tree Widget Usability Comparison WCAG 1.0/ current 508 Style Accessibility WCAG 2.0/(potential 508 refresh) Style Accessibility with ARIA role = “treeitem” aria-expanded=“false” aria-level=“2” aria-checked=“false” aria-posinset=“1” aria-setsize=“4” Name=“PJ111” img alt=“folder” ---------- Keyboard like desktop Tree widget Anchor tells is a link Name=PJ11 img alt=“folder” ---------- document “tabbing” + + “link folder PJ111” = = “Closed Folder PJ111” “Closed Folder one of four Depth 2” “unchecked”

12. CSS and Compliance through Equivalent Facilitation • Web is too complex for user defined style sheets • Disabling CSS breaks the usability of Web 2.0 applications • Provide low vision support with CSS enabled to meet • Support system colors / high contrast mode • Respond to font resizing - no fixed font sizes

13. WAI-ARIA – Most important accessibility advance in a decade • Brings Accessibility/Usability of Desktop to the Web • Allows for full interoperability with assistive technology • Key technology needed to support WCAG 2 and 508 • Web 2.0 applications, when properly enabled, Benefit ALL Users

14. Backup

15. References • W3C WAI-ARIA • http://www.w3.org/TR/wai-aria/ • Examples, Best Practices, Education • WAI-ARIA Authoring Practices • CodeTalks • More on WAI-ARIA • Dojo - http://www.dojotoolkit.org/ • Dojo Book http://docs.dojocampus.org/ • Widgets - http://docs.dojocampus.org/dijit/index • Tooling in development • U. of Illinois Firefox accessibility extension • Firebug ARIA Extension • AccProbe Firefox test tool • Open Ajax Alliance Accessibility Tools Task Force

16. Interoperability With WAI-ARIA Before HTML Browser Accessibility API Assistive Technology Document elements Basic form elements Alt text Mouse centric – limited keyboard With WAI-ARIA HTML ARIA Browser Accessibility API (Richer) Assistive Technology UI Types (roles) Properties Landmarks Drag/Drop Full Desktop keyboard usability