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

+1 to what Matt said.
This has more down side than up side. Authors will be confused by declaring
text as text with a text alternative and/or aria-label. Accessibility does
not benefit from being this complex.

                                                                     
                                                                     
                       Regards,                         Fred         
                                                                     
                       Fred Esch                                     
           Accessibility, Watson Innovations                         
    AARB Complex Visualization Working Group Chair                   
                   IBM Watson Group                                  
                                                                     
                                                                     






From:	Matthew King/Fishkill/IBM@IBMUS
To:	Joanmarie Diggs <jdiggs@igalia.com>
Cc:	Steve Faulkner <faulkner.steve@gmail.com>, James Craig
            <jcraig@apple.com>, W3C WAI Protocols & Formats
            <public-pfwg@w3.org>
Date:	11/11/2014 03:29 PM
Subject:	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
>