W3C home > Mailing lists > Public > wai-xtech@w3.org > December 2009

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

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Tue, 1 Dec 2009 07:16:54 -0600
To: "Charles McCathieNevile" <chaals@opera.com>
Cc: "Lars Gunther" <gunther@keryx.se>, "Tab Atkins Jr." <jackalmage@gmail.com>, "Jonas Sicking" <jonas@sicking.cc>, "HTMLWG WG" <public-html@w3.org>, "Shelley Powers" <shelley.just@gmail.com>, "W3C WAI-XTECH" <wai-xtech@w3.org>, wai-xtech-request@w3.org, "Leif Halvard Silli" <xn--mlform-iua@xn--mlform-iua.no>
Message-ID: <OFA454D848.BAA03797-ON8625767F.0048659C-8625767F.0048F5B8@us.ibm.com>

I agree with Charles. The author is going to do what they are going to do.
Anybody in accessibility would support evangelizing using standard controls
in the way they were intended over their being re-purposed such as by
making an H1 look and behave like a button. Removing the ability to make an
H1 look and behave like a button can't be prohibited without removing
scripting and CSS support for the element. What we can do is make it
accessible using ARIA. What we can't do is use accessibility failure as a
way to regulate how authors create their UIs - that would be an
unsuccessful endeavor.

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

             <chaals@opera.com                                          To 
             >                         "Tab Atkins Jr."                    
             Sent by:                  <jackalmage@gmail.com>              
             wai-xtech-request                                          cc 
             @w3.org                   "Leif Halvard Silli"                
                                       "Jonas Sicking" <jonas@sicking.cc>, 
             11/12/2009 05:09          "Lars Gunther" <gunther@keryx.se>,  
             AM                        "Shelley Powers"                    
                                       <shelley.just@gmail.com>, "HTMLWG   
                                       WG" <public-html@w3.org>, "W3C      
                                       WAI-XTECH" <wai-xtech@w3.org>       
                                       Re: ARIA roles added to the a       
                                       element should be conforming in     

On Tue, 10 Nov 2009 17:42:31 +0100, Tab Atkins Jr. <jackalmage@gmail.com>

> On Tue, Nov 10, 2009 at 8:40 AM, Charles McCathieNevile
> <chaals@opera.com> wrote:
>>>>> On Thu, Oct 22, 2009 at 9:08 AM, Leif Halvard Silli wrote:
>>>>>> In the spirit of "don't break the Web", the most important question
>>>>>> seems to me be to be "should it work?" Should a <h1> with a
>>>>>> role="button" be presented as a button in accessibility devices?
>> [a few people with known expertise and experiences in accessibility said
>> Yes. I agree with them.]
> Ok.
> On Tue, Nov 10, 2009 at 8:40 AM, Charles McCathieNevile
>> ... A 3-minute test case
>> suggests that the role works on H1 now. As Steve and others said it
>> should. Using role="button" on a link behaves that way too.
> Damn, I was sort of hoping it *wasn't* supported in that particular
> way yet.

That could be because you don't rely on assistive technology to understand

what a website is doing :)

>  Well, that's existence proof at least, even if it's sort of
> crazy to me.
>> In any case, as a browser implementor I will strongly resist attempts
>> to get the browser to behave differently in this case - since our goal
>> is to help users.
> So you're reasonably certain that presenting that <h1> as a button in
> accessibility devices is indeed a good thing for users?

For the case where it is being used as a button by some author, yes.

>  And that officially blessing this usage is better than attempting to
> evangelize for more appropriate usage in the first place, obviating
> the need for ARIA?

Not at all.

It is far better to evangelise proper usage of code.

However, abandoning users in real cases, in order to make it easier to
evangelise a principle for authors strikes me as wrong-headed (it is a
violation of the principle of prioritising communities or whatever it is
currently called), and I believe it would lead to lots of authors saying
"why don't you just deal with the problem" and ignoring the architecture
theory purists who would refuse to do so.

> (I'm very interested in the answer to this, because I'm assuming that
> one *can* use appropriate elements in the first place - my own
> experience building websites seems to suggest so.  If in practice
> there are indeed important reasons to subvert HTML's default
> semantics, that's information to know about!)

I can write good code too. And many people can. But it doesn't take a
neurosurgeon and a statistics genius to discover that a lot of the people
who make websites believe there is some important reason to misuse code...

>>> Because ARIA and CSS are different things.  Why should they work
>>> similarly?  ARIA is nothing than a patch to help out users of ATs when
>>> authors use elements in novel ways, such as using <div>s to implement
>>> sliders.  It's not meant as a general tool to be used by the average
>>> author - with luck, a normal author never has to get anywhere *near*
>>> ARIA, because they're using elements for what they're intended for.
>> So it's a patch for authors who do crazy things.
> Well, no.

Well, yes actually.

> You don't have to do crazy things to make use of ARIA.  A
> major use-case for it is implementing new widgets, where there are no
> appropriate default semantics and so it's better to jump straight into
> <div>s and <span>s and patch them up so they actually make sense in
> mediums beyond visual.

Quite true, but in no way contradicting what I said.

> I'm saying that I *don't* think ARIA should be a patch for when
> authors do crazy things.

Which is where we diverge radically in opinion.

People *need* some way to figure out what is going on. And where authors
do crazy things, then dress it all up with some visual presentation,
people who see it can apply their understanding of the visual semantics to

interpret what's happening. That's what such authors rely on in the first

So (repeating myself because I think it is important) *one* of the major
use cases for ARIA is providing a way to patch wierd stuff that authors
do. The other major use case is the one you present above. I suspect there

will be lots of HTML4 date pickers deployed using crazy script-and-css
messes even when the other browsers also implement input type="date",
which leads me to conclude taht what seems crazy depends a lot on where
you are looking from.

>  In my experience it's always possible, and
> usually pretty easy, to comply with HTML's default semantics.

In mine too. However, I see that a lot of real world content doesn't, for
whatever reason, manage to achieve that goal - and yet people need to be
able to use it.

> I may be wrong, though - there may be cases that I just haven't run
> into where the most logical thing really *is* to use an <h1> but treat
> it as a button.
> (Actually, I may know of one - some accordion structures use headings
> as the toggler for their section.  In that case, is it most helpful to
> expose the heading as a button?  I truly don't know, and would
> appreciate some guidance on the matter.)

Given the lack of list-specific headings, and given the value to real
users of being able to navigate an outline or structure via the headings,
I would say you have just provided a very sound use case - thanks very



Charles McCathieNevile  Opera Software, Standards Group
     je parle franšais -- hablo espa˝ol -- jeg lŠrer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

(image/gif attachment: graycol.gif)

(image/gif attachment: pic14939.gif)

(image/gif attachment: ecblank.gif)

Received on Tuesday, 1 December 2009 13:17:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:25:28 UTC