Restrict ARIA role="text" to <img> #26

Closed
opened this issue Feb 23, 2016 · 26 comments

Projects
None yet
9 participants

richschwer commented Feb 23, 2016

 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 commented Feb 23, 2016

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

richschwer commented Feb 23, 2016

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

jnurthen commented Feb 23, 2016

 Does someone have an action on the aria spec then? On Feb 23, 2016, at 09:51, Richard Schwerdtfeger notifications@github.com 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 commented Feb 23, 2016

 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".
Author

richschwer commented Feb 23, 2016

 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 commented Feb 23, 2016

 @jnurthen Does someone have an action on the aria spec then? https://www.w3.org/WAI/ARIA/track/actions/2023
Collaborator

stevefaulkner commented Feb 23, 2016

 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 notifications@github.com wrote: 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 commented Feb 23, 2016

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

chaals commented Feb 23, 2016

 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 commented Feb 23, 2016

 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.

 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: 
Still an interactive link because of the author error.

Flattened text because of the explicit role.
Rather than limiting an otherwise useful API, resolve this with UA implementation requirements for anticipated authoring mistakes.
Author

richschwer commented Feb 24, 2016

 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.

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

richschwer commented Feb 29, 2016

 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.
Author

richschwer commented Feb 29, 2016

 btw. I do not like aria-hidden.

jnurthen commented Feb 29, 2016

 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.
Author

richschwer commented Mar 2, 2016

 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 commented Mar 3, 2016

 @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:   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.

 Good example. Let me update it to include non-focusability as a requirement in that case, too. (adding tabindex="-1") 
Flattened text because of the explicit role.
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 commented Mar 4, 2016

 @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.

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

richschwer commented Mar 14, 2016

 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 commented Mar 31, 2016

 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: ***** 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 commented Mar 31, 2016

 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.
Collaborator

stevefaulkner commented Nov 11, 2016

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

dataopt commented Apr 16, 2018

 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.

Closed

Closed

Open