- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 10 Apr 2012 00:05:27 +0200
- To: wai-xtech <wai-xtech@w3.org>, Alexander Surkov <surkov.alexander@gmail.com>
- Cc: Steve Faulkner <faulkner.steve@gmail.com>, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
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