Forwarded message 2
Was this meant to be sent to just me? To all three co-chairs? Or to
the entire group? In general I recommend at a minimum sending email
such as these to all three co-chairs copying www-archive@w3.org. You
are welcome to omit copying the archive if you want a private reply, or
to copy public-html if you want to start a discussion.
As I am assuming that you are sending this to me in my role as a W3C
co-chair, I am copying my co-chairs and w3c staff on my reply.
There is no question that the consensus of the working group is that an
anchor tag styled as a button is a violation of the rules, and that web
developers break the rules and show no signs of stopping, and that such
a violation is not reasonably detectable using automated tools.
We also find that it was not the creation of WAI-ARIA that caused
authors to re-purpose this element, that WAI-ARIA happens to be one of
the few ways that can programmatically verify semantic consistency, or
that this could provide an indirect mechanism to verify the underlying
breakage.
All of this is from the front of the decision itself.
The addition of a role attribute to such an abomination itself does no
harm. At worst it is ignored. At best, it gives text browsers an
opportunity to greater understand the intent.
Again, you are correct that this is a missed opportunity to educate
people about the misuse of this element.
The net result is close to what you stated:
> So it may well be that, on balance, the Chairs believe the harm caused
> to non-CSS users by allowing certain Aria as conforming (which avoids
> alerting authors to the underlying problem) is less than the harm caused
> to AT users by disallowing that Aria (which may cause some authors
> simply to remove the Aria).
The only difference is that I would have worded it that we found that
the objections to making the use of the role attribute in such
situations non-conforming to be stronger than the objections to allowing
the use of the role attribute in such situations.
Even though I would have worded it differently, I agree that the end
result is the same.
- Sam Ruby
P.S. If this answer satisfies you, then no further action is necessary.
However if you like, you have my permission to forward this note in
its entirety to either www-archive or public-html.
On 03/01/2011 04:45 AM, Smylers wrote:
> Sam Ruby writes:
>
>> The decision follows.
>
> Hi there. Thanks for making the decision, and all the effort put into
> it.
>
> There is one part of it I would appreciate clarification on, if possible
>
>> Making a link act like a button to ATs while leaving it as a link
>> for non-AT users will lead to non-AT users having a confusing
>> experience, since the author will think the link is going to appear
>> as a button to users and may refer to it as such.
>>
>> The situation being described is exactly the opposite: in case where
>> the link acts like a button for non-AT users (by virtue of the
>> techniques such as JS), the use case is to enable the use of aria
>> markup to make such behave the same for AT users.
>
> On reading the above part of the change proposal I thought it was
> referring to a situation like this:
>
> There's a link which has been styled with CSS to look like a button.
>
> * Graphical browsers with CSS enabled present it as a button.
> * Text browsers, and graphical browsers with CSS disabled, present it
> as a link (along with some other non-browser user agents, such as
> something listing all the links on a page, or a web crawler).
> * AT will convey it as a link by default, but the author may have used
> Aria to say instead it should be conveyed as a button.
>
> Note that regardless of how Aria is used, the first two categories are
> already in conflict with each other -- so some non-AT users are getting
> a misleading presentation. And since Aria is, by definition, only for
> AT, no use of Aria can resolve this conflict.
>
> The only way of resolving the conflict is to change the underlying
> mark-up so that a link is not being used as a button.
>
> I do not speak for the author of the change proposal quoted above, but
> its following paragraph suggests my interpretation is what was intended:
>
>> What's important to remember is that there are more than two kinds
>> of user agents; there are at least three... User agents without CSS
>> support or without scripting support, and certainly without ATs,
>> which always use the default semantics of the elements.
>>
>> This is potentially a valid objection, but fails to explore what
>> happens in the case where such a user agent does not support ARIA, nor
>> the case where such a user agent does support ARIA.
>
> In a non-CSS non-Aria browser, there is obviously the conflict I
> mentioned above.
>
>> In the former case, it does no harm.
>
> The harm isn't caused by the Aria mark-up, but by the underlying misuse
> of an element.
>
> However, accepting as conforming the use of Aria to 'fix' mark-up in
> this way condones fixing things only for AT users while leaving them
> confusing for non-CSS users.
>
> To an author who misguidedly believe that misusing a link as a button
> and applying matching Aria is sufficient to convey identical semantics
> to all users, having that Aria conforming allows the author to continue
> believing that; they simply do not get alerted to the underling problem.
>
> Whereas a conformance error can indicate that there is an underlying
> problem which needs addressing, with suggestions on how to do that.
>
> So it seems to me that encouraging Aria mark-up in this case does to
> harm to users of non-CSS user-agents.
>
> I do not understand how that fits in with the decision's bare claim that
> it does no harm, so I am concerned that the Chairs' interpretation of
> the above situation was different from mine, and the one I'm thinking of
> wasn't considered.
>
>> The only way to keep things consistent amongst all three is to use
>> HTML elements appropriately, and not override their semantics with
>> ARIA.
>>
>> To date that approach has failed to keep them consistent, nor is there
>> any evidence that this trend won't continue.
>
> So it may well be that, on balance, the Chairs believe the harm caused
> to non-CSS users by allowing certain Aria as conforming (which avoids
> alerting authors to the underlying problem) is less than the harm caused
> to AT users by disallowing that Aria (which may cause some authors
> simply to remove the Aria).
>
> If that is the Chairs' position in this decision, then I have no problem
> with it. (None of us could know for certain on something like this, so
> whichever way the Chairs went isn't something anybody can demonstrate to
> be wrong.)
>
> But that is quite different from claiming there is no harm to non-CSS
> users.
>
> (Though obviously the effect of the decision is the same.)
>
>> == Revisiting this Issue ==
>>
>> This issue can be reopened if new information come up.
>
> The information I write above is not new to me, since I thought it was
> covered by the change proposal. Given the request to avoid 'me too'
> votes in the straw poll or duplicating information from elsewhere, I
> didn't submit it there. (For which, my apologies; with the benefit of
> hindsight it seems that's what I should have done.)
>
> However, since it looks like the Chairs' interpretation of that part of
> the change proposal was different from mine, this may qualify as new
> information to you.
>
> Does this count as new information?
>
> Thanks.
>
> Smylers