- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 15 Jul 2010 17:58:49 +0000 (UTC)
- To: public-html@w3.org
ISSUE-109 ========= SUMMARY Change the title of the Annotations for Assistive Technologies section, add more introductory material, and urge implementors to avoid exposing conflicting semantics in their user interface. RATIONALE 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. 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. 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. 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. DETAILS Change the heading to just "Annotations for assistive technology products", which accurately describes the purpose of the section without using any acronyms. Add an introductory paragraph that explains what ARIA is before using the acronym. The exact text is left to editor discretion, but it should include an expansion of the acronym, an explanation of the purpose of the technology, and could include an example. Add a requirement that user agents not let their behaviour other than as exposed through assistive technologies be affected by ARIA annotations when those annotations conflict with HTML semantics. The exact text is again left to editor discretion. IMPACT POSITIVE EFFECTS * Authors are more likely to find out about ARIA and so more likely to make any pages in which they use <div>itis widgets accessible. NEGATIVE EFFECTS None. CONFORMANCE CLASS CHANGES A new requirement would be applied to user agents. Since no user agents contradict the requirement at this time, it would have no practical impact today, but may prevent future problems. RISKS * Having the restriction be limited to conflicts, rather than requiring that ARIA only affect accessibility API UIs, could lead to some UAs actually applying ARIA semantics in non accessibility-API situations. This could lead to the features being used in a presentational fashion that conflicts with their accessibility API uses, resulting in ARIA being useless for its original intended purpose of accessibility annotation. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 15 July 2010 17:59:20 UTC