Re: Alternative to @aria-describedAT: <a role=img>

Benjamin Hawkes-Lewis, Tue, 10 Apr 2012 22:03:53 +0100:

>> my conclusion, is that, per the ARIA spec, then a 
>> <a role=img href=* > is distinctly different from 
>> <a role=presentation href=* >.
> 
> Per the HTML5 and ARIA specs, yes.
> 
>> Which strengthens me in the view that HTML5 ought to
>> permit <a role=img href=* >.
> 
> I don't see how that follows from the difference.

It follows from the fact that <a role=presentation> cannot do what <a 
role=img> can do, and from the fact that I want done what <a role=img> 
can do.

>> Agreed?
> 
> If anything, I think it would be more consistent to expand the
> processing of "presentation" so that other role annotations that do
> not imply interactivity (like "img") never supplant native semantics
> that do imply interactivity (like "a href").

So, when, at some point @aria-describedAT materializes, would e.g. 
<table aria-describedAT="link"> then be an interactive element?

And what is the correct role for <img usemap> (which is considered 
interactive per HTMl5) ? 

And what is the problem with <a role=img href>? What's the principal 
issue?

>> Btw, it seems seems to me that not only VoiceOver+Safari but also Jaws
>> 13 have incorrect behavior as it does not expose the link-i-ness of <a
>> role=img>.
> 
> Is that because of JAWS or because of what browsers are exposing to
> the accessibility tree?

I suppose it is JAWS because JAWS is known to not rely on those API.
-- 
Leif H Silli

Received on Tuesday, 10 April 2012 23:02:20 UTC