W3C home > Mailing lists > Public > public-html@w3.org > July 2010

Change proposal for ISSUE-109

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 15 Jul 2010 17:58:49 +0000 (UTC)
To: public-html@w3.org
Message-ID: <Pine.LNX.4.64.1007151757090.24444@ps20323.dreamhostps.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:10 GMT