- 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>
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 criteria. 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 element. >> 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