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

Lars Gunther wrote:
>
> > The harm that I see is loosing the ability to have a clear message for
> > what the right way to do things is.
> 
> This was my fear as well when I tried to suggest a middle ground for
> this issue. Since it was a awhile I'll repeat myself.
> 
> <a role="button"> should be forbidden when hard-coded onto the page for
> these reasons:
> 
> 1. It is sloppy markup. Conformant HTML should be the best possible.


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?

At that point, we're talking about remediation, which is never pretty,
often painful, but also quite necessary.  So we tell the author,
"...despite what you should be doing, you are doing something else.
Therefore, if you insist on doing that, can you at least signal to AT what
your intent is?"  Author, "Sure, but when I add @role to that element, the
validators(s) flags my content as non-conformant, where before, without
the @role statement, it *was* conformant" (from the technical perspective,
not the greater semantic/logic perspective).

Now what? We've just created a scenario where _reducing_ accessibility
improves conformance results - what's wrong with *that* picture?

This topic was discussed at the TPAC meetings last week, and the minutes
of that meeting are at: http://www.w3.org/2009/11/05-aapi-minutes.html
This very issue led off the discussion.

As I understand it, the idea is that we have groupings that *might* make
sense (even if 'bad') and give the author an advisory, but let it pass
through. (Sort of like the 'deprecated' state... you really shouldn't but
better than nothing). I'd rather have a 60% win then a 100% fail when it
comes to accessibility.

> 
> 2. It is possibly confusing if JavaScript is turned off, since it will
> not act as a button in that case.
> 
> The validator's error message should be carefully worded to suggest that
> authors instead of removing @role change the tag to <button>


The current notion is that, while we certainly want to try and train
authors to do the better thing, we need at the same time to accept that
sometimes they won't, and in those cases 'bolting on' an accessibility
enhancement, while not optimum, is better than doing nothing, and throwing
a validation error when we do that is just counter-productive.  Thus the
messages need to be of the advisory nature, rather than the "bad author"
nature, and likely the author should be able to toggle off those
advisories as required ("Yes, I know that you want me to do it a better
way, but I won't, I'm doing it this way and here's the ARIA part for
Accessibility, so leave me alone")


> 
> YUI, JQuery, Prototype/Scriptaculous, Dojo can be evangelized into
> setting @role dynamically (if that's not the case already) and have
> their manuals suggest such usage as well.
> 
> If they get it right, so will 95 % of all websites.

+1, and further, the authors of those libraries will likely do a better
job getting it right from the get-go, so we can hold out hope.  But as my
granny used to say, let's not cut off our noses to spite our faces.

JF

Received on Monday, 9 November 2009 20:22:06 UTC