- 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:07 UTC