W3C home > Mailing lists > Public > public-html@w3.org > March 2011

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

From: Smylers <Smylers@stripey.com>
Date: Tue, 1 Mar 2011 10:58:24 +0000
To: HTMLWG WG <public-html@w3.org>
Message-ID: <20110301105824.GS27444@stripey.com>
Sam Ruby writes:

> The decision follows.

Hi group. I had a question about this, regarding the effect on non-CSS
user agents, which Sam has answered to my satisfaction.

I had meant to include the group on the thread, but appear to be too
stupid to use my own mail client and I inadvertently failed to do that.
In the event that anybody else is interested in this matter, my question
and Sam's reply are both attached.

Cheers

Smylers
-- 
http://twitter.com/Smylers2

attached mail follows:


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
-- 
http://twitter.com/Smylers2

attached mail follows:


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
Received on Tuesday, 1 March 2011 10:58:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:23 GMT