- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 17 Jun 2010 03:15:50 -0700
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, public-html@w3.org
On Thu, Jun 17, 2010 at 2:54 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote: > 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. Is there anything to substantiate this concern? I.e. has anyone ever heard of this happening in practice? >>> 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. Out of curiosity, how much CSS was required to do this? If an implementation follows the recommendations of the HTML5 rendering section, then I think the following CSS should be enough: .buttonAsLink { binding: none; color: blue; text-decoration: underline; } However I don't think that is the case in any implementations *yet*. / Jonas
Received on Thursday, 17 June 2010 10:16:46 UTC