Re: Change proposal for ISSUE-85

Richard Schwerdtfeger, Wed, 16 Jun 2010 17:05:16 -0500:
> Jonas Sicking <jonas@sicking.cc> wrote on 06/16/2010 04:28:03 PM:
>> From: Jonas Sicking <jonas@sicking.cc>

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

What about this: ?

 <img role="presentation" alt="Filler text" src="..."> 

A logical solution could be to say that the @alt attribute should be 
empty. 

>> > # [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"

But it is a fact that @role allow us to check for more conformance 
errors than HTML4 allows. It is another matter a) how serious it should 
be considered to use <a> as a button and b) what kind of error message 
there should be. It may be simpler for authors to use <a> than to use 
<button>. 
 
> So Ian is suggesting that someone who makes an attempt to make 
> something accessible gets an error or a warning.

If using <button> instead of <a> is difficult, then, yes it is a 
problem. 

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

The "yes, please, both" doesn't always work: <figure> supposedly 
blesses authors who want to be accessible. And if they add funny 
@role's to <figure>, they should only receive even more blessing? And 
never a complaint or warning that they do it wrong? Where is then the 
blessing and benefit of using <figure>?
 
>> 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.

May be it is a bug. Certainly, if your view "wins", then it is. But the 
language - HTML - kind of becomes turned on its head that way. And, at 
the very least, it is not very compatible with *current* user agents - 
not even if you XHTML5 instead of HTML5 ...

>> 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.
>> 
> See Ian's statement above - "godsend". 

See the WAI CG Consensus document: [1] "automatic validators can detect 
the presence/absence of @alt but in general cannot certify the 
correctness of the text string." With @role="presentation", they can 
test the correctness better.

[1] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
--. 
leif halvard silli

Received on Wednesday, 16 June 2010 22:47:18 UTC