RE: text role removal

Birkir,

While I don't totally disagree with the "customer service" example, I have often thought it to be a red herring. In practice, when screen reader users experience a communications stumble or complete failure in the context of a customer service call, at least in my experience, it is unlikely the root cause is traceable to something as simple or gramular as calling a link a button or lack of ability to find an image because it is not coded as an image.

That said, your points are nonetheless valid.

I think the stronger case for ensuring screen reader users are aware of the use of imnages in communications is the effect that the lack of such knowledge has on education and social inclusion. People who are Blind need to understand how to interpret and use imagery in order to fully participate in modern communications. Emojies are a perfect example. And, the use cases presented for the text role are very similar to how emojies are used.

Other text role examples, such as a ratings symbol, are just as easily understood as images. It can be useful to know that the rating is represented as an image so hiding that fact can actually be a disservice to the screen reader user. It also puts browser functionality, such as the context menu for the image, out of reach of screen reader users.

It seems to me that the purpose of the text role as "stylizing speech." Giving the author the ability to style speech seems inconsistent with the purpose of ARIA. I can imagine very good reasons to give authors such capability, but we should be careful about how we go about it so that such styling does not create unintentional negative effects.

Matt

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

Not to create another password role type of thread, but some of us screen reader folks had discussions about this role and failed to come up with a convincing use case.
Completely abstracting or hiding the way a page component is implemented for a screen reader creates increased separation between them and other users and is technically a violation of WCAG 4.1.2.
If there are clear and present benefits to doing so, it may be worth it. But in this case an alt text on an image or an icon would do exactly the same thing as the proposed text role, plus letting the user know that there is, in fact, an image there.
If I see a sentence
<p>I <img src="heart.jpg" alt="love"> New York.</p> I get curious and ask people what is in the image.
Thus I learn that heart is a popular imagery for love.
Same with, say, an envelope icon for email.
If the text role is used there I would never know there was an image in the sentence.
this has some practical implications, e.g. when a screen reader user calls customer service.
Informal discussions with some of my fellow screen reader users revealed that we had the same concerns.
-Birkir




On 6/22/16, James Craig <jcraig@apple.com> wrote:
>> On Jun 22, 2016, at 4:44 AM, James Craig <jcraig@apple.com> wrote:
>>
>>> On Jun 20, 2016, at 1:01 PM, Bryan Garaventa 
>>> <bryan.garaventa@ssbbartgroup.com> wrote:
>>>
>>> From what I remember, this was removed due to the inability to 
>>> handle the scenario of author error when role="text" were applied to 
>>> the body tag of a webpage, which would destroy all child contents. 
>>> This came up during one of the UAIG calls.
>>
>> We addressed this point prior to it's inclusion in the spec, and even 
>> included some serious author warnings.
>>
>> The resolution of that discussion was that the benefits of tools used 
>> correctly outweigh the risks of their potential misuse. In other words,
>> the occasional smashed finger doesn't negate the usefulness of a hammer. 
>
>
> After re-reading the discussion on this topic, there wasn't enough in 
> the meeting minutes to warrant its removal.
> http://www.w3.org/2016/03/31-aria-minutes.html#item04
>
> The feature was already approved for 1.1 (in the January 2014 F2F 
> meeting), it was one of the first features added to the spec (along 
> with appropriate warning text), and already had two shipping 
> implementations at the time of its removal.
>
> Given all that, the only thing warranting its removal would be:
>
> 1) An agreement that the feature is not, in fact, useful. (effectively 
> like
> deprecation)
> 2) A formal statement from one of the browsers vendors that the 
> feature is not implementable on a particular platform.
>
> The text role should be uncommented and moved back into the spec.
> (ACTION-2086)
>
> James
>
>


--
Birkir Gunnarsson, CPACC
Senior Accessibility Subject Matter Expert | Deque Systems
2121 Cooperative Way, Suite 210
Herndon, VA, 20171

Ph: (919) 607-27 53
Twitter: @birkir_gun

Received on Thursday, 23 June 2016 19:27:04 UTC