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

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

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> 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 | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html