RE: text role removal

James,

 

The existing implementations are very valuable. One of the best ways to evaluate a proposed feature is by having a working prototype.

 

James Craig wrote:

>A few of the other uses you may not have considered:

>Ratings are done this way so that 

>the text "★★★☆☆" can be spoken as "3 of 5 stars" rather than the unicode literals

>The markup is something like 

><span role="text" aria-label="3 of 5 stars">★★★☆☆</span>

 

We considered this use case. Equal or better accessibility is achieved with:

<span role="img" aria-label="Rated 3 stars out of 5">★★★☆☆</span>

 

>People are occasionally using this to purposefully 

>flatten a few semantic elements that would otherwise be redundant for screen readers 

>(e.g. the implementation required redundant links for styling or functionality, 

>only one of which is relevant for AT.) 

>This is like an ad-hoc was to trigger "children presentational"-like functionality. 

>Something like 

><a href="#"><span role="text">multiple objects and click handlers in here, treated as one "children presentational" link</span></a>

 

We considered this use case as well. This is just a “coding convenience.” There are multiple ways of achieving that same end, including using role=”presentation” if the contained elements have implied semantics. 

 

The text role was described as providing value to screen reader users. But, as far as I can remember, all the screen reader users in the group had a clear preference for either removing the text role or severely limiting its applicability. Again, this is because representing graphics as text is not an improvement to accessibility. It is the author stylizing speech. And, all other use cases that we considered had alternative approaches that provided equal or better accessibility.

 

Net: significant downside with unclear benefit mixed with disagreement over mapping requirements led to a decision to punt to 2.0.

 

Hth,

Matt

 

From: James Craig [mailto:jcraig@apple.com] 
Sent: Friday, June 24, 2016 4:55 AM
To: Matt King <a11ythinker@gmail.com>
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Birkir Gunnarsson <birkir.gunnarsson@deque.com>; Accessible Rich Internet Applications Working Group <public-aria@w3.org>; Steve Faulkner <faulkner.steve@gmail.com>
Subject: Re: text role removal

 

 

On Jun 23, 2016, at 1:54 PM, Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> > wrote:

 

As I recall, the fundamental objections were related to both the utility and
the risks of the role. In all the use cases that were presented, all the
screen reader users in the working group were in agreement that the text
role did not provide better accessibility than the image role. In every use
case we examined, either the text role was hiding something that was useful
or the image role was as good or even better fit.

 

Since the text role has been implemented in a few browsers for a couple years, people are already using this on a number of sites, including some big ones like the iTunes Media Stores. 

 

A few of the other uses you may not have considered:

 

* Ratings are done this way so that the text "★★★☆☆" can be spoken as "3 of 5 stars" rather than the unicode literals "black star, black star, black star, white star, white star"... The markup is something like <span role="text" aria-label="3 of 5 stars">★★★☆☆</span>

* People are occasionally using this to purposefully flatten a few semantic elements that would otherwise be redundant for screen readers (e.g. the implementation required redundant links for styling or functionality, only one of which is relevant for AT.) This is like an ad-hoc was to trigger "children presentational"-like functionality. Something like <a href="#"><span role="text">multiple objects and click handlers in here, treated as one "children presentational" link</span></a>

 

You can test these examples in any recent version of Safari or Chrome. Both have shipped the text role since 2014.





There were also questions surrounding what should happen with selection for
copy and paste and how AT could access appropriate context actions.

 

Those related-but-separate issues were discussed in the 2014 Face-to-Face and were determined to be puntable to ARIA 2.0.