Re: Change proposal for ISSUE-109

I have updated the change proposal
(<https://mail.google.com/mail/html/compose/static_files/goog_1160213515>Change
the title of the WAI-ARIA section of the HTML5 spec and provide advice about
ARIA scope <http://www.w3.org/html/wg/wiki/ChangeProposals/ariasection>) which
Ian's proposal is supposed to be a response to:

The updates are responses to the 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 (see book chaper and section titles linked
> below). 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<http://my.safaribooksonline.com/9780321717948/ch02lev1sec4>as does a book about AJAX
> from 2007 <http://my.safaribooksonline.com/9780131350649/ch02lev1sec5> and
> a book from 2008 on
> http://my.safaribooksonline.com/9780596155681/ajax_and_wai-aria universal
> design] and a recent book by shelley powers JavaScript Cookbook<http://my.safaribooksonline.com/9781449390211>.
> and others.
>
> 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<http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5>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".
>



On 21 July 2010 23:34, Maciej Stachowiak <mjs@apple.com> wrote:

>
> 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.   `._.-(,_..'--(,_..'`-.;.'
> >
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html