- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Tue, 15 Jun 2010 19:49:29 +0100
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org
there is also another bug related to this: 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 15 June 2010 19:36, Sam Ruby <rubys@intertwingly.net> wrote: > 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 > -- 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 Tuesday, 15 June 2010 18:50:22 UTC