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

Hi Alexander,

Alexander Surkov, Tue, 10 Apr 2012 19:01:02 +0900:
> 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"
  [ snip ]
> 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 we read it the same way. But what does "expose semantics" mean? 
Is it necessarily synonymous with "include in the accessibility tree"? 

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

Benjamin probably meant "MUST NOT use role=img" since, by explicitly 
listing the permitted WAI-ARIA roles for <a>, HTML5 does forbid <a 
role=img>: <http://www.w3.org/TR/html5/wai-aria.html#wai-aria>. But of 
course, HTML5's author requirements do not overrule the 'WAI-ARIA 1.0 
User Agent Implementation Guide'. 

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

I take your point. But my reason to discussing it, was related to 
HTML5's forbiddance of <a role=img>: I try to see whether the roles 
that HTMl5 allows, are enough. Also: we are discussing the same 
element, <a>, with two roles that - partly - have the same effect. 
Finally: You rule it out as special case, while I focus on 
role=presentation as a a "normal" role and thus, its effects are 
comparable to role=img. To a degree, both perspectives have their 
place. 

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

OK. WAI-ARIA 1.0 also says:

"If an element with a role of presentation is focusable, user agents 
MUST ignore the normal effect of the role and expose the element with 
implicit native semantics, in order to ensure that the element is both 
understandable and operable."

I am not sure what that means. E.g. if, while VoiceOver presents the 
following element, 
   <a href=link role=presentation>Long text.</a>
the user presses the shortcut to activate the link, and the link gets 
activated, then I suppose that the user agent has ignored the "the 
normal effect" of the presentation role and instead allowed the element 
to be "operable" - but perhaps not "understandable" (since VoiceOver 
doesn't announce the link-i-ness).

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

Agreed.
-- 
Leif H Silli

Received on Tuesday, 10 April 2012 16:44:13 UTC