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

On Feb 1, 2014, at 12:54 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 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:
> 
>>>> If we say that role="div" is a synonym of 
>>>> role="presentation", we’re implying that <div>s should never be 
>>>> exposed to accessibility APIs, which is likely to break a lot of 
>>>> things.
>>>> 
>>>> My top contenders so far are “none”, “null”, and the empty string (“”).
>>> 
>>> I think role="flat", role="flattened" or role="flatten" are better. 
>>> Because, what presentation role does is that it flattens the signals 
>>> from many to just one. E.g. for <img>, it flattens the two layers - 
>>> alternative text and picture - into just one thing - picture.
>> 
>> 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. <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.

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.

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

>> In all 
>> cases, the presentation role removes any implicit role mapping (e.g. 
>> <h2> no longer maps to “heading”) and therefore any attributes 
>> associated with that role (e.g. @alt on img) are also deemed 
>> irrelevant.
> 
> Here you say that it as expected that presentation role silences @alt, 
> whereas below ...
> 
>> The fact that it works this way on HTML images is just an 
>> artifact of the host language that puts the alternative text in an 
>> attribute instead of the child contents. 
> 
> … here you say that is an artifact.

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.


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


>>> And for headings, it flattens hierarchic text to just (plain) text.
>>> 
>>> Flat/Flattened is known from many fields as a name for simplification 
>>> processes were the result is that the basic content is kept while the 
>>> styling and/or structure is lost. Flat/Flattened thus tells authors 
>>> that *not everything* is lost, something which could help them 
>>> understand that the result of flattening an img is different from the 
>>> result of flattening  a heading - and also help them understand how 
>>> flatten differs from hiding. Also, for flat/flattens, chances are that 
>>> authors understand that it is not necessary to apply it to elements 
>>> that are already flat, such as <span> or <img> with empty alt=“".
>> 
>> You may be misunderstanding the presentation role, too. It does not 
>> flatten the contents.
> 
> Sorry, but I tried to keep it short. For <table>, it flattens the 
> elements that the table is made up of. Same goes for lists and other 
> constructs. This is described in the ARIA spec, and I expected that you 
> expected that I knew this.

I’m glad to know you read that part of the spec. I try not to assume anyone has read it, so my re-stating it in the context of this discussion was not at all intended as a slight against you. If I’ve caused you some offense, I assure you it was unintentional. 

> Thus I am aware that a child <strong> 
> element inside <h2 role="presentation"> is not flattened - it retains 
> its semantics.
> 
>> All the *standalone* descendant contents nodes 
>> retain their semantics. For example, this would be exposed as a 
>> heading inside a main landmark.
>> 
>> <main><h2>foo</h2></main>
>> 
>> But this would just be exposed as a heading, because the <main> tag 
>> has had its role nullified.
>> 
>> <main role="presentation"><h2>foo</h2></main>
> 
> Yup, I know.

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.


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

James

Received on Saturday, 1 February 2014 22:33:25 UTC