Warning:
This wiki has been archived and is now read-only.
ARIAIntegration
Issue: Integration of WAI-ARIA into HTML5
Status: Dependency - Integrating Role and State Metadata in HTML5 for WAI-ARIA support.
Contents
- 1 Issue: Integration of WAI-ARIA into HTML5
- 1.1 Formal Request from the Protocols & Formats Working Group
- 1.2 Related Resources
- 1.3 ARIA & AJAX Examples & Test Suites
- 1.4 Proposals for Integrating ARIA into HTML5
- 1.5 Native Accessibility Features of HTML5
- 1.6 Default role Values for HTML Elements and Built-in Accessibility
- 1.7 Tests of Built-in Role Coverage
- 1.8 Email
Formal Request from the Protocols & Formats Working Group
Integrating ARIA into HTML5: Roles, States and Explicit Markup
Opening thoughts on WAI-ARIA in HTML5 (PFWG)
Note: This is high level, but we thought we should say something. We continue to work on some more concrete ideas. None of this is cast in concrete. But this gives you an idea of where we are coming from. -- Al Gilman, chair, Protocols & Formats WG (PFWG)
We look forward to working with the HTML working group on ensuring accessibility support for rich internet applications in HTML 5.
We are finding that developers, are creating countless custom controls in their Web 2.0 applications which require the use of ARIA. ARIA is starting to be incorporated in Web 2.0 applications and widget libraries. Early adopters like IBM, AOL, and SAP are developing ARIA supporting widget libraries like Dojo. ARIA provides needed semantics to enable a user agent to support platform accessibility APIs, allowing for full interoperability with assistive technologies. Furthermore, ARIA addresses keyboard gaps in HTML needed to make these applications accessible. For these reasons it is essential that HTML 5 provide for backward compatability. Vehicles for supporting ARIA states and properties, such as namespaces or a data dictionary linked through the html:html.profile attribute are on the table for discussion.
The working group likes the idea of having built in semantics in HTML and in particular would prefer to have common document elements, such as widgets built in to the markup. This reduces download size and the effort required to make a web page accessible. For these reasons, we would promote the use of such markup over the ARIA approach. That said, we do believe that HTML 5 will not incorporate document elements for all those included in the ARIA role taxonomy nor will it include all the states and properties. For these reasons, backward compatability for the ARIA specifications is a must.
Outside of ARIA we would like HTML 5 to support the XHTML access element. The access element supports badly needed semantics for access key navigation but without the need for device dependency restrictions. Additionally, if accessibility features are being removed from HTML 4.01, such as longdesc or alt text, we need to make sure that the base markup supports the appropriate equivalent functionality in terms of interoperability with assistive technologies. For example, ARIA provides a describedby property which establishes a relationship to descriptive text on the page (prose or text shown in response to a user action) which may be an appropriate alternative.
To summarize, our goals for HTML 5 are as follow:
- Support for issues highlighted in Table: 1 of the ARIA Roadmap
- Backward compatability to ARIA, including the role attribute.
- Allow for full interoperability with assistive technologies
- A preference for access to accessibility information via the DOM
- Reduced efforts by authors to support assistive technologies
- Support for the access element or a version of it.
- Maintain equivalent or improved accessibility features of HTML 4.01
Related Resources
ARIA Documents and Drafts
*Roadmap for Accessible Rich Internet Applications (ARIA) *Roles for Accessible Rich Internet Applications (ARIA Roles) *States and Properties Module for Accessible Rich Internet Applications (ARIA States and Properties) *Embedding Role and State Metadata into HTML4/XHTML1
- Note: A similar issue is addressed in the RDFa Primer
Widget Libraries & Toolkits
ARIA & AJAX Examples & Test Suites
The Mozilla Foundation has demonstrated strong support for ARIA, including working with IBM to implement support for ARIA in FireFox; the Mozilla Developer Center contains some excellent introductory and advanced information about ARIA and ARIA Integration into HTML5:
- Accessible Rich Internet Applications' (ARIA) Relationship to HTML5 FAQ
- Mozilla's AJAX Support for WAI ARIA Live Regions
- Mozilla's ARIA Test Pages
Accessible AJAX test cases by Charles Chen, developer of FireVox and Click,Speak
Becky Gibson, a Web Accessibility Architect at IBM, maintains a personal collection of ARIA and AJAX development resource, named WebA11y
CLC Lightweight, Internet Served Accessibility (LISA) is a project that aims to create a talking browser that is delivered to the user as a web page. There is no application or extension to install; the user simply goes to the CLC LISA web page and is able to use its functions immediately.
- Note 1: since CLC LISA is proof of concept implementation, there are limitations such as only working on Internet Explorer for Windows; however, it does provide an illustration of how IE can be used to provide ARIA support.
- Note 2: to try this demo, you will have to allow clcworld.net to run ActiveX for the speech synthesizer. note that no controls will be downloaded nor installed; CLC LISA utilizes SAPI5 which comes with Windows XP and newer. Thus you only need to grant the existing control permission to run.
The Illinois Center for Instructional Technology Accessibility maintains a suite of ARIA test pages
ReefChat is a free and open source accessible Ajax chat application developed by Peter Thiessen and designed to work with the FireVox screen reader or any other screen reader that supports WAI-ARIA. Features include: accessible layout; ARIA Live Region support; message highlighting based on message importance; message filtering using FireVox screen reader; and chat transcript history (ReefChat gets its name from a coral reef where fish meet to socialize.)
- Note: this application requires access to a server, preferably Linux based. For the database, it requires MySQL and the scripting language PHP. Refer to the ReefChat Installation page for more details
Other Germane Resources
*AccessibilityDependencies:Accessibility Dependencies of HTMLx *Evaluation and Repair Language (EARL) 1.0 Schema *XML Accessibility Guidelines *Protocols and Formats Working Group (public page) *Components of Web Accessibility *Alternative Web Browsing *How People With Disabilities Use the Web *Why Standards Harmonization is Essential to Web Accessibility *Using Combined Expertise to Evaluate Web Accessibility *References on Web Accessibility
Proposals for Integrating ARIA into HTML5
Ian Hickson's Proposal for Using "aria-" as a Vendor-Prefix in HTML5
It's not clear to me that we want the ARIA roles and attributes at all on the long term. My recommendation would be to use non-namespaces attributes throughout, and to give them some sort of vendor-prefix, as in:
aria-required="..." aria-state="..."
...and similar. (These aren't namespace prefixes, they're just textual prefixes.) In particular, do not use unprefixed attributes in HTML5, as that will result in conflicts with whatever attributes HTML5 does invent (like "required").
- source: Ian Hickson, comment on bug 391713 - Simplify ARIA roles & states in text/html (20 August 2007)
Replies to Ian Hickson's Proposal
Aaron Leventhal
That works for me. With a "aria-" as the prefix an element can be styled in IE 7 using an attribute selector. Although you can have a colon in an attribute name in IE with text/html, I can't find a way to style that with an attribute selector. So:
[aria-hidden] { display: none } -- works in IE [aria:hidden] { display: none } -- doesn't work in IE
- source: Aaron Leventhal comment on bug 391713 - Simplify ARIA roles & states in text/html (20 August 2007)
Mozilla Developer Center ARIA Relationship to HTML FAQ
Question 11: I want to use text/html with ARIA and avoid declaring namespaces -- what are the current workarounds?
Namespaced role value workaround: One issue that needs a workaround is the namespace requirements in role attribute values. Previously, ARIA's roles require namespaces for the value of the role attribute. For example, it was necessary in Firefox 1.5 and Firefox 2 to use something likeQuestion 12: That's terrible! What's the proposal to remove the ARIA namespace requirement for properties?
The proposal comes in two parts: For use of ARIA properties in text/html, Ian Hickson has suggested using "aria-" as a prefix for ARIA attribute names. The old method of using setAttributeNS() would still work, however. In the odd case that an author used both on the same element, the real namespaced version would win (because it is always used dynamically after page load, so it's more likely to be the result of user action). This is a very simple proposal to implement in browsers (create a method to get an ARIA property for a node which calls getAttribute, getAttributeNS or both, depending on what's possible in the document). A patch to implement the proposal in Firefox 3 already exists.
Thus far, Ian Hickson, and key individuals within Opera and Mozilla have agreed this is the way forward to make ARIA simpler in HTML. Aaron Leventhal has a working patch for Firefox to allow the hyphenated properties. Implementing these proposals would circumvent the dependency on namespaces (and thus initialization scripts). It would allow ARIA properties to be declared directly in markup, even when used in HTML. This would help increase the ease of adoption for ARIA, by removing a challenging technical barrier, and clarify the process of understanding, documenting, implementing, testing and debugging ARIA support in web applications.
ARIA Proposal (24 September 2007)
I have over the past few days with help from Aaron Leventhal and others written up a draft for how this should work. The goals and constraints we had when writing the proposal were:
- It should be possible to use in both (X)HTML and other vocabularies without the need for scripting.
- The processing should be the same for both HTML and XHTML.
- It should be possible to author new content that works in Firefox 2.
- The number of different possible ways to use ARIA should be minimized,and include only variations that are necessary.
- The proposal should be directly implementable in Firefox 3 and Opera 9.5.
The proposal is available at:
http://lists.w3.org/Archives/Public/www-archive/2007Sep/att-0106/aria-proposal.html
The latest version is available at:
http://simon.html5.org/specs/aria-proposal
- source: Simon Pieters, post to public-html (26 September 2007)
- for reaction to this proposal, consult the email threads ARIAIntegration#head-5c73aabc143bec779ce5f457bccb646d2b3863bf: ARIA a Proposal and ARIAIntegration#head-70a9cbbcac162e0af1e6278b79cc5730cf36aaff: role cardinality
Native Accessibility Features of HTML5
Built-in Accessibility Roles in HTML5
It isn't helpful to say that "foo is vital for accessibility" without saying why and what to write as the processing model in the spec in a way that makes sense for the long term (in the case of headers= so that the processing model also takes into account scope="" as well as implicit "obvious" default association).
<section>, <header> and the outline algorithm
These features provide a standard way to generate an outline for an HTML document. The outline can be used for jumping directly to an interesting part of a long document.
<article>
This element enables a "Skip to content" feature in UAs where the user can't get a quick overview by glance (e.g. aural UAs and visual UAs constrained by a relatively small screen).
<aside>
This element lets non-visual UAs indicate to the user that a given piece of text is not part of the main flow of thought. (Failure to indicate this could potentially be confusing.)
<footer>
Provides for skipping over administrative information in, for example, aural UAs when the user wants to scan a page as quickly as possible omitting such notices.
<nav>
Enables "Skip over navigation" and "Skip to navigation" features in UAs where the user can't easily navigate spatially (non-visual or no pointing device).
<figure>
The association of a caption with the element being captioned and the suppression of the caption when a text fallback is used is at least well-intentioned to support the needs of blind readers. Whether the design actually meets these needs is debatable judging from recent comments.
<m>
Makes it possible for non-visual UAs to indicate that a particular run of text was highlighted by, e.g. a search engine, so that a user might want to skip to it. (Again, well-intentioned. Whether it is actually workable is debatable.)
<meter>
Provides for AT access to the state of a gauge widget while making it super-easy to make visual gauges that do the right thing AT-wise.
<time>
Hopefully helps the microformat community stop polluting the title="" attribute of the <abbr> element in ways that interfere with the aural Web browsing user experience.
<datagrid>
Provides for AT access to complex grid widgets such as in browser-based email apps like Gmail.
<details>
Provides for AT mapping to the UI idiom that in (for example) the Mac native UI is visually represented by the disclosure triangle.
<datalist>
Makes it easier for users to fill text fields. Provides for AT mapping to the combobox UI idiom.
<output>
Makes it possible for AT to flag a piece of content as the changing result of a calculation. (I have no idea how useful this is in practice of how aural UAs or screen readers deal with script-based document mutations in general.)
<progress>
Provides for AT access to the state of a progress bar widget while making it super-easy to make visual progress bars that do the right thing AT-wise.
Various additions to <input type="">
Make it easier to adapt input methods to the kind of data the form field asks for. For example, if the field wants a number, a speech recognition input method could restrict itself to trying to recognize numbers only.
Make it possible for AT to indicate that a given button adds or removes a repeating part (as opposed to indicating a generic button).
Makes it easy to flag parts of the DOM irrelevant for the current moment in time in the life cycle of a Web app UI view so that AT should not try to present those parts to the user.
Chances are that when authoring tool vendors assess business cases, <progress> will have enough of a business case to go with it even without considering accessibility whereas the business case for role="" hinges on accessibility considerations only.
Existing as in "existing in a spec" is not good enough. For something to be considered existing, it needs to be implemented in a way that works. The debates are part of the finding of fact on whether something exists in this latter sense. It is frustrating for those who already know, but it is something we need to go through in order to define processing models that are compatible with the existing implementations.
Related Resources:
- Table of Built-in Accessibility Roles in HTML5 compiled by Henri Sivonen
Default role Values for HTML Elements and Built-in Accessibility
In an earlier thread, we discussed the ways HTML5 could build-in accessibility by providing commonly used widgets and UI controls that UAs could then map to the accessibility hooks provided by the UA or by the UAs host operating system. That idea had led me to propose doing this with the @role attribute by having a a sensible default @role value set for each element.
One idea that comes to mind from this discussion is that the new Assistive Technology (AT) related elements (like <progress>) might be defined in terms of @role by indicating what the @role value would be by default (and cautioning that it should not be changed except in rare circumstances etc.). I think this would raise awareness about @role and demonstrate its proper use. Its this type of default usage that helps authors understand and properly extend these facilities.
The great advantage of this approach is it still allows simple authoring techniques to accomplish decent accessibility, but it also serves as a pedagogical device by demonstrating how to use the @role attribute for other custom extensions of HTML's semantics. This brings together many of our design principles: accessibility, extensibility, backwards compatibility, etc.
Just to try to provide a more concrete example, consider the HTML5 progress element. By simply adding the @role attribute as a global attribute , we would then specify a default value for each element.
The <progress> element would have a default value of "progressbar". A UA running on Mac OS X (as just an example), would then map any object created with a role of "progressbar" to the Mac OS X accessibility API's role of "kAXProgressIndicatorRole". Since the <[ progress]> element would have this default value for role, it too would be mapped to this.
Summary:
HTML5 Element:
<progress> with a default @role value of "progressbar"
WAIrole:
progressbar
Mac OS X Accessibility Services:
kAXProgressIndicatorRole CFSTR ("AXProgressIndicator")
In this way, the use of role would be there and implemented by UAs without authors doing anything. Authors would not require any knowledge of @role it would simply "just work" behind their backs. However, as a pedagogical device, some authors would notice these @role attributes. As authors made new innovations and created new UI from HTML markup, they could also make use of the WAI role values on their new widgets. UAs would simply need to comprehensively map the WAI role values to their own internal (OS) role values. If HTML5 identified any other roles missing from the WAI vocabulary, we would simply add those to the available repertoire. The @role attribute, all of the WAI role values, and any other role values we felt necessary would all exist in the HTML namespace so there would be no namespace headaches to deal with. Therefore when using role would not require the explicit use of namespaces at all. However, in the xml serialization authors would be free to use other role-value namespaces so long as the targeted UAs support those namespaces.
This to me seems like a big win. This is one of those instances where its hard to think of any disadvantages. To many authors the role attribute would just be there doing its work behind the authors back. Even those authors wanting to make use of role would do so without the need to incorporate namespace declarations. More advanced use in the xml serialization would permit the more advanced approach of incorporating roles from other namespace.
Source: default role values for HTML elements and built-in accessibility (Robert Burns, post to public-html, 2007-07-18)
Supplemental Resources
*List of built-in accessibility features in the initial HTML5 W3C Editor's draft *Proposal to incorporate default value for role for achieving built-in accessibility *Henri Sivonen's Table of Built-in role Coverage in HTML5
Tests of Built-in Role Coverage
July 2007
Thread: Opening Thoughts on WAI-ARIA in HTML5
*Opening Thoughts on WAI-ARIA in HTML5 (Al Gilman) (18 July 2007) *pointer to built-in role tests (Henri Sivonen) (19 July 2007) *Re: Opening Thoughts on WAI-ARIA in HTML5 (Joshue O Connor) (19 July 2007) *Re: Opening Thoughts on WAI-ARIA in HTML5 (Robert Burns) (19 July 2007) *Re: Opening Thoughts on WAI-ARIA in HTML5 (Al Gilman) (20 July 2007) *Re: Opening Thoughts on WAI-ARIA in HTML5 (Maciej Stachowiek) (20 July 2007) *Re: Opening Thoughts on WAI-ARIA in HTML5 (Robert Burns) (20 July 2007) *Re: Opening Thoughts on WAI-ARIA in HTML5 (Al Gilman) (20 July 2007)
September/October 2007
Thread: ARIA in HTML -- a new FAQ, and a proposal
- Aaron Leventhal, post to public-html (20 September 2007)
- Matthew Raymond, post to public-html (21 September 2007)
- Anne van Kesteren, post to public-html (21 September 2007)
- Simon Pieters, post to public-html (21 September 2007)
- Aaron Leventhal, post to public-html (21 September 2007)
- Aaron Leventhal, post to public-html (21 September 2007)
- Simon Pieters, post to public-html (22 September 2007)
- Aaron Leventhal, post to public-html (24 September 2007)
- Simon Pieters, post to public-html (24 September 2007)
- Joshue O Connor, post to public-html (26 September 2007)
Thread: ARIA Proposal
- Simon Pieters, 26 September 2007
- Matthew Raymond, 27 September 2007
- Joshue O Connor, 27 September 2007
- Aaron Leventhal, 27 September 2007
- Anne van Kesteren, 27 September 2007
- Richard Schwerdtfeger, 27 September 2007
- Matthew Raymond, 28 September 2007
- Sander Tekelenburg, 28 September 2007
- Matthew Raymond, 1 October 2007
- Anne van Kesteren, 1 October 2007
- Simon Pieters, 1 October 2007
- Sander Tekelenberg, 5 October 2007
- Sander Tekelenberg, 5 October 2007
- Henri Sivonen, 5 October 2007
- Sander Tekelenburg, 5 October 2007
- Richard Schwerdtfeger, 10 October 2007
- Anne van Kestren, 10 October 2007
Thread: role cardinality
- Al Gilman, 27 September 2007
- Simon Pieters, 27 September 2007
- Al Gilman, 27 September 2007
- Anne van Kesteren, 27 September 2007
- Al Gilman, 27 September 2007
- Aaron Leventhal, 28 September 2007
- Simon Pieters, 1 October 2007
- Al Gilman, 1 October 2007
- Richard Schwerdtfeger, 1 October 2007
- Anne van Kesteren, 1 October 2007
- Shane McCarron, 1 October 2007
- Anne van kesteren, 1 October 2007
- Richard Schwerdtfeger, 1 October 2007
- Anne van kesteren, 1 October 2007
- Robert Burns, 2 October 2007