Re: Change proposal for ISSUE-85

"(Currently, HTML5
disallows both using ARIA in this manner and using HTML in this manner.)"

MAJOR difference:

<a href=# onclick="copy()"> copy</a>

this will not trigger a conformance error or warning in a conformance checker

<a href=# onclick="copy()" role="button">copy</a>

this will  trigger a conformance error.


"and authors shouldn't make one look like the other."

its not really about how they look its how they act, see example above.

"> The only way to keep things consistent amongst all three is to use HTML
> elements appropriately, and not override their semantics with ARIA."

No, the only way to keep these consistent is not to allow scripted
behaviours and events on elements that override their default
semantics.

> 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.


JavaScript 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, JavaScript is
 unsuitable and unnecessary. Validators DO NOT flag the use of
JavaScript in these ways, even though there is a net benefit to using
appropriate elements instead of JavaScript in those cases.

All ARIA roles do is convey unambiguously to AT users what the author
has created using Javascript and what is allowed in practical terms in
HTML.

regards
Stevef

On 6 June 2010 20:27, Ian Hickson <ian@hixie.ch> wrote:
> 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.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
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 Monday, 7 June 2010 07:14:14 UTC