Michael Cooper

• World Wide Web Consortium (W3C)
• Web Accessibility Initiative (WAI)
• Staff contact to:
  • Web Content Accessibility Guidelines Working Group
  • Protocols and Formats Working Group

About W3C / WAI

World Wide Web Consortium (W3C)

• Mission is to lead the Web to its full potential
• Consortium of industry members who use a consensus process to create interoperable standards
• Royalty-free standards mean anyone can implement

Web Accessibility Initiative (WAI)

• Activities: Guidelines, technology review, education and outreach, research and development
• Guidelines are widely referenced in corporate and national policies
• Authorized Translations facilitate worldwide adoption

WAI Guidelines

WAI Specifications

• Guidelines
  • Authors: Web Content Accessibility Guidelines (WCAG)
  • Authoring tool developers: Authoring Tool Accessibility Guidelines (ATAG)
  • Browser and assistive technology developers: User Agent Accessibility Guidelines (UAAG)
• Technologies
  • Accessible Rich Internet Applications (WAI-ARIA)

Designing for accessibility

• Accessibility is both a design and technology issue
• Some issues are principally design (e.g. color scheme, page layout)
• Some issues involve good use of the technology (e.g. proper encoding of features like headings, regions, lists, etc.)
• A good design reduces need for technological accessibility features, and makes it much easier to implement them when needed
• Universal Design: designing for all users makes a better experience even for those without identified special needs

Demo comparison of accessible and inaccessible site

The rich Web application challenge

• HTML 4 does not provide all the features developers want to use
• Developers create widgets using style and script
• More complex user interaction models
• Need to manage focus and selection

Basic steps to make application accessible

1. Explicitly hide decorative elements of the application design from AT (SC 1.1.1)
2. Define relationships amongst elements (SC 1.3.1)
3. Define meaningful reading sequence (SC 1.3.2) and navigation sequence (SC 2.4.3)
4. Provide ways to pause audio (SC 1.4.2) and movement (SC 2.2.2)
5. Make application keyboard accessible (SC 2.1.1) and don't trap keyboard (SC 2.1.2)
6. Ensure focus is visible (SC 2.4.7)
7. Don't change context unexpectedly when control receives focus (SC 3.2.1) or changes value (SC 3.2.2)
8. Give user interface components programatically determined name, role, states, properties, value (SC 4.1.2)

Enhance semantics

• Many of the steps to make rich applications accessible are basic design and implementation questions
• WAI-ARIA extends HTML to address the rich application challenge
• In particular WAI-ARIA allows to:
  • Define more precise relationships
  • Provide information about role, states, and properties
  • Define accessible name

ARIA materials

• Background information
  • WAI-ARIA Introduction
  • WAI-ARIA Primer
  • WAI-ARIA Roadmap
• Developer documents
  • WAI-ARIA Specification
  • WAI-ARIA User Agent Implementation Guide
• Authoring guidance
  • WAI-ARIA Authoring Practices

ARIA concepts

• Roles
  • role attribute
  • Value is name of role
• States and properties
  • aria-{propertyname} attributes
  • Value defined by each type
  • Some global, some apply to specific roles

ARIA taxonomy

Example: ARIA button

Example: Toggle button

Example	Code
Pick your poison Check all Biscuits Cake Candy Soda Tarts	<button onclick="exToggleCheckboxes()" role="button" aria-pressed="false"> Check all </button> function exToggleCheckboxes() { var curState = button.getAttribute("aria-pressed"); //for each checkbox if (curState == "false" || curState == "mixed") element.checked = true; else element.checked = false; }

Roles

1. Abstract roles—part of taxonony, not to be used
2. Widgets, e.g., checkbox, menu, progressbar, tabpanel, treegrid…
3. Document structure, e.g., heading, img, list, math, presentation…
4. Landmark roles, e.g., main, navigation, search…

Complex widgets

• Many more widget types supported
• Some have more complex interaction models than standard HTML controls
• A variety of states and properties support these widgets in different ways

Drag and drop

• aria-grabbed—whether object is selected for drag and drop, or is unselectable
• aria-dropeffect—possible effects (e.g., move, copy, etc.) when an object dropped in

Relationships

• aria-labelledby and aria-describedby—reference to alternative content elsewhere on the page
• aria-activedescendant—indicates the subcomponent that has the focus
• aria-owns and aria-controls—non-descendant elements that are part of or controlled by the object
• aria-posinset—position of an element in a set (when part of the set is elided)

Live regions

Live regions have content that updates without user intervention, e.g., stock tickers, chat programs

• aria-live
  • element has auto-updating content
  • "politeness" indicates how important to interrupt other tasks
• aria-relevant—what kind of update occurred
• aria-atomic—change to any part of element triggers update of entire element

WAI-ARIA is a Candidate Recommendation

Growth of WAI-ARIA

• WAI-ARIA is being formally integrated into HTML 5
• WAI-ARIA may need expansion to meet all HTML needs
• Expansion of taxonomy will make WAI-ARIA useful in other host languages
• SVG may use WAI-ARIA as a primary accessibility model
• Considering other host languages for future versions

Support for WAI-ARIA

• The mainstream desktop browsers provide substantial support
• Many assistive technologies support via platform Accessibility API
• WAI-ARIA is being incorporated into HTML 5
• Although WAI-ARIA is not a formal part of HTML 4 (validators will complain), it is recognized by user agents

Policy implementation of WAI-ARIA

• WAI-ARIA is a technology—in general, policies shouldn't require specific technologies
• Policies should reference WCAG 2.0
• WAI-ARIA is a "technique" to conform to WCAG 2.0
  • WCAG allows any "sufficient" technique
  • Different techniques may exist, choose one most appropriate to situation
  • Specific to technology; WAI-ARIA is one (recommended) technology to use

Beyond WAI-ARIA

WAI-ARIA doesn't address all aspects of rich internet applications, in particular, developer also needs to:

• Make elements focusable
  • tabindex attribute extended to all elements, not just links and form controls
  • tabindex={positive integer} defines tab position of element
  • tabindex=0 puts element in focus order, in default order
  • tabindex=-1 makes element script-focusable, but not in focus order
• Provide focus highlighting
  • Normally user agent highlights focus on links and form controls
  • If you have made other elements focusable, you need to show focus yourself
  • :focus pseudo-class often covers this
  • Sometimes necessary to use script

Mapping language features to accessibility APIs

• Accessibility APIs allow Assistive Technologies to interact with elements in a common way
• WAI-ARIA allows authors to provide features that will map to accessibility APIs, when host language support doesn't exist
• For the first time a formal mapping of HTML 5 elements to Accessibility API features is being prepared
• Allows the various user agents to provide a common approach
• The mapping of HTML elements works alongside the mapping of WAI-ARIA features to provide a complete model

Recognizing user intent

• Proliferation of devices that interact with Web content
  • Desktop and laptop computers
  • Smartphones
  • Tablets
• New modes of input drive these devices, particularly touch
• Touch gestures vary amongst devices, and aren't accessible to all
• Web content can't respond properly to all the potential gestures used to accomplish a particular action
• Need a way to respond to user intent, e.g., drag, scroll, zoom, next page, etc.
• Assistive technologies can send such events more effectively than mimicing device-specific touch events