Re: Summarizing the contentious history of re-opened PFWG-ISSUE-348: Consider renaming (now actually 'deprecating' in ARIA 1.1) role="presentation" to avoid avoid author confusion

James Craig, Sat, 01 Feb 2014 14:32:54 -0800:
> On Feb 1, 2014, at 12:54 PM, Leif Halvard Silli wrote:
>> James Craig, Sat, 01 Feb 2014 10:32:07 -0800:
>>> On Feb 1, 2014, at 4:39 AM, Leif Halvard Silli wrote:
>>>> James Craig, Sat, 01 Feb 2014 01:06:58 -0800:
>>>>> On Jan 31, 2014, at 11:14 AM, Joanmarie Diggs <jdiggs@igalia.com> wrote:

>>> I think you’re misunderstanding how this works on images.
>> 
>> Why do you think so?
> 
> You’re full quote was:
> 
>>>> E.g. for <img>, it flattens the two layers - 
>>>> alternative text and picture - into just one thing - picture. And for 
>>>> headings, it flattens hierarchic text to just (plain) text.
> 
> It seemed to me that you were implying that the presentation role 
> does two different things, when it’s doing the same thing to all 
> nodes.

The difference you have identified is a matter of perspective:

* Your ”same thing” is ”it changes the role to presentation and the 
implications of that".

* My ”two things” is a description of what happens, concretely, for 
elements that have author contents (a.k.a ”attributes”) versus what 
happens for elements that only have text node content. 

The context of our debate is author misunderstandings of 
role="presentation". What perspective is most relevant to the debate? 
What touches authors misunderstandings best? 

FWIW, I too have in the past been baffled by the meaning of 
role="presentation" for img elements versus for other text node 
elements. There were many gotchas when I familiarized myself with ARIA. 
Some of them can be spotted in public-html@, I guess … And so I have 
developed some thoughts about what in ARIA is difficult to grasp etc. 
And I think we may not have the same perspective in that regard.

You seem to think that the misunderstanding regarding 
role="presentation" is mostly linked to the name. Whereas I think it is 
more complex. And from where I stand, I see it as imperative that 
authors understand that - and why - the practical consequences of 
applying role="presentation" to text node elements (like <h1>) versus 
to elements like img, are different. (Because they are! Even if you add 
some modifications below - some of them partly incorrect, I believe, 
see below.)

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

First, let me say that HTML5 emphasize that <img> elements are ”flat”: 
”The requirements above imply that images can be static bitmaps (e.g. 
PNGs, GIFs, JPEGs), single-page vector documents (single-page PDFs, XML 
files with an SVG root element), animated bitmaps (APNGs, animated 
GIFs), animated vector graphics (XML files with an SVG root element 
that use declarative SMIL animation), and so forth. However, these 
definitions preclude SVG files with script, multipage PDF files, 
interactive MNG files, HTML documents, plain text documents, and so 
forth. [PNG] [GIF] [JPEG] [PDF] [XML] [APNG] [SVG] [MNG]”

http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html#the-img-element


Second: you say that for <img role="presentation" src="image.svg">, the 
AT might ”dig into” the text of the SVG image? If that is the case, 
then applying role="presentation" to such an image, could help making 
the image accessible?! Is this described in ARIA somewhere? Why hasn’t 
HTML5 described is a technique? It is at least not described in the 
role="presentation" description in ARIA 1.0 or in ARIA 1.0’s 
description of accessible name calculation. Frankly I thought that, if 
you wanted the SVG to be accessible that way, then you would have to 
embed the <svg> directly in the HTML document rather than linking to it 
via <img src="svg">. May be you are really describing a capability of 
Apple products?

What you say about may SVG make sense. (I can see that it in theory 
does.) But it is not specced yet, AFAICS. And also, such a SVG would 
have to be counted as a child element, then, to fit into ARIA.

Third: Today’s authors’s misunderstandings are hardly due to the 
possibilities of VoiceOVer when it comes to digging into SVG served via 
<img>!

> I’m also not sure what you mean by this:
> 
>>>> it flattens the two layers - alternative text and picture - into 
>>>> just one thing - picture.
> 
> What does it mean to flatten them into a picture? My understanding is 
> that UAs just remove these simple raster images from the 
> accessibility APIs.

(Sidekick: ”… remove … from the accessibility APIs” sounds very much 
like what happens when doing aria-hidden="true". And you wonder why 
authors understand, when you can’t have debate about the *name* of 
role="presentation" without defaulting to teaching about this side 
point, as if it is very important to the matter?)

> Here’s my explanation again about browsers doing the same thing to 
> both types of content.

You are too occupied with what I might hide in my heart. :-D

Again, the context of our debate is *authors* misunderstanding of 
role="presentation". And so: What do sighted authors see when they 
apply role="presentation" to an image? They *see* that the image 
remains. They *know* that presentational images are silent, from A11Y 
users’ point of view. In essence: One ”channel” is left: the visual 
impression.

Authors see. But know that it is hidden to A11Y users. Why - authors 
might think - does the same thing not apply to <h1 role=presentation>? 

And there are more, possible sources for misunderstanding: Perhaps most 
authors don’t know this, but even if the image *does* contain a 
non-empty @alt, the alternative text is silenced.  And so, if we are 
looking for explanation of why authors think that role="presentation" 
is equal to aria-hidden="true", then the fact that role="presentation" 
hides the content of @alt (even if it can be seen by e.g. Lynx 
users!!!) might as well be behind why authors think that <h1 
role="presentation"> will hide the child text of that <h1> element.

Question is: how can we, eventually, get authors to think more 
productively?

   [ snip ]
> I failed to explain that comment fully. I intended to convey that, 
> had HTML been designed differently, the <img> elements could have 
> been something like this:
> 
> <img src="file.ext">alt text in here</img>
> 
> In which case, adding the presentation role would still expose the 
> child text contents to the accessibility APIs.

OK. Agreed.

>> I don’t think it is an artifact 
>> since, if you removed @alt and added @aria-label, then the @aria-label 
>> would be silenced by the role="presentation”.
> 
> It’d be an authoring error to do that since @aria-label is a global 
> attribute. User agents are required to expose it and therefore ignore 
> the presentation role. (Not all do, but those are UA bugs.)
> 
> Quoting from: http://www.w3.org/WAI/PF/aria/complete#presentation

> For any element with an explicit or inherited role of presentation, 
> user agents MUST ignore any non-global, role-specific WAI-ARIA states 
> and properties. However, the user agent MUST always expose global 
> WAI-ARIA states and properties to accessibility APIs, even if an 
> element has an explicit or inherited role of presentation.

And the next sentence, which begins with ”thus” and thus (sic) seems 
like an explanation of the preceding sentence, continues - emphasize is 
mine:

”Thus, the presentation role causes a given element to be treated as 
having no role or to be removed from the accessibility tree, but does 
not cause the content **contained within the element*** to be removed 
from the accessibility tree.“

And thereafter, the spec shows a code listing with examples of what it 
means. And none of those examples contains any global aria attributes 
with alternative text therein!

Are you saying that <span role="presentation" aria-label="foo"></span> 
should be presented to the reader? This does not happen in VoiceOver 
for OSX 10.7 at least! And I tell you: It doesn’t even happen if I set 
the role to heading! (That latter thing I more easily accept as a bug.)

Are you certain that you did not have in mind what happens if *another* 
element refers to that element via aria-labelledby, for instance? 
Because *then* that aria-label is taken account of in the accessible 
name calculation!

Because, otherwise - and with your weight on saying that <img> is not 
special! - one should expect that for the following img element, it 
would be presented as “Bar” to the reader, since, after all, it 
contains a global ARIA attribute aria-label="bar": 

   <img role="presentation" aria-label="Bar." alt="Foo" src="i"/>

Such a behavior would be OK for me. But I am hardly alone in not 
thinking that it is not supposed to work like that.
 
> […]  If I’ve 
> caused you some offense, I assure you it was unintentional. 

I am only frustrated that it takes so long to come to reach to the 
point were understand whether we agree or disagree ...

> Okay. Not trying to imply you don’t know something. Just clarifying 
> based on the discussion above. To me, the word “flatten” implies that 
> everything would be stripped out, like flattening layers in Photoshop.

So are you afraid that they would be too careful, that they would not 
make use of role="presentation" for fair of destroying the user 
experience? 

   Question: If so, is that good or bad?

Neither flatten, presentation, none, null, whatever say how deep they 
flatten. The ARIA spec already explains which child elements 
role="presentation" applies to. Regardless of the term, it will have to 
explain this. My main reason for recommending "flatten" is that it does 
not mean "disappear" or "hide" but, well, flatten. I am also happy that 
it doesn’t mean ”presentation” or ”decoration” etc.

I don’t think we need to emphasize to authors that the - oh so 
unspecial - img element nevertheless disappears from the A11Y API, as 
if they you had used aria-hidden="true" and not role="presentation". I 
mean, that authors get the wrong idea because they know that the img 
element ”disappears” when it is marked up as ”presentational” [be it 
via empty alt="" or role="presentation], is part of the problem here! 
(That is: According to my analysis of the problem.)

>>>> Some other options roughly in the lane, though I prefer "flatten":
>>>> 
>>>> role="transparent"
>>>> role="plain"
>>>> role=“blank"
>>> 
>>> Blank is okay, but I still think none and null are closer to the truth.
>> 
>> We stick to our ideas.
> 
> IIRC, null was actually suggested by Bryan Garaventa, not me.

I am not married to anything.

But I don't understand why null, none, empty has better chances of not 
being misunderstood than flatten. Besides, we should not concentrate on 
"misunderstand" but on "understand". Problem is that authors don’t 
understand what ”presentation” is and what effect it has - what it 
does. When they start to understand, we can start to fix 
misunderstandings. 

I am afraid that "none" or "null" is too closely linked to the role 
concept. Flatten, OTOH, is a term that I think creates understanding 
even if one doesn’t understand the role concept very much.
-- 
leif halvard silli

Received on Sunday, 2 February 2014 01:10:34 UTC