Re: Change proposal for ISSUE-85

hi jonas,

>Is there anything to substantiate this concern? I.e. has anyone ever
>heard of this happening in practice?

 I have noted from our web site stats is regularly people arrive at our blog
with querys like
"role not valid", as I have written a few articles on the subject of html /
aria validation.

Which suggest people are checking with a validator and finding arrors due to
use of role (most ;probably on html4/xhtml 1 docs)

and validation does appear to be a concern for some:

http://www.brucelawson.co.uk/2008/speeding-adoption-of-wai-aria/


regards
Stevef
On 17 June 2010 11:15, Jonas Sicking <jonas@sicking.cc> wrote:

> 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
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html