Re: Change proposal for ISSUE-85

On Wed, Jun 16, 2010 at 2:08 PM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
>
>
> 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.

Note that no one (as far as I can tell) is proposing that adding
"role=button" shouldn't work. Even with Ians change proposal browsers
are still *required* to forward that role to AT tools, thus leaving
the page no less accessible to users than with your change proposal.

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

Just because they have managed doesn't mean that their applications
are accessible. I have had lots of issues with accessibility and the
gmail UI and would love it if validators flagged some of the things
they are doing as invalid as to increase the chances that they will
fix it.

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

Leaving 10% of users behind would be a lot (though I do note that you
say "over 90%", so maybe the number isn't that high). How does that
compare to, for example, the number of blind people browsing the web?

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

Note that no one has suggested removing the ARIA role semantics.

> 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

That is a different situation then here though. We are providing the
vehicle to convey their intent. That vehicle is <button>.

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

Note that <a role=button> is *not* as accessible as <button> to me.
And I'm browsing with both CSS and Javascript enabled. For example it
creates the wrong context menu when I right click, and it fills the
page-info dialog with incorrect information about outgoing links.

So I don't consider it a idiotic conformance requirement to ask people
to use <button> rather than <a role=button>.

And note, all we are doing is asking them nicely to change their
markup. In no way are they punished if they don't follow our advice.
In fact, we aren't even asking them unless they ask us first by using
a validator.

/ Jonas

PS. This whole discussion is another example of how much simpler this
would be if we removed authoring requirements entirely and left that
task to lint-style tools. Then we would all be agreeing on what the
spec say.

Received on Wednesday, 16 June 2010 21:34:21 UTC