- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Wed, 11 Apr 2012 00:55:26 +0100
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: Alexander Surkov <surkov.alexander@gmail.com>, wai-xtech <wai-xtech@w3.org>, Steve Faulkner <faulkner.steve@gmail.com>
On Wed, Apr 11, 2012 at 12:01 AM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > Benjamin Hawkes-Lewis, Tue, 10 Apr 2012 22:03:53 +0100: > >>> my conclusion, is that, per the ARIA spec, then a >>> <a role=img href=* > is distinctly different from >>> <a role=presentation href=* >. >> >> Per the HTML5 and ARIA specs, yes. >> >>> Which strengthens me in the view that HTML5 ought to >>> permit <a role=img href=* >. >> >> I don't see how that follows from the difference. > > It follows from the fact that <a role=presentation> cannot do what <a > role=img> can do, and from the fact that I want done what <a role=img> > can do. OK. 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> You say it "suppresses the 'normal' link announcement" (implicitly by screen readers), but I don't get how that helps end-users. >> 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. > 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. As currently specified, the <img> element would imply an "img" role and the <area> elements would each individually imply the "link" role. > 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. >>> 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/ -- Benjamin Hawkes-Lewis
Received on Tuesday, 10 April 2012 23:56:15 UTC