Re: Change proposal for ISSUE-85

Rich Schwerdtfeger
CTO Accessibility Software Group

public-html-request@w3.org wrote on 06/15/2010 10:19:58 PM:

> From: Ian Hickson <ian@hixie.ch>
> To: public-html@w3.org
> Date: 06/15/2010 10:21 PM
> Subject: Change proposal for ISSUE-85
> Sent by: public-html-request@w3.org
>
>
> 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.
>
Ian,

Buttons have been around in HTML for years. You seem to be misinformed
about what the mainstream development community is doing. It would benefit
you to walk down the hall and talk to the gmail people who in fact have
used <a role="button"> themselves. I don't know if it is in there today but
they have done it.

The reality is developers want to create custom UI components and nobody
has an all knowing crystal ball to determine all the ways someone wants to
create a button.

> 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.
>
Well, like I said I think gmail has a rather large install base. Somehow
they have managed. They are not alone by the way.

> 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.
>
Over 90 percent of the web sites today use script. I think those user
agents have a problem.

> Some examples of #3 are the text-based browsers, most search engines, and

> graphical browsers in which CSS or scripting are disabled.
>
They are missing out on a lot of content. Many web pages only have script
on them.

> The only way to keep things consistent amongst all three is to use HTML
> elements appropriately, and not override their semantics with ARIA.
>
So, what you want to do is use accessibility as a vehicle to enforce your
vision of sticking to host language semantics.
You want to tell someone who is trying to make their web page accessible be
an HTML villain - per your WhatWG post:
http://krijnhoetmer.nl/irc-logs/whatwg/20100616#l-228


[04:58] <othermaciej> it disallows the concept with a non-machine-checkable
requirement, but does not make the syntax an error
# [04:58] <othermaciej> however, it does make the syntax <a role="button">
an error
# [04:58] <Hixie> right, role="" is a godsend here
# [04:58] <othermaciej> with a machine-checkable rule

If you remove the ARIA role semantics it means that authors are free to
produce inaccessible content when they use script and CSS. I mean you don't
suggest
it is a failure if you add script and CSS so they will go right along doing
it. This is how we got into the situation where we needed ARIA. We failed
by not giving
the authors the vehicle to convey their intent and put ridiculous
requirements that stated you were accessible - only if script and CSS were
disabled in your browser. New accessibility regulations
remove technology restrictions and now REQUIRE that you convey the semantic
information accurately. This applies to WCAG 2 and the 508 refresh.
You suggest it would only be an error if the author made it accessible by
passing the role attribute.

So, what you are doing is sending HTML 5 down a path where the
accessibility community states that if you use
script your web page will be inaccessible. Government agencies will then be
then re-directed not to touch HTML 5 by the
advocacy groups and your timing could not be worse as all the government
accessibility regulations are being re-written.
We can't have that ...

So, another solution, to achieving your vision, is for you to remove CSS
and Script from HTML 5 and state that authors need to use the host
language as is. Then things will work in all the browsers and your text
based browsers and search engines can work to their
hearts content. That might mean you have a limited audience for HTML 5. It
will also create a monumental problem for WhatWG members who
have invested so much in using it.

So, my position is that I am against idiotic conformance requirements that
prevent real people from not using combinations of ARIA, script, and
CSS that are accessible. I do not believe in restricting the author in the
way you are suggesting. I prefer to give the author the tools they need to
do
what they want and be accessible.

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

The accessibility task force has looked at the HTML 5 elements and will
provide a list of where ARIA should override HTML semantics for the
assistive technology and where it will not. In most cases we have
prohibited ARIA from being applied to interactive widgets as it would
interfere with its operation in terms of what is applied to the AT.  Link
is commonly overriden to be a button in the real world. Why?
because it is keyboard navigable, you can click it, it is scriptable, and
it is stylable. Prohibit script and CSS and it is just an anchor - which
is what you want but not what developers want.

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