Re: Change proposal for ISSUE-85

On 2010-06-16 23:28, Jonas Sicking wrote:
> On Wed, Jun 16, 2010 at 2:08 PM, Richard Schwerdtfeger
> <schwer@us.ibm.com>  wrote:
>> So, what you want to do is use accessibility as a vehicle to enforce your
>> vision of sticking to host language semantics.
>> You want to tell someone who is trying to make their web page accessible be
>> an HTML villain - per your WhatWG post:
>> http://krijnhoetmer.nl/irc-logs/whatwg/20100616#l-228
>> [04:58]<othermaciej>  it disallows the concept with a non-machine-checkable
>> requirement, but does not make the syntax an error
>> # [04:58]<othermaciej>  however, it does make the syntax<a role="button">
>> an error
>> # [04:58]<Hixie>  right, role="" is a godsend here
>> # [04:58]<othermaciej>  with a machine-checkable rule
>>
>> If you remove the ARIA role semantics it means that authors are free to
>> produce inaccessible content when they use script and CSS.
>
> Note that no one has suggested removing the ARIA role semantics.

My understanding of what Richard is saying is that by making it a 
conformance error, the result of reporting an error for <a 
role="button"> will be for authors to simply remove the role attribute, 
even if the link really is behaving like a button, rather than changing 
it to a real button.

>> I mean you don't suggest
>> it is a failure if you add script and CSS so they will go right along doing
>> it. This is how we got into the situation where we needed ARIA. We failed by
>> not giving
>> the authors the vehicle to convey their intent
>
> That is a different situation then here though. We are providing the
> vehicle to convey their intent. That vehicle is<button>.

That sounds nice in theory, and in the past I have used <button> in 
place of <a> for that reason, even though the button had to be styled to 
look like a link to match the graphic designer's/client's request.

This particular case was a Cancel button which was designed to look like 
a link instead of a submit button.  The reasons for these design and 
implementation decisions were

1. To make it sufficiently distinguishable from the "Next" button so 
that end users didn't accidentally click it instead of Next.
2. To still submit and notify the server of the registration 
cancellation, if cancelled from step 2 onwards, and to work with the way 
in which the back end was being implemented.
3. Because it was actually a link step 1 of the registration process (if 
you cancelled before submitting step 1, there was no need to notify the 
server) but it still needed to look consistent across each of the pages.
4. It had to function with JS disabled, and so a submit button was 
chosen over a link that invoked form.submit().
5. Because I'm pedantic enough to take the time to do things right, 
though I can attest to the level of complexity that this right way of 
doing things created, particularly in terms getting consistent form 
control styling across browsers.  It most certainly would have been 
quicker and easier to just use a link.

In practice, however, we find that most authors simply avoid this hassle 
of styling buttons to look like links in favour of simply using a link 
with script to satisfy the behavioural implementation requirements. 
Even though from theoretical point of view, doing so may be less than 
ideal, web developers have to make a trade off between semantic purity 
and matching the client's requirements in a cost effective and timely 
manner.  Spending time replicating the look and feel of a link by 
styling a button often loses out to simply using a link and getting the 
job done faster.

Depriving authors of the ability to at least make up for this trade off 
by declaring that the link is really going to behave like a button (at 
least without getting a conformance error for it) does nothing to help 
accessibility, even if the motive behind doing so is in an honest 
attempt at encouraging authors to do the right thing.

So while I agree that the semantically correct approach is to use a 
button when it really is a button, the pragmatic approach here seems to 
be to simply allow role="button" on links.  It might, however, be 
reasonable for a validator to give the author friendly advice about 
using a real button instead, but I think trying to enforce this 
constraint will fail with negative consequences.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Thursday, 17 June 2010 09:54:43 UTC