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

Hello Sam,

Here is one real use case:

I designed DHTML menus, like everyone using unordered lists and links, and
then added roles for browsers that do understand them.

Here is the thought behind that: if your browser or AT don't understand
ARIA, you will understand that the menu is made up of links, and then
clicking these links will take you to whatever page/action this link points
to.

If you have an ARIA-enabled browser, you'll likely prefer to hear that this
link is menu item 3 of 5 in such-and-such submenu.

Thus I *need* to add a @role to an A element, for accessibility purposes as
well as backward-compatibility (my company is stuck with IE6 and will
probably be stuck with IE7 or IE8 for a few years in the future).

Samely, what I would call "fallback behaviour" (for lack of a better word,
feel free to correct me if 'fallback' is misused) applies when I do popins.
Focusable elements made up out of links (or link images) are what my blind
colleagues expect. They're not there yet regarding ARIA, but a /de facto/
expectation in the users I know is that buttons are represented by links. As
has been said in this thread, sure it might not be true to the letter of the
HTML spec, but it's there.

Excluding it from the spec as no-can-do will not make this use disappear
anytime soon, I should say.

So we can tell people to use buttons to close popins, for instance. Let's
assume we do, and it works. Yet what can we do for menuitems and still have
an expectable behaviour if we do not allow this role on <a> elements?
Enabling this is a great way to push accessibility forward as a progressive
enhancement.

The same can be said of tab bars as well (a role="tab" as has been pointed
to by Steven).
 
-- 
Kind regards,
Stéphane Deschamps
FT/SI/DDSI/APT/MOD/ IT Accessibility
  Web HCI expert


-----Message d'origine-----
De : Sam Ruby
Envoyé : lundi 9 novembre 2009 13:26
À : Steven Faulkner
Objet : Re: ARIA roles added to the a element should be conforming in HTML5.


It is my experience that conversations are more productive when anchored 
by specifics.  Given that there are implementations, instead of simply 
saying "Y should be allowed", statements like "tool X does Y for reason 
Z; Y is currently considered non-conformant; which should change, X or 
the draft?" would likely end up with a better (and quicker) outcome.




*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

Received on Monday, 9 November 2009 13:16:25 UTC