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

Hi, Leif.

Let me cite spec again:
"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"

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

I think Benjamin gave reasonable interpretation of the spec for <a
role=img href> case:

"I think the most natural interpretation of the cited text is that it
does require that user agents to exclude native semantics from the
accessibility tree in this case, since no attributes required by role
"img" are forbidden on <a>. The "jump" action is part of the semantics
of <a>."

That's why I said that the spec denies UA to expose semantics of <a>
element in this case.

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

Maybe it doesn't really matter who forbids something in the end but
Benjamin said:
"HTML5 says authors should not use role="img" on <a href> elements.
This conformance requirement affects authors only."

That means HTML5 doesn't forbid anything. Anyway.

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

It seems that role="presentation" discussion is really out of scope of
the topic. So if you think we have an issue here then I'd prefer to
have another thread for that. Anyway I should notice that Firefox
doesn't break the ARIA spec: "For any element with a role of
presentation and which is not focusable, the user agent MUST NOT
expose the implicit native semantics of the element (the role and its
states and properties) to accessibility APIs." Other behaviors like
you observe in IE it seems to be valid as well.

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

Well, I think this behavior is reasonable on case by case basis. But
that discussion was about landmarks, you shouldn't apply those words
to things like role=img.

Thanks.
Alex.


On Tue, Apr 10, 2012 at 7:05 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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 Tuesday, 10 April 2012 10:01:38 UTC