- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 17 Jun 2010 00:46:43 +0200
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, public-html@w3.org, public-html-request@w3.org
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