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: Steven Faulkner <faulkner.steve@gmail.com>
Date: Tue, 10 Nov 2009 16:50:58 +0000
Message-ID: <55687cf80911100850x7b3cf881i3684444687fbdf76@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Charles McCathieNevile <chaals@opera.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, 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>
hi tab,

>Damn, I was sort of hoping it *wasn't* supported in that particular
>way yet.  Well, that's existence proof at least, even if it's sort of
>crazy to me.

as per the ARIA spec, ARIA roles always override native roles, this is
implemented in FF and IE haven't checked safari and chrome, but would
suspect it is the same.


2009/11/10 Tab Atkins Jr. <jackalmage@gmail.com>

> 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
> <chaals@opera.com> wrote:
> > On Thu, 22 Oct 2009 16:42:50 +0200, Tab Atkins Jr. <jackalmage@gmail.com
> >
> > wrote:
> >> Well, since aria just recently got put into HTML, I suspect it's not
> >> widely used yet.  (I'm asking around for possible evidence.)
> >
> > Suspicion is not proof. ARIA has been around for a long time (longer than
> > HTML5, for example) and included in HTML content whatever the spec said
> > before (through various Javascript libraries and products from and for
> large
> > organisations, as noted elsewhere in the thread).
> >
> > Some user agents, and some assistive technologies, already support ARIA.
> A
> > 3-minute test case
> >
> > <html dir="ltr">
> > <head>
> >  <title>Blank page</title>
> > </head>
> > <body><h1 role="button">test</h1>
> > <button>test</button></body></html>
> >
> > running in Opera 1010 Mac (last week's weekly[1]) with VoiceOver 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.  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.
> >
> > I have been told various times that HTML 5 is about what happens in the
> real
> > world (indeed, I promote that benefit consistently in my mnay talks on
> the
> > topic), but I am ready to see the evidence.
> So you're reasonably certain that presenting that <h1> as a button in
> accessibility devices is indeed a good thing for users?  And that
> officially blessing this usage is better than attempting to evangelize
> for more appropriate usage in the first place, obviating the need for
> (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!)
> >> 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. In which case the
> expected
> > use is where authors don't do the right thing. If you make that
> > non-conforming, you can already argue that your authors don't care about
> the
> > semantics of conformance anyway, perhaps just the yes/no status. I am not
> > sure how you get from there (with or without the last assumption) to
> > shouldn't be conforming where it is used in ways that match its use cases
> > and what authors actually do".
> Well, no.  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.
> I'm saying that I *don't* think ARIA should be a patch for when
> authors do crazy things.  In my experience it's always possible, and
> usually pretty easy, to comply with HTML's default semantics.  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.)
> ~TJ

with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
Received on Tuesday, 10 November 2009 16:51:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:42 UTC