Re: First draft of ARIA 1.1. "text" role

Joan  Marie wrote:
> But to me, the solution to the problem means "don't present 
> 'image'". It does not mean "present 'text'".

I agree with this view of the 2nd set of examples.

I am still baffled by the ARIA 1.0 rationale that makes <img 
role="presentation" alt="My Image" src="MyImage.jpg">, which has a text 
equivalent of "My Image", synonomous with both <img role="presentation" 
alt="" src="MyImage.jpg"> and <img role="presentation" src="MyImage.jpg">.

True the image tag does not technically have "content" but alt is a text 
alternative, which is referred to as "alternitave text content" and 
treated as text content when images are turned off in the browser. 

Had I been around early enough in ARIA 1.0, and had the chops, I may have 
argued to have the first sentence of the definition of role presentation:
"An element whose implicit native role semantics will not be mapped to the 
accessibility API."
consistently applied to image with alt considered to be the text content 
of the image. I think this would be far less confusing. In fact, the 
current spec text doesn't clearly say that this is not the case. 
Especially since the image example in the spec has alt="" in it, a reader 
could reasonably deduce that the image alt text is preserved as text when 
role presentation is applied.

If alt text on images was recognized by ARIA implementations as the text 
content of an image, then there would be no need for a text role to 
support images that are used as text. In this case, <img 
role="presentation" alt="My Image" src="MyImage.jpg"> would be the same as 
the proposed <img role="text" aria-label="My Image" src="MyImage.jpg"> 
which would be the same as <img role="text" alt="My Image" 
src="MyImage.jpg">. 

The potential for these 3 image elements to be rendered differently for 
screen reader users of ARIA 1.1 implementations does not give me the 
feeling that we are moving in the direction of reducing complexity and 
increasing clarity for authors.

Extended characters are another story. The problem is that they really are 
text. So then Joanie's other point is really impoartant:
> When you tell an assistive technology "this object is text," I think
> it's reasonable for that assistive technology to assume that there 
> is text present, that the platform's accessible text interface 
isimplemented, etc. And that's not the case here.

In the case of the text role applied to a span containing text (whether or 
not it contains extended characters), it seems we are giving authors the 
ability to create what are essentially alternative "speech" or in effect 
"non text" equivalents of the text -- a more screen reader friendly 
description of text. In general, empowering or encouraging authors to 
recast text as something other than text specifically for screen readers 
feels slippery and kind of dangerous. I wonder how often it will be put in 
place, intentionally or ignorantly, and then forgotten. Who would think to 
"look behind" text to find alternative text when testing? We label images, 
form elements, widgets, etc., but text?

I wonder if we would ever see something like:
<span role="text" aria-label="I know what blind people want to 
hear...something different">This is what sighted people should read and it 
is what the author is really saying</span>.
The downside risk is magnified when you consider that role text could 
replace all descendants.

If creating screen reader-specific, context dependent  rendering of 
extended unicode text is the primary problem we need to solve, then ARIA 
1.0 has a solution:

<span aria-hidden="true">crazy sightee characters</span><span 
aria-hideden="false" style="display:none">screen reader friendly 
text</span>

Unfortunately, some browsers still do not support the 2nd span so the old 
hack of off-screen positioning is still required.

I would guess the main advantage of the new text role over this approach 
is that you can use a single element instead of 2. Are there others? The 
question I am pondering is whether it is really worth adding such a risky 
and complex role to gain this advantage? And, is the use of the text role 
going to be as transparent to authors as the aria-hidden attribute?

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com

Joanmarie Diggs <jdiggs@igalia.com> wrote on 11/11/2014 04:44:37 AM:

> From: Joanmarie Diggs <jdiggs@igalia.com>
> To: Steve Faulkner <faulkner.steve@gmail.com>, 
> Cc: James Craig <jcraig@apple.com>, W3C WAI Protocols & Formats 
> <public-pfwg@w3.org>
> Date: 11/11/2014 04:45 AM
> Subject: Re: First draft of ARIA 1.1. "text" role
> 
> Hey Steve.
> 
> On 11/11/2014 06:29 AM, Steve Faulkner wrote:
> > 
> > On 11 November 2014 02:38, Joanmarie Diggs <jdiggs@igalia.com
> > <mailto:jdiggs@igalia.com>> wrote:
> > 
> >     confuses me. Unlike the first set of examples, there is no actual
> >     (rendered) text there because the element is an image. So why 
should
> >     this non-textual object be exposed to accessibility APIs as plain 
text?
> > 
> > 
> > Hi JoanMarie,
> > 
> > <img alt="some text">
> > 
> > I think, is one of the main use cases for role=text, what it does is
> > ensure that when a developer (as if often the case unfortunately) uses
> > images of text/symbols/icons to convey meaning, through the use of
> > role=text the textual information is conveyed without the role=img
> > noise. The fact that an image is being used to provide it is an 
artifact
> > of design/technology constraints rather than being important 
information
> > (role=img) that is conveyed. In these cases, the medium is not the 
message.
> 
> Understood. But to me, the solution to the problem means "don't present
> 'image'". It does not mean "present 'text'".
> 
> When you tell an assistive technology "this object is text," I think
> it's reasonable for that assistive technology to assume that there is
> text present, that the platform's accessible text interface is
> implemented, etc. And that's not the case here.
> 
> --joanie
>