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

Thus, the demo is available here: 
http://lists.w3.org/Archives/Public/wai-xtech/2014Feb/att-0018/svg-image-tests.html


Leif

Leif Halvard Silli, Sun, 2 Feb 2014 16:00:23 +0100:
> 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

Received on Sunday, 2 February 2014 15:02:24 UTC