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
