Change the title of the WAI-ARIA section of the HTML5 spec and provide advice about ARIA scope

The following is a Change Proposal for content in Section 3.2.6 Annotations for assistive technology products (ARIA):

Editor: Steve Faulkner (faulkner.steve@gmail.com)

Date: April 29, 2010 (updated 29th July 2010).

Please address feedback to the HTML Working Group mailing list (public-html@w3.org).

Summary

Change the title of the section to one that is more descriptive and add content from the ARIA specification related to potential implementations of ARIA by user agents.

Rationale

For changing the title of the section:

1. The term "annotation" is unfamiliar to most people in the context of WAI-ARIA and does not appear to describe correctly the use of WAI-ARIA in HTML.
2. The term "annotation" is not used anywhere in the WAI-ARIA specification or the User Agent Implementation Guide.
3. The suggested alternatives better describe what the section is about.
4. WAI-ARIA includes other information not touched upon in this section such as "focus navigation". So more clearly defining what IS in the section is helpful for potential consumers of the spec.
5. Impying WAI-ARIA is only relevant to a subset of user agents (assistive technology products) creates a false division between what a user agent should and should not implement to improve the accessibility of the content it displays.

For adding information about scope of ARIA implementation by user agents.

1. The current spec text may leave user agent vendors may be left with the impression that WAI-ARIA roles, states and properties must not be used beyond the exposure of information to accessibility APIs. This is not the case. The suggested text clarifies this. It is always better to be explicit in stating what user agents are allowed to do than to rely on user agent implementers making educated guesses about what is likely to be the most helpful solution.
2. There are features in ARIA that are not present in HTML5, which user agents could implement to enhance the accessibility of content for users with disabilites that DO NOT use assistive technology. An example of this is WAI-ARIA landmarks. They are now deployed on major websites (Google, Yahoo, BBC) and if browsers implemented keyboard navigation to landmarks it would be increase the navigability for all non mouse users. Another example is WAI-ARIA live regions, these could be useful to aural browser users regardless.

Details

change summary:

change 1

1. Change title of section from "3.2.6 Annotations for assistive technology products (ARIA)" to:

"3.2.6 Use of WAI-ARIA Roles, States and Properties in HTML"

or

"3.2.6 Using WAI-ARIA Roles, States and Properties in HTML"

or

"3.2.6 Conformance Requirements for WAI-ARIA Roles, States and Properties in HTML"

or

"3.2.6 WAI-ARIA Roles, States and Properties in HTML"

or

"3.2.6 Using WAI-ARIA Role, State and Property attributes in HTML"

or

"3.2.6 WAI-ARIA Role, State and Property attributes in HTML"

or simply "3.2.6 WAI-ARIA" which is how SVG ("4.8.15 SVG") and MathML ("4.8.14 MathML") are titled in the specification.

change 2

2. After the sentence "User agents may apply different defaults than those described in this section in order to expose the semantics of HTML elements in a manner more fine-grained than possible with the above definitions." in section 3.2.6 insert the following text in a new paragraph:

"The WAI-ARIA specification neither requires or forbids user agents from enhancing native presentation and interaction behaviors on the basis of WAI- ARIA markup. Even mainstream user agents might choose to expose metadata or navigational features directly or via user-installed extensions; for example, exposing required form fields or landmark navigation. User agents are encouraged to maximize their usefulness to users, including users without disabilities." source

Impact

Positive Effects

• Provides a title for the section that reflects the content.
• Gives extra advice/clarification to implementors.

Negative Effects

• may lead authors to believe that ARIA currently does something it does not, but this can be mitigated by clearly titling the sub section the implementor only advice is in as advice for user agents ONLY. Note: content in the suggested insertion point is hidden when a user selects the "Hide UA text" view.

Conformance Classes Changes

none

Rebuttal of counter proposal

counter proposal

The counter proposal states:

"The term ARIA is an acronym with very little name recognition in the wider developer community,
and using it in a heading is likely to confuse people rather than encourage them to learn more."

This is an odd statement to make since the current section title includes the term ARIA and could have been changed by the editor at any time. I challenge the unfounded assertion that ARIA has very little name recognition in the wider developer community. Why would the use of ARIA in the heading confuse people? The current heading confused me "Annotations for assistive technology products (ARIA)" and I am someone very familiar with the subject. But if it is so confusing for readers why are acronyms such as IANA used in headings in the spec? how many people in the wider developer community have clear notion of what "Serializability of script execution" means or "Common microsyntaxes" what's "IDL"? Clearly clarity and recognition is not a major factor in deciding what to include in headings in the HTML5 spec.

Furthermore, a newly published book about HTML5 aimed squarely at developers sees fit to use WAI-ARIA in a section title as does a book about AJAX from 2007 and a book from 2008 on universal design and a recent book by shelley powers JavaScript Cookbook.

The counter proposal states:

"Since accessibility is an important topic, we should encourage authors to learn as much as possible 
about the topic, which means not using confusing acronyms as early as the section heading."

Which is why the proposed alternative to the current text provide clear descriptive linked references to the WAI-ARIA authoring guide and specification.

The counter proposal states:

"Furthermore, we should explain the acronym before we use it. Thus, we should add a 
paragraph of introductory material at the top of the section that clearly indicates the purpose of ARIA."

good idea about adding a paragraph of intro material with an expansion of the acronym, but I don't see this being done for any other acronym used in a heading in the spec, so why so for this one? Anyway, why is this included in this counter proposal, the editor could add this at any time, as he recently did with an example of aria-labelledby use, without requiring it be agreed to .

The counter proposal states:

"Finally, the section lacks conformance requirements that would prevent
user agents from using ARIA in a manner that conflicts with other HTML
features in non-AT scenarios. For example, aria-required="" should not
cause an <input> element to appear required in the visual presentation
if its required="" attribute is absent, and vice versa."

What has this to do with the proposal it counters? and why is it included here the editor can add this at any time.

Note the counter proposal does not address the issue of "adding information about scope of ARIA implementation by user agents".

References