- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Thu, 17 Jun 2010 11:54:11 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, public-html@w3.org
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