Re: Change proposal for ISSUE-85

On Wed, Jun 16, 2010 at 3:05 PM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group
>
> Jonas Sicking <jonas@sicking.cc> wrote on 06/16/2010 04:28:03 PM:
>
>> From: Jonas Sicking <jonas@sicking.cc>
>> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
>> Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org,
>> public-html-request@w3.org
>> Date: 06/16/2010 04:33 PM
>> Subject: 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.
>>
> You don't want to fire a warning or an error on someone who is trying to
> make it accessible.

If they are doing it the wrong way then I don't see why we shouldn't.

>> >> 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.
>>
>
> Ian suggested it be used to flag an error which to quote him was a "godsend"
>
> So Ian is suggesting that someone who makes an attempt to make something
> accessible gets
> an error or a warning.

He has suggested to issue a warning when someone does something wrong,
yes. But again, no one has suggested removing anything.

>> > 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. Wefailed
>> > 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>.
>>
> Not if they override it with script and CSS. Then it may not behave like a
> button. If it does
> not and you don't convey the semantics properly you fail.

I don't understand what you are saying here.

>> > 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.
>>
> That is because the page-info dialog ignores the accessibility meta data.
> That is a bug.
> The fact that a right click does not tell that it has a role of button is
> also a bug.

If we everywhere where we looked at what the semantic meaning of an
element was we would look at not just the type of element, but also
looked at ARIA roles then that would immensely complicate the
implementation of the browser. Have you heard of any browser
developers that are willing to add that complexity? If not I think
your point is moot.

/ Jonas

Received on Wednesday, 16 June 2010 22:57:21 UTC