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

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

From: James Craig <jcraig@apple.com>
Date: Mon, 03 Feb 2014 15:29:24 -0800
Cc: 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: <F04A271D-ECA2-47AA-9FF1-230E0B38A9D5@apple.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Switching to public-pfwg at Rich’s request. Moving XTECH to BCC.

On Feb 3, 2014, at 3:07 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 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.

> 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">


Received on Monday, 3 February 2014 23:30:23 UTC

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