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

On Wed, Apr 11, 2012 at 12:01 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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.

OK.

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>

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

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

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

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

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

>>> 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/

--
Benjamin Hawkes-Lewis

Received on Tuesday, 10 April 2012 23:56:15 UTC