- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 21 Oct 2009 12:08:10 -0500
- To: Steven Faulkner <faulkner.steve@gmail.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, HTMLWG WG <public-html@w3.org>, public-html-request@w3.org, W3C WAI-XTECH <wai-xtech@w3.org>
- Message-ID: <OFB6507F3D.095B1377-ON86257656.005BD322-86257656.005E216C@us.ibm.com>
Jonas,
The bottom line is that unless in HTML we are going to rip script and CSS
support out of a broad range of HTML elements authors will repurpose them.
Authors do not adhere to a utopion world where they follow the intent of
the HTML working group intended. As you can imagine, IBM alone has hundreds
of software products, many web based. More often than not a product team
will create a custom control to differentiate themselves from their
competitors and to add features that the HTML working group did not think
of. They don't care whether you, me, or anyone else says they should use
the button provided in HTML. If you tried we tried to stop these practices
from happening, by removing the script capability on an element, developers
will not use HTML 5 and most likely object to HTML 5 standardization.
There is absolutely, no way we can remove ARIA attributes from the list of
elements in the spec. because authors will repurpose them. The ONLY thing
we can do is:
- recommend that authors use the standard controls provided in HTML
- Ensure that ARIA attributes for states and properties do not conflict
with the native host language state and property by saying the host
language takes precedence. For example, aria-checked when applied to a an
HTML checkbox does not override the checked stated implied by the control
Frankly, all of us in accessibility would prefer users use standard
controls. It makes our life MUCH easier. Unfortunately, that is not the
world we live in. So, we need ARIA to convey the author's intent. Failure
to provide ARIA capability to the author is a failure in the HTML working
group to address accessibility.
Rich
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Steven Faulkner
<faulkner.steve@g
mail.com> To
Sent by: Jonas Sicking <jonas@sicking.cc>
public-html-reque cc
st@w3.org HTMLWG WG <public-html@w3.org>, W3C
WAI-XTECH <wai-xtech@w3.org>
Subject
10/21/2009 02:48 Re: ARIA roles added to the a
AM element should be conforming in
HTML5.
Hi jonas,
the examples are not sites but YUI and and jQuery widgets, so they are
being used on many sites.
>Wouldn't it be better for these sites to use a <button> element
>instead? Or maybe they currently "can't" because you can't style a
>button enough to give it the desired rendering.
of course it would be, but the developers have decided to use the a
element.
a related example: wouldn't it be easier for example for the gmail
developers to use a <button> for the "search mail" button in gmail
instead of
<DIV id=:r9 class="J-K-I J-J5-Ji ipG21e J-K-I-JW" tabIndex=0
closure_hashCode_5dymj1="112" act="" unselectable="on"><DIV class="J-J5-Ji
J-K-I-Kv-H" unselectable="on">
<DIV class="J-J5-Ji J-K-I-J6-H" unselectable="on">
<DIV class=J-K-I-KC unselectable="on">
<DIV class=J-K-I-K9-KP unselectable="on"> </DIV>
<DIV class=J-K-I-Jz unselectable="on">Search
Mail</DIV></DIV></DIV></DIV></DIV>
styled and scripted to look and act like a button?
I would think yes, but they obviously don't
best regards
Stevef
2009/10/21 Jonas Sicking <jonas@sicking.cc>
On Wed, Oct 21, 2009 at 12:17 AM, Steven Faulkner
<faulkner.steve@gmail.com> wrote:
> Currently the a element is defined in the HTML5 specification as an
element
> that cannot have its native role overriden by ARIA roles [1]
>
> This is contrary to use in the wild as it has been overriden by the
addition
> of a number of roles in popular javascript UI libraries.
>
> Examples:
> button
> http://jqueryui.com/demos/dialog/
>
http://developer.yahoo.com/yui/examples/carousel/carousel-ariaplugin_source.html
> tab
>
http://developer.yahoo.com/yui/examples/tabview/tabview-ariaplugin_clean.html
> menutiem
> http://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html
>
> It is important to understand that it is not ARIA that is making the
link
> into a button, its the developers use of javascript, event handlers and
CSS
> that is making it look and act like a button or tab or menutiem. The
> addition of ARIA is merely providing the information that other users
get by
> default. So making the addition of an ARIA role non conforming, to an
> element that has been designed to act and look like something other
than its
> native role, is not the appropriate repsonse.
Wouldn't it be better for these sites to use a <button> element
instead? Or maybe they currently "can't" because you can't style a
button enough to give it the desired rendering.
/ Jonas
--
with regards
Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium
www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic07641.gif
- image/gif attachment: ecblank.gif
Received on Wednesday, 21 October 2009 17:09:05 UTC