Re: Change proposal for ISSUE-85

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.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 6 June 2010 19:28:22 UTC