>
> Effectively, what you are saying above, is that this:
> <img role="presentation" src="svg">
the subdom of an <svg> img is available:
https://dl.dropboxusercontent.com/u/377471/SVG/adobesimplesvgtest1.html for
an example,
the subdom of <img src=svg> does not appear to be available:
https://dl.dropboxusercontent.com/u/377471/SVG/adobesvgtest4.html
--
Regards
SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
On 2 February 2014 04:35, Leif Halvard Silli <
xn--mlform-iua@xn--mlform-iua.no> wrote:
> I think we need to split the debate in two:
>
> a) Name change to clarify the presentation role for authors?
> b) Effect of role=presentation on img elements with SVG images;
>
> (And may be we should discuss global attributes with textual content in
> a third thread ...)
>
> I don't think that it is 100% necessary to clarify everything related
> to b) in order to solve a). That being said, this thread is about b)
>
> James Craig wrote:
> >> <img> is not a special case, except that, for simple raster
> >> image, its only accessibility information is contained in an
> >> attribute specific to the role. This may not always be the case for
> >> <img>. For example, the sub DOM of SVG images is available through
> >> the rendering engine (and in some ways, through the DOM), so these
> >> would behave more like the heading example you listed above, rather
> >> than how you described the image behavior.
>
> Effectively, what you are saying above, is that this:
> <img role="presentation" src="svg">
>
> should be treated like an iframe:
> <iframe role="presentation" src="svg"></iframe>
>
> VoiceOver+Safari seem to behave a bit like you say, though with various
> bugs. Whereas VOiceOVer+Firefox behave more as HTML5 expects.
>
> The VOiceOver+Safari behavior is in conflict with HTML5, though. And
> IMO, it is also in conflict with the accessible name calculation as
> described by ARIA.
>
> The VOiceOver+Safari behavior makes the effect of role="presentatioN"
> on <img> harder to predict as it means that role="presentation" will
> sometimes not hide the image from the A11Y layer.
>
> On the other side, the HTML WG had an intense debate about whether user
> agents should be encouraged/permitted/whatever to use OCR techniques
> and other kinds of image analysis in order to extract meaning from
> images. And so, it could seem natural that it should be allowed an
> encouraged to extract meaning from text in SVG or PDF images.
>
> In HTML, iframe constitutes a browsing context, while img does not.
> That is the reason, I guess, why Firefox do dig into iframe's content
> (if the <iframe> is given role="img", it only digs into iframe
> document's <title> attribute, though) and also the reason why Firefox
> does not dig into svg inside <img>.
>
> With regard to the accessible name calculation, then it speaks about
> collecting content from "descendant content", "descendant subtree",
> "descendants" and "descendant node". My normal assumption would be that
> this refers to direct children of the element. And not e.g. to a svg
> document referenced by the src attribute of <img>. For <iframe>, this
> is a little different, I guess because iframe is a browsing context.
> --
> leif halvard silli