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 04:36:13 UTC