Re: Change proposal for ISSUE-85

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

Are their not legitimate use cases where keeping the consistency is
unecessary?

For example google docs, google calendar, google reader etc gives me a
message when i view it with javascript disabled

"Your browser must support JavaScript."

Also try looking at it with CSS disabled...

regards
Stevef

On 16 June 2010 04:19, Ian Hickson <ian@ khixie.ch> wrote:

>
> Updated change proposal including a discussion of links vs buttons in a
> new NOTES section.
>
> 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.
>
>
> NOTES
>
> It has been suggested that occurances of the following need role="button"
> to be made accessible:
>
>   <a href="#" onclick="action()">...</a>
>   <a href="javascript:action()">...</a>
>
> However, both are non-conforming uses of the <a> element in HTML, because
> they both use the <a> element for a purpose other than representing a
> hyperlink. They are not _syntactically_ non-conforming because they both
> have valid use cases in indistinguishable cases: <a href="javascript:"> is
> needed to expose bookmarklets to users, and onclick="" is needed for a
> wide variety of interactive purposes even on normal links (e.g. making
> AJAX applications gracefully degrade). Even a link to href="#" has some
> use cases, e.g. to link to the current page to provide the user with a
> draggable URL for bookmarking purposes. There's no reason such links
> shouldn't be made interactive (e.g. the onclick="" could just trigger a
> click animation). So we can't catch this particular case with a validator.
> It's unfortunate, but that's what happens when there are valid use cases.
>
> The role="" attribute gives us the unique opportunity to catch this
> particular error as a syntax error. This is a good thing, not a problem.
>
> In any case, the above examples should not be exposed to ATs as buttons
> widgets even if they were valid. They are exposed to users as link
> widgets, not button widgets, and thus that is the appropriate AT behaviour
> and the appropriate ARIA role.
>
>
> 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