- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 10 Nov 2009 20:18:36 +0100
- 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 UTC