Re: Change proposal for ISSUE-85

I have filed 2 bugs in relation to the issues that you have brought up:

trigger a conformance error when javascript is included in href attribute
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9872

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 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 09:11:32 UTC