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

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

Received on Wednesday, 2 March 2011 00:49:08 UTC