Re: Change proposal for ISSUE-85

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