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

Attached is a demo.

Leif

Bryan Garaventa, Sat, 1 Feb 2014 21:05:36 -0800:
> 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 
>