Re: Change proposal for ISSUE-85

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