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

Thx. It’s possible, then, that there should be two roles, one for removing
semantics, one for marking images (and maybe other items) as
decorative/atmospheric. The dual purpose is really awkward to explain.



(I’m not sure why a decorative image couldn’t have a description, once
there are semantics to say it is decorative. Use of alt to indicate
decorativeness precluded it before.)


 ------------------------------

*From:* James Craig [mailto:jcraig@apple.com]
*Sent:* Monday, January 27, 2014 5:04 PM
*To:* Suzanne Taylor
*Cc:* w3c-wai-pf@w3.org WAI-PFWG; WAI XTech; Kelly.Ford@microsoft.com;
Richard Schwerdtfeger; Derek Featherstone; Steve Faulkner
*Subject:* 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



Thanks for the feedback Suzanne. Whether or not “none” is the best
replacement is irrelevant. The confusion is not around images. It it around
the use of role="presentation" on other elements. For example:



The following marking:

<h4 role="presentation">Foo</h4>



is effectively the same as:

<div>Foo</div>



But many authors are using it to mean this:

<h4 aria-hidden="true">Foo</h4>



And that’s a major problem I hope we can resolve, regardless of the
solution.





FWIW though, the example you mentioned:

<img src="character.png" alt="A blue monster with 57 green frog eyes and a
fluffy purple tail" role="presentation">



Is an authoring error, as no accessibility information (including a label
such as @alt) should be provided on elements with role="presentation"
according to the specification:



Quoting: http://www.w3.org/WAI/PF/aria/complete#presentation

Authors *SHOULD NOT* provide meaningful alternative text (for example, use
alt="" in HTML4) when the presentation role is applied to an image.





Cheers,

James





On Jan 27, 2014, at 1:51 PM, Suzanne Taylor <suzanne.taylor@pearson.com>
wrote:



 I think accessibility specialists who are looking to speak openly and
honestly about their understanding when an attribute is brand new do not
really represent how the average web developer will look at things.

Role="none" while perhaps clearer to someone who understands accessibility
APIs is less descriptive and less useful. Consider:

<img src="character.png" alt="A blue monster with 57 green frog eyes and a
fluffy purple tail" role="presentation">

Role is presentation. Those who don't want to read this type of
description can have that setting turned off. Those who like these
descriptions can have "read presentation images" turned on.

<img src="rock.png" alt="" role="presentation"> would be silent even with
that setting turned on.

<img src="rock.png" role="none"> is not accurate. It's not nothing. It's
not <span src="rock.png">. It's an image. AT in the future might want to
know that - for transformation to haptic, sonified and/or 3-D
"decorations".

-----Original Message-----
From: James Craig [mailto:jcraig@apple.com <jcraig@apple.com>]
Sent: Monday, January 27, 2014 4:14 PM
To: w3c-wai-pf@w3.org WAI-PFWG; WAI XTech; Kelly.Ford@microsoft.com;
Richard Schwerdtfeger; Derek Featherstone; Steve Faulkner
Subject: 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

To PFWG (and copying the referenced individuals). Also copying XTECH since
the ARIA topics are now moving to Bugzilla and open issue tracking.

In the ARIA F2F meeting last week, we decided to reopen the issue of
renaming the term "presentation" as a role. the name is too long, but more
importantly, it's way too easily confused with aria-hidden.

This topic to "shorten the name 'presentation'" was raised this time by
Rich, although he seemed to have forgotten the contentious history of the
previous debate. Therefore I'd like to summarize the previous discussion
and point out that I think this issue was previously handled poorly by the
PFWG ARIA Task Force. Although I still agree with changing the name (I
suggested role="none"), the work involved will be much, much more
difficult now that ARIA 1.0 is done, because we have to deprecate it
rather than remove it, and this pushes much of the responsibility onto
authors. We should have resolved this formal comment for ARIA 1.0 when it
was originally raised by Kelly Ford.

PFWG-ISSUE-348: Consider renaming (now actually 'deprecating' in ARIA 1.1)
role="presentation" to avoid avoid author confusion
https://www.w3.org/WAI/PF/Group/track/issues/348

This topic was originally raised by a WG member, Microsoft Member
Representative, Kelly Ford.

Quoting Kelly from
https://www.w3.org/WAI/PF/Group/comments/details?comment_id=166

 We believe that role=presentation is problematic, beginning with the

word "presentation", continuing on to possible misinterpretation of what
should be presentation, and possible mis-use of role=presentation by
authors who want to avoid extra effort, thereby hiding real information
from AT who respect that role.
End quote.

Much evidence was presented to support this argument, including the fact
that even accessibility *experts* (including Derek Featherstone and Steve
Faulkner) thought it was interchangeable with aria-hidden, specifically
because of the name "presentation":

Quoting Derek from
https://groups.google.com/forum/#!topic/free-aria/c6aw0zwUAnM

 This attribute should work on any node, though, correct? I was under the

impression that this simply wasn't for images, but for any node that
"should not be exposed" to AT via whatever means.

End quote.

And Steve Faulkner's reply from the same thread:

 thats my understanding.

End quote.

Ultimately the issue was dismissed (via majority consensus, but with
strong objections) because it would require a few user agents to update a
single token value, which is possibly one of the easiest changes in UA
programming, period.

Quoting Rich from
https://lists.w3.org/Archives/Member/w3c-wai-pf/2009JulSep/0089.html

 Well I am [[saying that changing the name is wrong]]. There are tons of

implementations out there using role="presentation". We have a lot better
things to do than change the name of a role. That requires us to go out
and fix browser, web content, and ATs all over the place for a name change
with no significant functional value add. I think we should be spending
our resources on fixing bigger problems like canvas as opposed to things
like that.
End quote.

Quoting myself from the reply:
https://lists.w3.org/Archives/Member/w3c-wai-pf/2009JulSep/0092.html

 I think that's the wrong justification for defending against a change.

Our first responsibility is to get ARIA 1.0 right. It won't matter that it
works when done according to spec if authors are confused enough to do it
the wrong way. This is a recurring confusion from authors and commenters
about what 'presentation' means. The comment by Kelly Ford [1] is well
justified and mentions a problem that we desperately want to avoid, that
".developers are going to get confused from the outset and we'll be stuck
with bad implementations from the outset."


Worse yet, read the free-aria thread referenced in the comment. Even

accessibility experts like Derek Featherstone and Steve Faulkner are/were
confused at the terminology and usage. I have to admit a similar confusion
when I first read that part of the draft.
End quote.

We're now seeing this as a major authoring problem. Many of us have
presentation slides attempting to clarify the difference between
role="presentation" and aria-hidden="true" because it's misused so
frequently. This issue would have been much easier to fix in 1.0. We're
now going to have to recommend authors do something like role="none
presentation" for years to be backwards-compatible with "ARIA 1.0
Compliant" implementations.

Please let this be a lesson to every W3C contributor that existing
implementations (or lack thereof) of any *pre-1.0* specification should
never be cause for blocking improvements to the language.

Thanks,
James Craig