- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 7 Jun 2010 10:03:08 +0100
- To: Ian Hickson <ian@hixie.ch>
- Cc: Sam Ruby <rubys@intertwingly.net>, public-html@w3.org
I have filed 2 bugs in relation to the issues that you have brought up: trigger a conformance error when javascript is included in href attribute http://www.w3.org/Bugs/Public/show_bug.cgi?id=9872 provide normative advice to conformance checkers about use of onevent handler attributes: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9871 regards stevef On 6 June 2010 20:27, Ian Hickson <ian@hixie.ch> wrote: > On Sun, 6 Jun 2010, Sam Ruby wrote: >> >> Do you both agree with the following statement? >> >> Making a link act like a button to non-ATs while leaving it as a link >> for AT users will lead to AT users having a confusing experience, since >> the author will think the link is going to appear as a button to users >> and may refer to it as such. > > Yes. And vice versa. That's why <a> elements shouldn't be allowed to be > marked as role=button, and <button> elements marked as role=link, and > authors shouldn't make one look like the other. (Currently, HTML5 > disallows both using ARIA in this manner and using HTML in this manner.) > > What's important to remember is that there are more than two kinds of user > agents; there are at least three: > > 1. User agents with scripting, CSS, etc, which can be made to render > elements (like <a>) as other elements (like <button>). > > 2. User agents with ATs, which report the accessibility mapping described > with ARIA, defaulting to the default semantics of the elements. > > 3. User agents without CSS support or without scripting support, and > certainly without ATs, which always use the default semantics of the > elements. > > Some examples of #3 are the text-based browsers, most search engines, and > graphical browsers in which CSS or scripting are disabled. > > The only way to keep things consistent amongst all three is to use HTML > elements appropriately, and not override their semantics with ARIA. > > ARIA is great when you're creating new widgets that aren't in HTML yet: it > allows you to create pages that work in #1 and #2, covering the vast > majority of users, at the cost of #3, who wouldn't be able to experience > the new widget at all anyway. However, when HTML provides the widget you > need, as in the case of a button or a link, and #3 already supports that > widget and therefore there is no need to fake it. In these cases, ARIA is > unsuitable and unnecessary. Validators flag the use of ARIA in these ways, > since there is a net benefit to using appropriate elements instead of ARIA > in those cases. > > > Updated change proposal with the above: > > ISSUE-85 > ======== > > SUMMARY > > Don't allow people to use ARIA to write inaccessible documents. > > > RATIONALE > > ARIA is useful for authors who need to make new widgets that HTML doesn't > yet support. Buttons are supported by HTML, and therefore there is no > reason for an author to make a link act like a button to ATs. > > Making a link act like a button to ATs while leaving it as a link for > non-AT users will lead to non-AT users having a confusing experience, > since the author will think the link is going to appear as a button to > users and may refer to it as such. > > What's important to remember is that there are more than two kinds of user > agents; there are at least three: > > 1. User agents with scripting, CSS, etc, which can be made to render > elements (like <a>) as other elements (like <button>). > > 2. User agents with ATs, which report the accessibility mapping described > with ARIA, defaulting to the default semantics of the elements. > > 3. User agents without CSS support or without scripting support, and > certainly without ATs, which always use the default semantics of the > elements. > > Some examples of #3 are the text-based browsers, most search engines, and > graphical browsers in which CSS or scripting are disabled. > > The only way to keep things consistent amongst all three is to use HTML > elements appropriately, and not override their semantics with ARIA. > > ARIA is great when you're creating new widgets that aren't in HTML yet: it > allows you to create pages that work in #1 and #2, covering the vast > majority of users, at the cost of #3, who wouldn't be able to experience > the new widget at all anyway. However, when HTML provides the widget you > need, as in the case of a button or a link, and #3 already supports that > widget and therefore there is no need to fake it. In these cases, ARIA is > unsuitable and unnecessary. Validators flag the use of ARIA in these ways, > since there is a net benefit to using appropriate elements instead of ARIA > in those cases. > > > DETAILS > > No change. > > > IMPACT > > POSITIVE EFFECTS > Encourages authors to use HTML as intended, which increases the total > accessibility of the Web. > > NEGATIVE EFFECTS > None. > > CONFORMANCE CLASS CHANGES > None. > > RISKS > None. > > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- 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
Received on Monday, 7 June 2010 09:11:32 UTC