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

I don't see a principled difference between these examples. They both are
supposed to replace _something_ (either text or image) by the text. I hope
it doesn't mean it should be exposed as native text since it's huge
implementation problem both for the browser and some AT (like Orca) and one
more step to the world where AT users has own virtual version of the web.
So if it's not supposed to be like native text then the AT has to add a
special support for role="text", for example, no extra pauses when reading
the text. That sort of ruins out beauty of the idea of role="text" in my
understanding since it's not a text on the implementation end but still
works.
Thanks.
Alex.

On Mon, Nov 10, 2014 at 9:38 PM, Joanmarie Diggs <jdiggs@igalia.com> wrote:

> Hey James.
>
> On 11/10/2014 02:40 PM, James Craig wrote:
> > First draft of ARIA 1.1. "text" role
> > http://rawgit.com/w3c/aria/master/aria/aria.html#text
>
> The first set of examples:
>
>   <p>I <span role="text img" aria-label="love">♥︎</span> New York.</p>
>   <p>My <span role="text img" aria-label="heart">♥︎</span> bleeds.</p>
>   <span role="text" aria-label="3 of 5 stars">★★★☆☆︎</span>
>
> makes a lot of sense to me: You want to provide a better spoken
> representation than you'd get from sending those non-alphanumeric text
> characters to whatever speech synthesizer is being used, so you need to
> prevent the inline text from being folded/flattened into the parent. And
> there's actual (rendered) text there, so role="text" seems like the
> obvious solution both from the authoring standpoint (text is text) and
> from the accessibility API mapping standpoint (text roles should
> implement the accessible text interface in order to provide access to
> the text at a given character offset, text selection, text attributes,
> etc.)
>
> However the second set of examples:
>
>   <p>I <img src="icon.gif" alt="love" role="text" aria-label="love"> New
> York.︎</p>
>   <p>My <img src="icon.gif" alt="heart" role="text" aria-label="heart">
> bleeds.︎</p>
>
> 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?
>
> Beyond the above, you have an image with alt text that ensures the
> spoken representation is what the content author wants it to be. So far
> so good. But if the author declares the non-textual image element to be
> role text, the alt property which had ensured the spoken representation
> desired by the author no longer applies? And because it no longer
> applies, the author must then use aria-label to get that desired spoken
> representation back? All for the purpose of telling ATs that this object
> which has no rendered text is a plain text object?
>
> --joanie
>
>