- 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