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

Hi Alexander,

> ----- Begin forwarded message -----
> From: Alexander Surkov <surkov.alexander@gmail.com>

>>> "user agents MUST use the semantic of the WAI-ARIA role for
>>> processing, not the native semantic, unless the role requires WAI-ARIA
>>> states and properties whose attributes are explicitly forbidden on the
>>> native element by the host language"

>> [ snip ] Why is there no MUST? Answer: Because HTML5 - currently
>>  - explicitly disallows role="img" for the <a> element.
> 
> I might miss something but ARIA implementation guide says about
> WAI-ARIA states and properties (not about roles).

Hm ... It says that *if* the role requires states and properties *whose 
attributes* are explicitly forbidden on the native element. So, yes, I 
agree that it is kind of unclear - too many ifs - to my taste. However, 
if we think about it, then i seems to me that HTML5 does not forbid the 
attributes of any states or attribute on the <img> element?

> So even if HTML 5
> disallows role="img" for the <a> then ARIA implementation guide
> requires UA to ignore <a> native semantics. But I would love to see
> ARIA implementation guide respecting what HTML5 says.

I think you got it wrong: It is *HTML5* which eventually needs to 
forbid something. (Because WAI-ARIA is a "hyper-language/meta language" 
which just makes its resources available to *any* host language.)

>>> It sounds reasonable with me if ARIA would add or extend native
>>> semantics rather than completely remove it. From the user/web author
>>> point of view I don't see any benefits that AT users see an image but
>>> sighted users see a normal link.
>> 
>> HTML5 already disagrees with you: It allows role=presentation on both
>> <a> and <img>.
> 
> I didn't mean anything about role=presentation since it's sort of
> special role ('role' term might be not a good term for this mechanism
> at all). Anyway sorry if my words made you think this way.

OK: If you like, then role=presentation and <a role=img> are "special". 

However, my point was that if you do <a role=presentation><img></a>, 
the sighted will perceive the image as both a link and image, while the 
AT user will not even perceive it: The <a> will not be perceived as 
link and the <img> will not be perceived as anything. 

According to Accessibility Probe, in Firefox 11, such a link has role 
of "text", which I suppose is equivalent to "presentation", right? 
However, for some reason, NVDA announces it as a link. Jaws and 
VoiceOver treats it as expected: They don't announce that it is a link. 
I don't know if NVDA's behavior is related to how the Firefox A11Y API 
works. But I note that accState is "focusable, linked" - which is same 
as for <a role=link>. Hence, I suspect that the error is in the Firefox 
A11Y API.

In IE8, the behavior is as expected - and as in VoiceOver and Jaws: <a 
role=presentation> has accState read only.

>> Also, when a link wraps around an image, then sighted
>> users don't see "a normal link" — they see an image. Only when they
>> hover around - or click - the image, do they see the link.
> 
> You need to keep in mind that what AT users see and what UA exposes to
> AT are different things. Originally ARIA implementation guide requires
> UA to remove native semantics in case of <a role=img href> and
> therefore it means UA can't expose actions in this case what means the
> AT user is not able to click this image at all via AT API. That was a
> problem I referred to.

I believe you are wrong: The AT can say "Press enter to activate link 
to long description." That will - and does - work! Even if the <a> is 
announced as "img".  This is also logical! Imagine that the AT user's 
sighted friend sits side-by-side, with a mouse in hand: It would be 
weird if he could not click the image until the AT software was closed!

Take note, also, that 

  <a role=img aria-label="Nice photo of Leif. Press Enter for long
     description." href=link ><img></a>

is presented to the AT user in a way which is *very* analogous to the 
way Jaws presents an <img> that has @longdesc:

  <img ="Nice photo of Leif. Press Enter for long
         description." longdesc="link" >

Jaws then announces "Press (Alt +) Enter for long description." (It 
says "Alt + Enter", but it seems "Enter" is what works - at least in 
Firefox.)

>> Example: Om CNN.com today, each news story is presented like this:
>> 
>> <div><a href="LinkURL"><img src="URL" alt=""></a>
>> <a href="LinkURL">Veteran reporter Wallace remembered</a></div>
>> 
>> Question: Why - in your opinion - do the AT user need to perceive the
>> first link above as a link?

> [ snip ] But there's nothing interesting from mapping to AT 
> point of view in this case.

Seems we agree that AT user don't need to know it is a link.

>> Already today, HTML5 permits us make the
>> link presentational. And so, what is the difference between making it
>> presentational and making it a an image?
> 
> Perhaps it's out of scope of this discussion but you should keep in
> mind that link can't be presentational because it's focusable.

When you say "can't be presentational", then do you actually mean 
"should not be presentational"?

Suspicion: I suspect that you and Aaron Leventhal's viewpoints on this, 
are *directly* linked to what you say in this discussion: 
http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0177


Namely: You think that Firefox's behavior is best. And Firefox' 
behavior is to "mix" the roles: The native role is kept, and the 
WAI-ARIA role is just "added" to the new role. (If I have understood 
you correctly.)

Btw - and related: In the case of <a role=presentation>, then is it not 
so that Firefox *does* present the link as both presentational *and* 
link (as if that was possible)? See what I said about how NVDA handles 
such links, above.
-- 
Leif H Silli

Received on Monday, 9 April 2012 22:06:01 UTC