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

On 03/01/2011 07:48 PM, Ian Hickson 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>.)

To quote the W3C Process Document: at this point the Chairs believe that 
"the Group has duly considered the legitimate concerns of dissenters as 
far as is possible and reasonable, [and] the group SHOULD move on."

If anybody wants the chairs to reconsider this issue, they should take a 
look at the "Revisiting this Issue" section which was included in the 
decision[1].  Alternately, they are welcome to pursue the option 
described in the "Appealing this Decision" section.

>> 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.

Steve Faulkner has provided[2] the requested information.

>> 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?)

In the case of this issue, there are no absolutes.  Both the proposal 
and counter proposal sought to balance competing priorities.  They just 
did so in different ways.

If there are actual bug reports for which the resolution would change 
the balance established by the proposal that was ultimately adopted, 
then please bring such to the attention of the working group.  Note we 
said the working group (i.e., public-html), not the chairs.  In the 
event that unanimity within the group is not possible, the chairs will 
engage[3] at that time.

Meanwhile we expect everybody in the Working Group to abide by the 
Discussion Guidelines[4].  Should we determine that people are simply 
writing bug reports in an attempt to repeat the same argument over and 
over again without providing the requested new information, then such 
inappropriate actions will be deal with in the manner described on that 
page.

- Sam Ruby

[1] http://lists.w3.org/Archives/Public/public-html/2011Mar/0005.html
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10066#c32
[3] http://www.w3.org/2005/10/Process-20051014/policies#managing-dissent
[4] http://www.w3.org/html/wg/wiki/ListGuidelines

Received on Monday, 7 March 2011 22:19:57 UTC