- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 11 Apr 2012 01:01:47 +0200
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Alexander Surkov <surkov.alexander@gmail.com>, wai-xtech <wai-xtech@w3.org>, Steve Faulkner <faulkner.steve@gmail.com>
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. >> Agreed? > > 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? And what is the correct role for <img usemap> (which is considered interactive per HTMl5) ? And what is the problem with <a role=img href>? What's the principal issue? >> 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. -- Leif H Silli
Received on Tuesday, 10 April 2012 23:02:20 UTC