- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 22 Oct 2009 09:42:50 -0500
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: 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>
On Thu, Oct 22, 2009 at 9:32 AM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > Tab Atkins Jr. On 09-10-22 16.13: >> 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? >> >> You can't break the web unless a particular practice is already >> widespread and changing the current behavior for it would be >> detrimental to sites relying on the current behavior. >> >> Are there a significant number of sites currently using <h1 >> role=button> and expecting it to be presented as a button to ATs? Are >> there ATs who *do* present it as such? >> >> Both of those have to be true before "don't break the web" becomes >> relevant. > > I agree that those questions are relevant. But one could just as well turn > them and say: "Do you want to forbid aria="button" on a <h1>? Well, then you > should first check that no sites do this, and that no user agents support > it!" Well, since aria just recently got put into HTML, I suspect it's not widely used yet. (I'm asking around for possible evidence.) > The spirit of "don't break the Web" is "don't destroy the experience for the > user because of some principle". Yup, but in the absence of evidence, you might as well go with the principle. If evidence shows up later, you can always change things. > For CSS it is simple: You can style a <h1> as you wish, including ways that > allow it to be used in non-conforming ways - even if such uses probably are > quite seldom. During the specification work of this group, we have a number > of times stumbled upon difficulties because some targeted UA hasn't had full > CSS support for *all* elements of HTML. (<legend>, anyone?) > > Why should ARIA work any different from CSS? > > I think, in general, it only becomes difficult for authors, for spec editors > - for everyone - if we mix what authors should do (semantics) with how user > agents should act (parsing etc). 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. As well, it's really just more trouble than it's worth to restrict CSS to only apply 'conforming' styling - the operations are too low-level to sanely constrain. ARIA, on the other hand, is a high-level tool that *can* be sanely restricted. ~TJ
Received on Thursday, 22 October 2009 14:43:39 UTC