W3C home > Mailing lists > Public > public-html@w3.org > October 2009

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 22 Oct 2009 09:42:50 -0500
Message-ID: <dd0fbad0910220742l42a3f7cdn5d20888862fcfbca@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC