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

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 10 Nov 2009 20:18:36 +0100
Message-ID: <4AF9BC8C.4090707@xn--mlform-iua.no>
To: John Foliot <jfoliot@stanford.edu>
CC: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, 'Charles McCathieNevile' <chaals@opera.com>, 'Jonas Sicking' <jonas@sicking.cc>, 'Lars Gunther' <gunther@keryx.se>, 'Shelley Powers' <shelley.just@gmail.com>, 'HTMLWG WG' <public-html@w3.org>, 'W3C WAI-XTECH' <wai-xtech@w3.org>
John Foliot On 09-11-10 19.34:

> Leif Halvard Silli wrote:
>> If we want to avoid that H1 elements can be turned into buttons,
>> perhaps we should start by making the following non-conforming?
>>
>> <a href="link"><h1>Heading</h1></a>
> 
> Leif,
> 
> In my role of supporting a large author base here on campus, it is my 
> general experience that 'taking away' things from authors makes them both 
> cranky and unwilling to cooperate, whilst handing out enough rope (and 
> planning for the odd tangling of said rope) fosters creativity, and 
> demonstrates that ensuring accessibility doesn't need to be seen as 
> restrictive.

Mostly, it was meant rhetorically: If one is serious about making 
<h1 role="button"> - or the almost synonymous <h1 role="link"> - 
non-conforming, then we should also make it non-conforming to turn 
h1 elements into links. This would not be to take anything away 
from authors, OTOH, since HTML 4 and XHTML 1 already forbid 
wrapping H1 elements inside A elements (except when it is 
surrounded by the OBJECT or MAP element).

That it *isn't* non-conforming to turn a H1 element into a link in 
HTML 5 probably is a matter of having simple rules for block 
element wrapping. And/or that it would be absurd if we should 
forbid everything that we think is a borderline case.

Linguistic grammars where all meaningless expressions are also 
considered grammatically incorrect have yet to been discovered.

> As accessibility advocates, we need to be both open to those who don't have 
> the same appreciation we do to some of the finer nuances of our specialty, 
> as well as a rich toolbox of techniques and solutions to then help them get 
> things right.  We also know that often accessibility is one of the last 
> items on the development checklist (it shouldn't be, but it is), and so 
> often we get approached at the 11th hour for the "...can you make sure this 
> passes..." request, and my having a quick fix of "...add some ARIA roles 
> here..." is significantly more palatable then my saying, "...take it back to 
> the drawing board and start over...". (You can imagine the response to a 
> statement like that 2 days before launch)  That's the real world.
> 
> We all can pretty much agree that making an <h1> a 'button' doesn't really 
> make a whole lot of semantic sense, but (as someone pointed out earlier) if 
> a content author decides, against better recommendations, to make a <h1> a 
> button that activates an accordion expansion, then we should be able to 
> convey that important information to AT in all its wrongness - not being 
> able to do so penalizes the AT user, not the content author.

I prefer to argue from another angle. However, I have come to the 
same conclusion as you.
-- 
leif halvard silli
Received on Tuesday, 10 November 2009 19:19:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:16:07 GMT