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 Wednesday, 22 June 2016 14:29:53 UTC