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

Benjamin Hawkes-Lewis, Wed, 11 Apr 2012 00:55:26 +0100:

> I don't see the advantage of:
> 
>   <a role=img href=u id=a aria-label=LinkText aria-labelledby='a i'>
>   <img longdesc=u id=i alt=Alt-Text src=i ></a>
> 
> over the simpler, conforming, robust alternative:
> 
>   <a href="october-sales.html"><img alt="October Sales"></a>

In the first example, you include @longdesc. You support @longdesc, so, 
why do you ask why? Don't @longdesc have advantages?

> You say it "suppresses the 'normal' link announcement" (implicitly by
> screen readers), but I don't get how that helps end-users.

The goal is to create the "longdesc experience" via the the anchor 
element. Do you see @longdesc as something to use when one cannot use 
an anchor?

To me, the advantage of @longdesc is that that instead of taking the 
focus away from the image - like a normal link often does, it instead 
focus in on the image. So I don't see the longdesc concept as only 
something you do when you can't/shouldn't/isn't allowed/whatever to use 
an anchor element.

I don't take lightly on the "longdesc imitation": I use aria-label etc 
to tell non-Jaws etc that there is long description available.

>>> 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?
> 
> If it materializes, and if it's defined to imply interactivity, and if
> user agents actually implement interactivity on the basis of it, then
> I guess so.

OK. aria-describedAT would not not have any effect on e.g. <span  
aria-describedat=*>. I suppose no one would "see" it. But if you did 
<span role=img aria-describedat=*>, then one would see it.

>> And what is the correct role for <img usemap> (which is considered
>> interactive per HTMl5) ?
> 
> When I said "interactive" I wasn't particularly talking about HTML5
> content models.

Ah, there you have it. Yes, I see that my question was unclear.

> As currently specified, the <img> element would imply an "img" role
> and the <area> elements would each individually imply the "link" role.

I agree about <area>. Not so sure about <img usemap=#name>. You can't 
wrap a link around it - it is forbidden, because it is interactive. 
And, also, it is supposed to react to CSS such as

   *:link{border:1px solid blue}

So, by all means, it is interactive. And my hunch is that, because it 
is interactive, the role=img is not the most logical role. Or, at 
least: What is then the difference between <a role=img> and <img 
usemap=#l>? 

>> And what is the problem with <a role=img href>? What's the principal
>> issue?
> 
> Representing a link to AT as an image instead of a link seems unlikely
> to reflect author intent.

That doesn't sound like a principal issue, to me. They say that ARIA is 
like CSS. And so, as author, I would like to use it as freely as 
possible.

>>>> 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.
> 
> I think you'll find it uses both. See, for example:
> 
> http://www.paciellogroup.com/blog/2010/10/jaws-support-for-aria/

Right. I think so too. But Firefox does present <a role=presentation 
href> as a link, and so I think that in this case, it is Jaws. You 
know, Jaws tries to be cross browser - and that always impacts things, 
I guess. E.g., if I got it right, then IE presents <a role=presentation 
href> as *not* a link.
-- 
lhsilli

Received on Wednesday, 11 April 2012 02:25:05 UTC