Re: Effect of role=presentation on img elements with svg

Perhaps a simple demo would help?

Take the following code:

<div>
<h2 class="heading" role="presentation">
Header text
</h2>
</div>

<div>
<img role="presentation" src="false/path.jpg" />
</div>

<div>
<ul class="something" role="presentation"><li>
<a href="#"> Test link </a>
</li></ul>
</div>

Regardless whether the element is an image or a container, the following is 
rendered in the accessibility tree:

<div>
Header text
</div>

<div>
</div>

<div>
<a href="#"> Test link </a>
</div>

So basically, the structures containing role="presentation" are being 
nullified as though they never existed, and all attributes within the 
opening and closing < and > signs are also removed.

----- Original Message ----- 
From: "Leif Halvard Silli" <xn--mlform-iua@xn--mlform-iua.no>
To: "James Craig" <jcraig@apple.com>
Cc: "Joanmarie Diggs" <jdiggs@igalia.com>; "Cynthia Shelly" 
<cyns@microsoft.com>; "Bryan Garaventa" <bryan.garaventa@whatsock.com>; "T.V 
Raman" <raman@google.com>; <jongund@illinois.edu>; <jason@jasonjgw.net>; 
<wai-xtech@w3.org>; <w3c-wai-pf@w3.org>
Sent: Saturday, February 01, 2014 8:35 PM
Subject: Effect of role=presentation on img elements with svg


>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

Received on Sunday, 2 February 2014 05:08:05 UTC