HTML5 and WAI-ARIA Bruce Lawson, Opera Software HTML5 Study Groupt/ Tokyo / 18 November 2010
HTML5 hates accessibility?
Accessible Rich Internet Applications WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page. http://www.w3.org/TR/wai-aria/complete
How assistive technology works
roles, states, properties ● Role is what something is. <div role="navigation">, “tooltip” ● State is how something is at the moment (from pre- defined list): aria-checked = “true”, aria-required=”true” ● Property: aria-valuenow (of a slider), aria-describedby (points to a description)
HTML attributes don't validate in HTML4 <div role="navigation"> <input aria-required="true"> (but validate in HTML5!)
Built-in always beats bolt-on It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of objects. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by al owing the user agent to handle the object natively.
Remains useful for legacy content When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature. Legacy content may continue to use WAI-ARIA
Gotcha! ●Multiple <header>s allowed, but only one role=banner per page ●Multiple <footer>s al owed, multiple <address> allowed but only one role=contentinfo per page ●No <main> element ●Some screen reader naughtiness
Not everything is native to HTML5 WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the host language feature. WAI-ARIA should only be used in cases where the host language lacks the needed role, state, and property indicators.