Re: Working Group Decision on ISSUE-129 aria-mapping

On 03/02/2011 05:33 PM, Steve Faulkner wrote:
>
> Ian hickson wrote:
>
> "In the interests of avoiding mistakes, could you provide me with a set of
> edit instructions that state exactly what should change to fully comply
> with this decision? I fear that attempting to apply the vague change
> proposal in the original CP followed by the diff to that proposal quoted
> above will result in errors."
>
> I have provided here
> http://www.html5accessibility.com/tests/aria-changes.html

Thanks!

If anybody spots any errors that need to be corrected before this text 
is incorporated, I encourage them to speak up now.  However, if such 
errors are identified later, bug reports that bring the text in line 
with the decision can be filed.

- Sam Ruby

> A copy of the aria section revision 1.4093. with the required changes:
>
> the required changes are in the 2 data tables.
> each deletion and insertion is marked using the <ins> and <del> elements.
>
> NOTE: the deletion of  the rows in the data tables pertaining to the
> table, tr, td and th elemnts  is NOT part of the change proposal, but
> were removed earlier by the html5 editor and NO agreement on
> re-inserting them has occured, but have mysteriously re-appeared in this
> version of the spec, so need to be removed once again
>
> regards
> Stevef
>
> On 2 March 2011 00:48, Ian Hickson <ian@hixie.ch <mailto:ian@hixie.ch>>
> wrote:
>
>     On Mon, 28 Feb 2011, Sam Ruby wrote:
>      >
>      >   In any case, the above examples should not be exposed to ATs as
>      >   buttons widgets even if they were valid. They are exposed to
>     users as
>      >   link widgets, not button widgets, and thus that is the
>     appropriate AT
>      >   behaviour and the appropriate ARIA role.
>      >
>      > We fail to follow the logic.  They are exposed differently to AT
>     users
>      > and non-AT users and therefore this behavior is correct?
>
>     I feel that the chairs' lack of understanding of this particular
>     argument
>     may have affected the decision with respect to the "button" role on
>     links
>     and the "link" role on buttons.
>
>     The argument presented in favour of allowing these roles is that this
>     (even in the absence of styling) is a button:
>
>     <a href=# onclick="action()">Action</a>
>
>     Putting aside the issue of whether such authoring should be valid at all
>     in the first place, the counter-argument, which is quoted above and was
>     apparently not understood by the chairs, is that this in not a button.
>
>     The type of widget that a user interacts with, as determined by the
>     user,
>     is determined not by the theoretical purpose that the author
>     intended the
>     widget to have, but by the actual user interaction with the widget. For
>     the sample markup above, the rendering and behaviour of a visual user
>     agent is that of a link, not of a button. As such, it would be
>     inappropriate, for the reasons described in the CCP and the
>     objections to
>     the original CP, to expose that link to ATs as a button.
>
>     (The same argument applies in reverse, for <button role=link>.)
>
>
>      > Therefore, the HTML Working Group hereby adopts the ARIA in HTML5:
>      > change some role mappings Proposal for ISSUE-129, with some specific
>      > exclusions.  Of the Change Proposals before us, this one has
>     drawn the
>      > weaker objections.
>      >
>      > The specific exclusions are:
>      >
>      >   * Any changes to how <hgroup> elements are to be interpreted,
>     or how
>      >     headings contained within such an <hgroup> are to be interpreted.
>      >   * Allowing slider, scrollbar, or progressbar for <button>, <input
>      >     type=image>, or <input type=image>
>      >   * Allowing progressbar, radio, slider, or scrollbar for <a>
>      >   * Allowing button, checkbox, option, radio, slider, spinbutton, or
>      >     scrollbar on <h1>-<h6>
>
>     In the interests of avoiding mistakes, could you provide me with a
>     set of
>     edit instructions that state exactly what should change to fully comply
>     with this decision? I fear that attempting to apply the vague change
>     proposal in the original CP followed by the diff to that proposal quoted
>     above will result in errors.
>
>
>      > We encourage discussion to continue on these topics, and for the
>      > discussion to take tangible form as bug reports.  Bug reports on
>     these
>      > specific topics will be allowed.
>
>     Could you clarify how I should handle such bug reports? For example,
>     would
>     it be appropriate for me to edit the spec if someone filed a bug saying
>     that allowing role=link on <button> is bad because buttons aren't links,
>     don't look like links, don't act like links, and that this therefore
>     results in a situation where AT users and non-AT users get a confusingly
>     different experience (e.g. they would not be able to easily communicate
>     when discussing the page, since what one experienced as a link the other
>     would see as a button)? Such a bug doesn't seem to fall foul of the
>     taboo
>     argument indicated here:
>
>      > Bug reports predicated on the assumption that use cases of adding
>     ARIA
>      > to existing markup that mostly works but doesn't conform to the
>     ideals
>      > defined by the specification will be summarily closed.
>
>     Also, since this decision has been given in the form of rationale
>     that is
>     to be applied to future bug reports as well, could the chairs
>     clarify what
>     the purpose of conformance criteria should be in general, if not to help
>     authors avoid writing markup that "mostly works but doesn't conform
>     to the
>     ideals defined by the specification"? (Or is "ideals" being used in a
>     narrower sense than "best practices" and "avoiding mistakes" principles
>     that was used in the arguments against these changes?)
>
>     --
>     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
>
> www.paciellogroup.com <http://www.paciellogroup.com> |
> www.HTML5accessibility.com <http://www.HTML5accessibility.com> |
> www.twitter.com/stevefaulkner <http://www.twitter.com/stevefaulkner>
> HTML5: Techniques for providing useful text alternatives -
> dev.w3.org/html5/alt-techniques/ <http://dev.w3.org/html5/alt-techniques/>
> Web Accessibility Toolbar -
> www.paciellogroup.com/resources/wat-ie-about.html
> <http://www.paciellogroup.com/resources/wat-ie-about.html>

Received on Wednesday, 2 March 2011 23:09:45 UTC