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

stephane.deschamps@orange-ftgroup.com On 09-11-09 14.15:

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

May be I did not get what you meant.

But ARIA is an advanced accessibility feature. Not all user agents 
supports it. If we permit @role to diverge in a confusing way from 
the default role of the element, then we risk that old and new 
user agents see the same element differently.

Therefore I would argue that it is more backward compatible to use 
the HTML 4 included <button> element, which in ARIA aware user 
agents defaults to role="button", rather than to use the <a> 
elements with role="button", and risk that the old user agents 
presents it as a link.

If IE6 doesn't support the button element (does it?), then  we 
should look at that specific problem. May be that's and issue that 
means we require looser rules for ARIA @role. However, authors 
should still, in some way, be recommended by the validator to use 
the <button> element instead of <a>.
-- 
leif halvard silli

Received on Monday, 9 November 2009 17:01:48 UTC