Re: ARIA roles added to the a element should be conforming in HTML5.

hi Lars,

>If an author cares enough to validate his or her code, my estimation is
that he or she also cares enough to fix the markup. After all, that is what
you'll do with >any non ARIA-related validation error.

then a set of conformance rules should be developed that calls out as
invalid the code structures that result in the need for the use of ARIA, for

<a href="#" onclick="some function()">

should throw an error as it overrides the a element. semantic.

<p onclick="somefunction()">

should throw an error as it is not actionable with the keyboard.

code  'report spam' button from google mail:
<DIV class="J-K-I J-J5-Ji J-K-I-Js-Kc J-K-I-Js-KK  J-K-I-JW" tabIndex=0
closure_hashCode_frqwon="22012" act="9" unselectable="on"><DIV
class="J-J5-Ji J-K-I-Kv-H" unselectable="on">
<DIV class="J-J5-Ji J-K-I-J6-H" unselectable="on">
<DIV class=J-K-I-KC unselectable="on">
<DIV class=J-K-I-K9-KP unselectable="on">&nbsp;</DIV>
<DIV class=J-K-I-Jz unselectable="on">Report

code patterns such as the above could reliably be found and flagged as poor
coding practice.

There are many such examples in the wild that are both poor coding and cause
accessibility issues.
The addition of ARIA code to better convey to users the behaviour and
interaction model (ie improve the accessibility) of a a particular code
construct should not be the point where we attempt to start teaching


2009/11/10 Lars Gunther <>

> 2009-11-09 21:21, John Foliot skrev:
> You likely will not get any argument here, but what happens when an author
>> *DOES*  create sloppy code? We can 'forbid' it all we want, but unless the
>> browsers refuse to render what the author has created (they won't), then
>> forbidding alone is not the answer. Moreover, despite pleading, discussion
>> and argument, if the author cannot or will not change their code, then
>> what?
> If an author cares enough to validate his or her code, my estimation is
> that he or she also cares enough to fix the markup. After all, that is what
> you'll do with any non ARIA-related validation error.
> As has been pointed out, a validator can not fix everything. It's a tool
> for authors to use, but it requires knowledge. E.g. a big public Swedish
> site (hat tip Peter Krantz) has hundreds of these:
> <img src="spacer.gif" alt="typographic air">
> Perfectly valid, totally wrecking accessibility.
> Anyway, I appreciate Steven's and your drive to see ARIA adopted. But the
> main issue must be that a validator checks for valid code. In the long run
> nothing serves accessibility more than clean, semantic markup.
> As for discussed use cases:
> 1. To style a link as a button, having JavaScript turned off, is bad
> practice. If the validator catches such bad practice, all the better.
> 2. If the validator in the future can be used to validate the DOM as well
> as well as the original markup (an idea I support, BTW) we have two options:
> a. The author may be knowledgeable enough to disregard any reports about a
> and @role="button" mismatches.
> b. Such disregarding can be done automatically, perhaps with a script or a
> toggle.
> Let's consider for a while what we lose if we allow <a role="button">:
> * Student's will miss out on a learning opportunity. The quicker you get
> their minds on the right path, the better, in my experience.
> * People that do care and want to do the right thing and that would indeed
> fix their markup, might miss this opportunity, since the mismatch is not
> pointed out to them.
> The more knowledgable authors there are in the world, the more we will have
> good role models, good blog posts, good books, good advice on discussion
> forums and mailing lists. Thus what is best for education will be best for
> accessibility in the long run.
> --
> Lars Gunther

with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium |
Web Accessibility Toolbar -

Received on Tuesday, 10 November 2009 09:54:08 UTC