- 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 "Charles McCathieNevile" <chaals@opera.com To > "Tab Atkins Jr." Sent by: <jackalmage@gmail.com> wai-xtech-request cc @w3.org "Leif Halvard Silli" <xn--mlform-iua@xn--mlform-iua.no>, "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> Subject Re: ARIA roles added to the a element should be conforming in HTML5. On Tue, 10 Nov 2009 17:42:31 +0100, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > 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 place. 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 much. cheers Chaals -- 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
Attachments
- 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