- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 15 Jun 2010 14:36:10 -0400
- To: Ian Hickson <ian@hixie.ch>
- CC: Steven Faulkner <faulkner.steve@gmail.com>, public-html@w3.org
On 06/06/2010 03:27 PM, Ian Hickson wrote: > > 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. Steven makes the case that this reasoning also applies to style attributes and href attributes with javascript: schemes. See also bug 9872: Care to update your proposal to address (either by incorporation or refutation) this? > 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. - Sam Ruby
Received on Tuesday, 15 June 2010 18:36:42 UTC