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: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 6 Nov 2009 14:14:40 -0600
To: "John Foliot" <jfoliot@stanford.edu>
Cc: "'HTMLWG WG'" <public-html@w3.org>, public-html-request@w3.org, "'W3C WAI-XTECH'" <wai-xtech@w3.org>
Message-ID: <OF6D94606E.AC26DE2E-ON86257666.00598F65-86257666.006F34D9@us.ibm.com>
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

public-html-request@w3.org wrote on 10/21/2009 06:23:20 PM:

> "John Foliot" <jfoliot@stanford.edu> 
> Sent by: public-html-request@w3.org
> 
> 10/21/2009 06:23 PM
> 
> To
> 
> "'HTMLWG WG'" <public-html@w3.org>
> 
> cc
> 
> "'W3C WAI-XTECH'" <wai-xtech@w3.org>
> 
> Subject
> 
> RE: ARIA roles added to the a element should be conforming in HTML5.
> 
> Thoughts on this thread:
> 
> Thomas Broyer wrote:
> >
> > The fact that the developer can technically turn an <a> into a button
> > isn't a justification for making it conforming. If it's not a link but
> > a button, you should use <button> or <span role=button>.
> >
> 
> The fact that we are seeing this in the wild, and that non-conformant 
pages 
> still render in all browsers (and will continue to do so) is 
justification 
> enough that ARIA added here should not 'add' to the non-conformance. 
ARIA 
> is an attempt to provide real solutions to real problems, and if a 
developer 
> can turn an <a> into a button and have it render on screen, that is a 
real 
> problem.
> 
> 
> 
> Maciej Stachowiak wrote:
> >
> > ... a funky custom role
> > on <h1>. But it does seem fairly common to use an <a> element with
> > styling and a click event listener or javascript: URL as a button,
> > instead of as a link. Is it worthwhile for the spec to tell people
> > doing such things that they are wrong?
> 
> 1) ARIA is no more 'funky' than microdata - and in fact is much more 
mature. 
> Bad choice of description.
> 
> 2) Having the spec introduce or take advantage of a teachable moment is 
good
> 
> 3) Why *can't* any element take an ARIA role if it is appropriate? Given 

> the desire to have as much accessibility baked in as possible, this 
seems 
> like a trivial thing to add to the spec - any element can take an ARIA 
role 
> if/when required.  Why limit it to a subset of the entire tool-box?
> 
> 
> 
> Henri Sivonen wrote:
> >
> > Styling h1 to be a button probably isn't a cowpath.
> >
> 
> Right, but it *is* a potential out-lyer, and more importantly, what 
*harm* 
> is inflicted by allowing the <h_> element to take an ARIA role?
>
All we are doing is allowing the author to convey their intent. Do I wish 
authors would use html elements for their purpose? Of course. That is not 
the world we live in. Whether we believe something is a cowpath is really 
irrelevant. Industry thought HTML was only for documents in 1998 too. 
> 
> 
> Ian Hickson wrote:
> >
> > Conformance is about what developers _should_ do, however.
> >
> 
> There is however no real penalty for non-conformance, so that really 
doesn't 
> mean a whole bunch in the grand scheme of things.  If however you truly 
> believe that conformance is "...what developers _should_ do...", then 
they 
> _should_ add ARIA role information to any element that they have 
> 'repurposed' via scripting and CSS, to, as Steven states "Make sense out 
of 
> non-sense" for users of AT.  And to do this 'legally' the spec must say 
they 
> can...
> 
> JF
> 
> 
> 
> 
> 
Received on Friday, 6 November 2009 20:15:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:16:07 GMT