Restrict ARIA role="text" to <img>

[richschwer]

In the ARIA API mappings meetings everyone was concerned about having role="text" be applied to content other than text as people could put a link in the middle of say a span of text which would be a real problem. The group agreed that the role of "text" should be restricted by the host language to only be used on images for now.

Per the conversation Steve F. and I had please restrict the role of text to only being applied to

[jnurthen]

I'm assuming it will also be allowed on div and span (as shown in the examples in the aria spec)

[richschwer]

no. We are going to limit to images because someone can put a link in the middle of the span.

[jnurthen]

Does someone have an action on the aria spec then?

On Feb 23, 2016, at 09:51, Richard Schwerdtfeger [email protected] wrote:

no. We are going to limit to images because someone can put a link in the middle of the span.

―
Reply to this email directly or view it on GitHub.

[jnurthen]

I mean - doesn't this essentially make the text role useless..... The only benefit it has with this new conformance requirement is allow someone to prevent a screen reader from saying the word "graphic".

[richschwer]

no. the text role was for images of text. The only other option would be to do the following which is to make an attribute called aria-text which can only be applied to images. This way you could create a similar restriction in HTML but also do the following:
<span role="img" aria-text="true" aria-label="5 stars">*****</a>

Again, what happens if someone puts a link in there?

You can propose that to the group.

[klown]

@jnurthen

Does someone have an action on the aria spec then?

https://www.w3.org/WAI/ARIA/track/actions/2023

[stevefaulkner]

Thinking about this a little more we could restrict any container elements
with role=text to only non interactive descendants:

Eg

This restriction is already used in HTML for a number of elements. This
would provide some more flexibility, while constraining the children of
role=text to the desired element types.

On Tuesday, 23 February 2016, Joseph Scheuhammer [email protected]
wrote:

@jnurthen https://github.com/jnurthen

Does someone have an action on the aria spec then?

https://www.w3.org/WAI/ARIA/track/actions/2023

—
Reply to this email directly or view it on GitHub
#26 (comment).

Regards

SteveF
Current Standards Work @w3c
http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

[klown]

Thinking about this a little more we could restrict any container elements with role=text to only non interactive descendants

FYI:
https://www.w3.org/WAI/ARIA/track/issues/1011

[chaals]

There is a real issue with making it purely text. ASCII art is still with us:

The following is found in the HTML spec source code:

████████ ████████  ████ ████████ ████ ██    ██  ██████
██       ██     ██  ██     ██     ██  ███   ██ ██    ██
██       ██     ██  ██     ██     ██  ████  ██ ██
██████   ██     ██  ██     ██     ██  ██ ██ ██ ██   ████
██       ██     ██  ██     ██     ██  ██  ████ ██    ██
██       ██     ██  ██     ██     ██  ██   ███ ██    ██
████████ ████████  ████    ██    ████ ██    ██  ██████

(Admittedly much to my distaste).

I think we need something more than a pure img solution if we're going to do this.

In HTML, img is already represented, textually, by the content of the alt attribute.

[chaals]

The link case is analagous to having an image map. We need to define some magic (blergh) that handles the case, probably by decalring that anything interactive inside the label is treated as a map. But I suspect this isn't as hard as it might seem. Especially if we don't want to make ARIA more generally useful.

[cookiecrook]

I object to limiting the authoring use. That's an easy spec solution but it won't work in practice, and will be too limiting of legitimate cases. For the spec, it's sufficient to have the author SHOULD NOT requirements. This will allow validators to throw warnings.

You could even add a requirement that any interactive control inside an element with role="text" will invalidate the containing text role. Authors legitimately wishing to flatten these contained interactive nodes would need to add an explicit role="none"... For example:

<div role="text">Still an <a href="#">interactive link</a> because of the author error.</div>
<div role="text"><a href="#" role="none">Flattened text</a> because of the explicit role.</div>

Rather than limiting an otherwise useful API, resolve this with UA implementation requirements for anticipated authoring mistakes.

[richschwer]

The issue we all had is that even if role="none" is applied the link does not go away. The entire API mapping team felt very uncomfortable with this.

[cookiecrook]

The link doesn't go away if you apply aria-hidden to the entire page either.

[richschwer]

but it makes a mess of things when you are trying to do text api conversion and you have a link that does not belong there.

[richschwer]

btw. I do not like aria-hidden.

[jnurthen]

How is this any different than If someone were to put role=button on something with a link child? The link will go away there too yet button is allowed on a div.

[richschwer]

If someone made a button and put a link in it, it is highly likely that they would have done so to send people to where the button was intended to take you. However, with text we are talking about STATIC text mapping. Placing a link in the middle of that is incredibly confusing. That was not the intent of having a static text section. Everyone on the #aapi call found this to be dangerous.

If we were going to go this route I would much rather us at least try to prohibit access to images - meaning that we put a property on images to say something is static or we subclass an image and make. I want to force developers to think about what they are doing vs. just dumping on any text.

So, this would then be legal (note: this is my opinion and not necessarily the opinion of the rest of the group) <div role="img" aria-text="true" aria-label="5 stars">**</div>. The we limit the host language by saying that it is limited to elements having img as native host language semantics even though this still bothers me: <div role="img" aria-text="true" aria-label="5 stars">__<a href="foo.com"></a></div>. Here we say all children are presentational as you would expect on an image.

[klown]

@jnurthen @richschwer
To make things concrete, here's a button with a link inside it. Note that the link has an explicit role="presentation" attribute:

 <div role="button" tabindex="0" aria-labelledby="buttonlabel">
    <a role="presentation" href="www.ocadu.ca">OCADU </a>
 </div>

In that case, FF exposes the link as a child of the button in the accessibility tree, and ignores the presentation role. Note that is consistent with the ARIA specification for presentation/none, namely that if an element is focusable, the role will be ignored.

[cookiecrook]

Good example. Let me update it to include non-focusability as a requirement in that case, too. (adding tabindex="-1")

<div role="text"><a href="#" tabindex="-1" role="none">Flattened text</a> because of the explicit role.</div>

Bottom line, we should make it a little harder for developers to make easy mistakes. However, we should not prevent them from using the roles as intended though.

Spec text could be ~"UAs MUST ignore the 'text' role if the element contains any interactive (term to be defined) elements, unless those descendant elements have an explicit role=none and are not focusable." The spec should not limit the role to use on images.

[klown]

@cookiecrook wrote:

Good example. Let me update it to include non-focusability as a requirement in that case, too. (adding tabindex="-1")

Nit: that does not make it non-focusable. The link remains focusable, but is no longer TAB-navigable. See the section on negative tabindex in the HTML5 spec.

Nonetheless, I agree with your suggested spec text change. I've added a note about it to ISSUE-1011.

[cookiecrook]

We’ll call it “not user focusable” then.

[richschwer]

We will be taking the text role up again in a working group call. Right now the api mapping people need a lot more convincing.

[mcking65]

Whether an author uses pictures of text or svg drawings of text or extended unicode characters, all the blind people I have spoken with do not want to lose the information that images or graphics are used. It is especially important in situations like I heart New York as described in the proposed spec text. Blind people want and sometimes need to know when information is communicated via pictures or graphics.

Similarly, if it is an actual image, we do not want to lose copy/paste functionality or context menu actions provided by the browser for that element, all of which would disappear for screen reader users if the text role were used.

Instead of adding a text role, I recommend we pursue making constructs like the following work well with screen readers:

<span role="img" aria-label="5 stars">*****</span>

Let's please not give authors more ways to accidentally take away important information. Let's also please work to keep the control of presentation in the hands of screen reader users and screen reader developers. If screen readers want to provide functions to stream-line presentation of emogies or images embedded inside sentences, they can already do that.

[Wildebrew]

I second Matt's opinion.
WCAG 4.1.2 talks about name, role, value. If we use role="text" on an image, we have effectively hidden its role from blind users.
If I, as a blind user, am having a call with a customer service agent, or a talk with a sighted colleague, they are not going to understand me when I refer to the content of the element with role="text" or the sentence "I love New York", to quote the example. If I don't even know that the word "love" replaces an image of a heart on the page I can never begin to guess where the text comes from.
This role will create a separate webpage experience for a blind user, and that is a dangerous path we have fought to get away from in the past.
Use role="img" and appropriate aalternative text mechanism.
It serves the same purpose, works fairly well with a.t. already, and communicates the role of the element along with its alternative text.

The inconvenience of hearing the word "image" announced with the text is small compared to the problems that can arise from not knowing about the presence of an image.

The screen reader can give the user a choice of stripping the word "image" from any element with role="img" which would result in the same experience as if role="text" was implemented, only you give the power to the user, not to the author.
I have spoken with a couple of screen reader users recently who share my concern about this role.
We fail to see (pardon the pun) what good it would do for us.

[stevefaulkner]

closing this for now as role=text did not make it into aria 1.1

[dataopt]

If screen readers do allow users to strip the word "image" from role="img", that will be great. Which screen readers offer this option?

Such an option will be very valuable in cases where many simple math symbols appear in a single sentence. For example, one can have something like what is in the image below (alt text gives the actual source to be rendered by MathJax):

Sighted people would simply read this as, "Let aleph sub 1 and aleph sub 2 denote the cardinality of the set of real numbers and the cardinality of the power set of the set of real numbers, respectively." As far as I can tell, if each math symbol has role="img", a screen reader will probably insert the word "image" four times into the sentence.

[brennanyoung]

As far as I can tell, if each math symbol has role="img", a screen reader will probably insert the word "image" four times into the sentence.

You can hack around this by using aria-roledescription=" " but who feels comfortable with that 'solution'?... I believe we still need a proper mechanism for announcing glyphs, emojis and the like (which are already text, not images) in a predictable (and translatable) fashion.

For example, I just discovered that unicode glyphs are usually announced in Browser UI language, rather than respecting whatever HTML lang has been specified.

[brennanyoung]

closing this for now as role=text did not make it into aria 1.1

The use case remains. Could we reopen this issue please for aria next?

[jnurthen]

This isn't the correct place for this discussion.
Please add specific use cases to w3c/aria#870 to facilitate discussion.