Re: Change proposal for ISSUE-109

Thank you for your submission. I have posted this on ISSUE-109:
http://dev.w3.org/html5/status/issue-status.html#ISSUE-0109

Regards,
Maciej

On Jul 15, 2010, at 10:58 AM, Ian Hickson wrote:

> 
> 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 Wednesday, 21 July 2010 22:34:39 UTC