Re: ARIA roles added to the a element should be conforming in HTML5.


The bottom line is that unless in HTML we are going to rip script and CSS
support out of a broad range of HTML elements authors will repurpose them.
Authors do not adhere to a utopion world where they follow the intent of
the HTML working group intended. As you can imagine, IBM alone has hundreds
of software products, many web based. More often than not a product team
will create a custom control to differentiate themselves from their
competitors and to add features that the HTML working group did not think
of. They don't care whether you, me, or anyone else says they should use
the button provided in HTML. If you tried we tried to stop these practices
from happening, by removing the script capability on an element, developers
will not use HTML 5 and most likely object to HTML 5 standardization.

There is absolutely, no way we can remove ARIA attributes from the list of
elements in the spec. because authors will repurpose them. The ONLY thing
we can do is:

- recommend that authors use the standard controls provided in HTML
- Ensure that ARIA attributes for states and properties do not conflict
with the native host language state and property by saying the host
language takes precedence. For example, aria-checked when applied to a an
HTML checkbox does not override the checked stated implied by the control

Frankly, all of us in accessibility would prefer users use standard
controls. It makes our life MUCH easier. Unfortunately, that is not the
world we live in. So, we need ARIA to convey the author's intent. Failure
to provide ARIA capability to the author is a failure in the HTML working
group to address accessibility.


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

             Steven Faulkner                                               
   >                                                  To 
             Sent by:                  Jonas Sicking <>    
             public-html-reque                                          cc 
                    HTMLWG WG <>, W3C 
                                       WAI-XTECH <>        
             10/21/2009 02:48          Re: ARIA roles added to the a       
             AM                        element should be conforming in     

Hi jonas,

the examples are not sites but YUI and  and jQuery widgets, so they are
being used on many sites.

>Wouldn't it be better for these sites to use a <button> element
>instead? Or maybe they currently "can't" because you can't style a
>button enough to give it the desired rendering.

of course it would be, but the developers have decided to use  the a

a related example: wouldn't it be easier for example for the gmail
developers to use a <button> for the  "search mail" button in gmail
instead of

<DIV id=:r9 class="J-K-I J-J5-Ji ipG21e J-K-I-JW" tabIndex=0
closure_hashCode_5dymj1="112" act="" unselectable="on"><DIV class="J-J5-Ji
J-K-I-Kv-H" unselectable="on">
<DIV class="J-J5-Ji J-K-I-J6-H" unselectable="on">
<DIV class=J-K-I-KC unselectable="on">
<DIV class=J-K-I-K9-KP unselectable="on">&nbsp;</DIV>
<DIV class=J-K-I-Jz unselectable="on">Search

styled and scripted to look and act like a button?

I would think yes, but they obviously don't

best regards

2009/10/21 Jonas Sicking <>
  On Wed, Oct 21, 2009 at 12:17 AM, Steven Faulkner
  <> wrote:
  > Currently the a element is defined in the HTML5 specification as an
  > that cannot have its native role overriden by ARIA roles [1]
  > This is contrary to use in the wild as it has been overriden by the
  > of a number of roles in popular javascript UI libraries.
  > Examples:
  > button

  > tab

  > menutiem
  > It is important to understand that it is not ARIA that is making the
  > into a button, its the developers use of javascript, event handlers and
  > that is making it look and act like a button or tab or menutiem. The
  > addition of ARIA is merely providing the information that other users
  get by
  > default. So making the addition of an ARIA role non conforming, to an
  > element that has been designed to act and look like something other
  than its
  > native role, is not the appropriate repsonse.
  Wouldn't it be better for these sites to use a <button> element
  instead? Or maybe they currently "can't" because you can't style a
  button enough to give it the desired rendering.

  / Jonas

with regards

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

Received on Wednesday, 21 October 2009 17:09:05 UTC