W3C home > Mailing lists > Public > public-pfwg@w3.org > February 2014

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 4 Feb 2014 02:18:23 +0100
To: James Craig <jcraig@apple.com>, public-pfwg@w3.org
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Bryan Garaventa <bryan.garaventa@whatsock.com>, Steve Faulkner <faulkner.steve@gmail.com>, Joanmarie Diggs <jdiggs@igalia.com>, Cynthia Shelly <cyns@microsoft.com>, "T.V Raman" <raman@google.com>, "Gunderson, Jon R" <jongund@illinois.edu>, Jason White <jason@jasonjgw.net>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
Message-ID: <20140204021823576018.f53df6af@xn--mlform-iua.no>
James Craig, Mon, 03 Feb 2014 15:29:24 -0800:
> Switching to public-pfwg at Rich’s request. Moving XTECH to BCC.
> On Feb 3, 2014, at 3:07 PM, Leif Halvard Silli  wrote:
>> Bryan Garaventa, Sun, 2 Feb 2014 13:30:57 -0800:
>>> Still, as far as I'm aware, the purpose of presentation within the 
>>> spec is to nullify a particular element within the accessibility 
>>> tree, and to leave all child nodes alone if present.
>> The challenge is that the @src attribute doesn’t represent ”child 
>> nodes”.
> It does for <iframe>. It only hasn’t for <img> because most images 
> are flattened raster data.

Why don’t you count @src as ”implicit native role semantic”?

Presentation role flattens ”implicit native role semantics”. But how do 
we decide what an element’s ”implicit native role semantics” are? The 
@alt attribute is not unique to <img>, so uniqueness is not the 

Or consider the this script element. If @src is not part of script’s 
implicit native semantics, should I then fear that applying 
role="presentation" would cause AT to start reading the file referenced 
by the script element?

   <script aria-hidden="false" style="display:block"
           role=presentation src=file></script>

It is *one* issue that AT digs into the SVG of a <img> when the <img> 
*has* img role - by default or explicitly. That makes very much sense. 
Even if I consider it to be not reflected, yet, in HTML5.

However, per my thinking, the @src attribute, belongs to the img 
element’s ”implicit native role semantics” and hence should be 
flattened when the element has role="presentation". To bring in, that 
”what if <img/> had looked like <img>text</img>, is not relevant.

Currently, these elements has the @src attribute: audio; embed; iframe; 
img; input; script; source; track; video. ANd I would say that setting 
the role of any of these elements to presentation, should flatten the 
src attribute. The one element that clutters this up, is the iframe 

>> And further, one could argue that @src, just as @alt, is a 
>> specific img element feature, and that @srec therefore should be 
>> nullified, when img has presentation role. In my view, this makes 
>> sense, because the graphic is supposed be presentational for *all* 
>> users.
> I think the core of this debate is still that the name “presentation” 
> has historically meant, that the entire sub-tree is devoid of 
> semantic meaning, but that’s not what role="presentation" means, 
> which is why we’re talking about choosing a new name. There is too 
> much historical baggage that comes with that term. 
> Even here, you’re using <img src="file.svg" role="presentation">  
> when you’d get what you want if you just used: either <img 
> src="file.svg" alt=""> or <img src="file.svg" aria-hidden="true">

Are you saying that alt="" and aria-hidden="true" are synonyms? 
According to ”the baggage” it is alt="" and role="presentation" that 
are synonyms … ?!
leif halvard silli
Received on Tuesday, 4 February 2014 01:18:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:00 UTC