W3C home > Mailing lists > Public > public-html@w3.org > June 2010

Re: Change proposal for ISSUE-85

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 17 Jun 2010 03:15:50 -0700
Message-ID: <AANLkTik2rpZj2OIABJAAiGMbAoh6ANiejMpFYDtOs_sW@mail.gmail.com>
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 GMT

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