- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 11 Apr 2012 04:24:31 +0200
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Alexander Surkov <surkov.alexander@gmail.com>, wai-xtech <wai-xtech@w3.org>, Steve Faulkner <faulkner.steve@gmail.com>
Benjamin Hawkes-Lewis, Wed, 11 Apr 2012 00:55:26 +0100: > 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> In the first example, you include @longdesc. You support @longdesc, so, why do you ask why? Don't @longdesc have advantages? > You say it "suppresses the 'normal' link announcement" (implicitly by > screen readers), but I don't get how that helps end-users. The goal is to create the "longdesc experience" via the the anchor element. Do you see @longdesc as something to use when one cannot use an anchor? To me, the advantage of @longdesc is that that instead of taking the focus away from the image - like a normal link often does, it instead focus in on the image. So I don't see the longdesc concept as only something you do when you can't/shouldn't/isn't allowed/whatever to use an anchor element. I don't take lightly on the "longdesc imitation": I use aria-label etc to tell non-Jaws etc that there is long description available. >>> 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. OK. aria-describedAT would not not have any effect on e.g. <span aria-describedat=*>. I suppose no one would "see" it. But if you did <span role=img aria-describedat=*>, then one would see it. >> 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. Ah, there you have it. Yes, I see that my question was unclear. > As currently specified, the <img> element would imply an "img" role > and the <area> elements would each individually imply the "link" role. I agree about <area>. Not so sure about <img usemap=#name>. You can't wrap a link around it - it is forbidden, because it is interactive. And, also, it is supposed to react to CSS such as *:link{border:1px solid blue} So, by all means, it is interactive. And my hunch is that, because it is interactive, the role=img is not the most logical role. Or, at least: What is then the difference between <a role=img> and <img usemap=#l>? >> 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. That doesn't sound like a principal issue, to me. They say that ARIA is like CSS. And so, as author, I would like to use it as freely as possible. >>>> 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/ Right. I think so too. But Firefox does present <a role=presentation href> as a link, and so I think that in this case, it is Jaws. You know, Jaws tries to be cross browser - and that always impacts things, I guess. E.g., if I got it right, then IE presents <a role=presentation href> as *not* a link. -- lhsilli
Received on Wednesday, 11 April 2012 02:25:05 UTC