Consider early re-add of role=text

[kensgists]

It looks like there was prior agreement to move role="text" to ARIA 2.0.

I cannot find the rationale for that removal, but there is at least one implementation in the wild (Safari iOS) which has the effect of flattening out sub-elements within a container, so that VoiceOver will not treat sub-elements as swipe-stops during navigation.

That is, if you do this:
<span role=text>Some text<span> and some more text</span></span>

then VoiceOver will read it in one swipe, without hitching on the second span. That is, it will read:

"Some text and some more text" in stead of

"Some text" [pause for another swipe] "some more text"

It is helpful to have this ability to intentionally override odd reading by the screen reader (bracketing whether or not the screen reader should be doing hitched this reading of simple, non-semantic sub-elements).

[jnurthen]

While I am certainly not against role=text/static I'm not sure this is a good use case. I think the proposed aria-textseparation property ( see #699 ) could potentially solve this type of issue.

[kensgists]

Thanks for the response. I'll follow that ticket. Looks like a good proposal.

[brennanyoung]

The use case which I believe is not handled well using role=img is when text includes glyphs, wingdings, dingbats, domain-specific abbreviations and other symbols, and where the content needs to be internationalized (translated) and/or where there are strict editorial controls on how those sequences are to be expressed in a given spoken language.

For example, a quiz might use the symbols ✓ and ❌ to express correct and incorrect answers as part of some text. It's not currently possible to rely on browsers, screen readers and speech synthesizers making the right announcement. ✓ might be announced as "check", "check mark" or "tick" on an English configuration depending on various things. Browser language seems to override html lang attribute settings, so it's almost impossible to predict what will get announced. Additionally, I want ✓ announced as "correct" rather than "check mark".

Some a11y folks regard this as a non-issue, which is (I suppose) why we don't have this feature. I've been advised to just let the AT announce glyphs in whatever arbitrary way they do it, because users don't really care. Maybe that's acceptable, from certain points of view, but my editorial colleagues have a very different opinion about text content. Rigorous copy enforcement is a big deal at my firm, and I assume we are not unique.

So, we need a way to replace the arbitrary announcement of character sequences with an aria label which editorial/translation processes will find predictable.

The only way to do this today is to use a role which will expose an aria-label. The most obvious choice is role=img, but this has the disadvantage of announcing itself as an image (unnecessary chatter), and cluttering up any AT's special 'image viewer' UI with content which would be written rather than drawn, if it was pen and paper.

Some of the discussions about role=text have touched on this use case, but seem to have been lost in the debate about whether links should be permitted inside content with role=text, which is a separate problem entirely, with various solutions on offer, including some which follow precedents from other established element types.

From my point of view, the specification I am looking for pertains only to inline text elements, most obviously <span> but perhaps also <i> (idiomatic text) and maybe a few others. It must be available in 'browse mode' (i.e. the mechanism should not rely on tab focus or 'operability'), and should seamlessly replace the displayed text with an author-chosen alternative for assistive tech announcement, without the chatter of an explicit role announcement like "Image" or "Graphic". The most obvious form might appear in code something like:

<li>Question 1. Your answer: Nasal cannula. <span role="text" aria-label="correct">✓</span></li>
<li>Question 2. Your answer: Morphine. <span role="text" aria-label="incorrect">❌</span></li>

Such a mechanism could also be employed for fixing the otherwise arbitrary pronunciation of non-glyph text abbreviations such as "IV", which in our products we absolutely need announced correctly as the letters "I-V", rather than "Four" or "Roman Four", which is what happens today. And we want "IV" on the screen. I should point out that marking a character sequence up as an abbreviation does not solve this problem case - we don't need it announced as "intravenous", we just want to use the medical-domain-specific idiom - the one that matches the textbook and other training materials - rather than have it treated as a roman numeral, or an expanded abbreviation.

Some other domain-specific sequences from our products which ATs tend to pronounce 'wrongly':
AED (mispronounced as "aired")
mmHg (mispronounced as em-em-aitch-gee, should be "Millimeters of Mercury")
C/O (mispronounced as "c-slash-oh" or sometimes "care of", should be "complaint of")

More can be provided if necessary.

[carmacleod]

Good arguments.

(Regarding the "swipe stops" issue, this happens on desktop also, when using "next/previous line" reading keys. Just fyi).

Here are a few other use cases, collected from various past issues (some examples slightly edited).

Classic example of specifying preferred text for a symbol

<p>I <span role="text" aria-label="love">❤️</span> New York</p>

International Phonetic Alphabet: #756 (comment)

<p>[<span role="text" aria-label="banana">bəˈnɑːnə</span>] est la prononciation du mot "banane" en anglais.</p>

ASCII art #756 (comment)

<div role="text" aria-label="an ASCII-art kitten"><pre>
               |\___/|
               ) e e (
              =\  Y  /=
                )===(
</pre></div>

Screen reader only text (without CSS offscreen element) #756 (comment)

<span role="text" aria-label="Hello, I'm some text for screen reader users."></span>

Clarifying visually clear content #815 (comment)

<div role="text" aria-label="Price: $4.99">
	<span>Price: </span>
	<span>$4</span>
	<span style="vertical-align: super; font-size: 70%;">99</span>
</div>

Clarifying visually clear "bot blocking" obfuscation #756 (comment)

<div>webmaster<span role="text" class="at-image hide-text" aria-label="@">goawayrandommailcrawler</span>example<span role="text" class="dot-image hide-text" aria-label=".">34534gfd</span>com</div>

---

Here are a few more background/discussion links: #525 (comment)

If we were to define this role, we would need to specify that an element with role="text" MUST NOT have any interactive descendants (like buttons, links, etc) and it SHOULD NOT have any semantic descendants (like lists, etc). We would also need to explain what happens when content is flattened to a string, and we would need to provide buckets of examples... and maybe even some counter-examples.

The main argument against role="text" was that flattening can wipe out content that screen reader users might have wanted to know about.

To understand this problem, let's look at the classic example:

<p>I <span role="text" aria-label="love">❤️</span> New York</p>

A screen reader would read this as "I love New York". There is nothing to indicate that what you hear is actually missing the cuteness of the heart icon... so the screen reader user is left out of the meme. The only way around this that I can think of is to convince AT to play an earcon (a short symbolic sound) whenever an element with role="text" is encountered, and allow users to drill down for details if they want to.

Of course, not all role="text" use cases would have interesting content to drill down to. Just looking at the examples in this issue:

• would a student care that they are hearing "correct" or "incorrect" instead of "checkmark" or "cross mark"? Not likely, I think. They just want to know if their answer was right or wrong.
• the screen readers I tested didn't support the symbols of the Phonetic Alphabet, so drilling down to read them doesn't really make any sense.
• someone might actually want to know which characters were used in the ASCII art (with the screen reader set to say all punctuation in order to get the full effect)
• sr-only text does not need to be drilled into because there should be nothing there... although I'm not sure whether we would allow or prohibit something like:

<span role="text" aria-label="Hello, I'm some text for screen reader users.">I'm some text for sighted users.</span>

• for the price with $4 and a raised 99 cents, I can't imagine anyone caring how that content was structured. Similarly, the details of the obfuscation to block bots are not interesting to users.

So, in many cases, role="text" nicely equalizes the experience for screen reader users.
If I had to characterize the use cases that might matter, I would say that anything "visually playful" - a joke, or meme, or even a serious visual representation of something - should use role="img" instead of role="text. Maybe. But that is just based on the few examples here. I'd love to have others weigh in.

---

To test the above use cases: https://carmacleod.github.io/playground/role-text-tests.html

Interestingly, both Windows Chrome and Mac Safari already support role="text".
I ran the above role-text-tests in Windows Chrome with JAWS/NVDA and Mac Safari with VO, and they all work well.
Windows Firefox doesn't support role="text" (yet?), so the examples do not work there.
Did not try CrEdge (may need to disable UIA first - not sure).

[brennanyoung]

Thanks @carmacleod.

I can fully get behind the constraints that the mooted role should not permit explicit semantics in any descendents (it's straightforward to automate checking for this), and that visually playful 'character art' (ascii graphics, rebus puzzles etc.) should continue to use role=img. Both seem entirely reasonable, so I wonder what any counter arguments may be.

I also agree that a rich set of examples and counter examples can clarify quite adequately how this role should (and should not) be used.

I am not stuck on calling this role 'text', except that I appreciate the brevity. A more linguistically appropriate name might be role='pragmatic', but I'll let others fight over the exact nomenclature.

[JAWS-test]

All role=text examples at https://carmacleod.github.io/playground/role-text-tests.html work fine with TalkBack + Chrome (at Android Smartphone)

[carmacleod]

Thanks, @JAWS-test! Good to know.

[brennanyoung]

role=text works fine with (Chromium) Edge and Narrator

[brennanyoung]

FWIW I have made a feature request for supporting role=text for parity with all the other major browsers on bugzilla. I was surprised to see that no such issue had yet been posted.

[carmacleod]

@brennanyoung

feature request for supporting role=text for parity with all the other major browsers on bugzilla

Can you paste the links into this issue? Would be interesting to see if there's any action. :)

I was surprised to see that no such issue had yet been posted.

Probably because it was taken out of the spec. :)
There may be "closed" issues. Regardless, it's really interesting that many browsers still support it.

[jcsteh]

There are significant problems with role="text" and the use cases discussed here.

1. Most of these use cases are strongly biased towards speech, and specifically, reading by line or larger text units. Many of them don't make any sense at all for braille users, for example, nor do they make sense if a user is reading by character or perhaps even word.
2. role="text" conflates (speech-biased) presentation with content/semantics. Instead of providing information about "what something is" so it can be rendered appropriately, it just overrides the content completely. IMO, this is contrary to the principles of ARIA. We don't recommend <span aria-label="Go button"></span>. Instead, we recommend role="button".
3. As currently implemented, role="text" flattens and exposes the text as if it were just normal content in a document. An AT may not even be able to ascertain that role="text" was used, which is important as per (2).
4. Furthermore, this causes problems in cases where the browser is asked for text unit information; e.g. characters, words, lines. Consider an editable document where someone did <span role="text" aria-label="I V">IV</span>. The caret is on the "I" and the user presses right arrow. Because the text is exposed like any other text and is exposed as "I V", pressing right arrow will report the space, not the V. And this is just the simplest possible broken scenario I could think of; it gets much, much worse.

I'll respond to some specific comments and examples below:

I've been advised to just let the AT announce glyphs in whatever arbitrary way they do it, because users don't really care. Maybe that's acceptable, from certain points of view, but my editorial colleagues have a very different opinion about text content. Rigorous copy enforcement is a big deal at my firm, and I assume we are not unique.

This assumes that a screen reader is purely about narrating the content just like a human narrator would, but that isn't correct. If this were true, a screen reader wouldn't say "link" or "image", but it does because it's providing additional meta information and context to the user that isn't communicated through text alone.

A screen reader must also allow the user to perceive how content was written. Screen reader users don't get to just live in a world of voice. They have to write content like everyone else. Thus, a screen reader user must be able to learn how that content is written so they can follow similar patterns. See below for an example.

The only way to do this today is to use a role which will expose an aria-label. The most obvious choice is role=img, but this has the disadvantage of announcing itself as an image (unnecessary chatter), and cluttering up any AT's special 'image viewer' UI with content which would be written rather than drawn, if it was pen and paper.

Written rather than drawn, but not written as words, which is what role="text" implies. Yes, some might perceive "image" as unnecessary chatter, but at least the user knows that they're perceiving information which is different to its original form.

Such a mechanism could also be employed for fixing the otherwise arbitrary pronunciation of non-glyph text abbreviations such as "IV", which in our products we absolutely need announced correctly as the letters "I-V", rather than "Four" or "Roman Four", which is what happens today. And we want "IV" on the screen.

I totally understand that "Roman 4" is not desirable. However, simply overriding it with "I V" (with no indication to the AT that this is an override) means the user will never know this wasn't the way it was originally written. Let's consider a student reading your publication. If they're using speech, they might read character by character to learn how it was written. If they're using braille, this is always how they'll read it. Now, that student believes "I V" is the correct way to write it, and they get marked down for incorrect formatting.

mmHg (mispronounced as em-em-aitch-gee, should be "Millimeters of Mercury")

This is extremely verbose. A screen reader is also about efficiency. There's a reason you write "mmHg" in print: because it's inefficient and tedious to read and write "Millimeters of Mercury" every time. And see above re braille and understanding of how the content was written.

C/O (mispronounced as "c-slash-oh" or sometimes "care of",

IMO, screen readers shouldn't even be trying to guess this kind of thing. If a screen reader or speech synthesiser maps this to "care of", it's wrong.

<p>I <span role="text" aria-label="love">❤️</span> New York</p>

There's a reason the author chose to use ❤️ instead of "love", and brevity isn't really a solid argument here. Using role="text" in this way completely deprives the user the ability to perceive this choice.

<p>[<span role="text" aria-label="banana">bəˈnɑːnə</span>] est la prononciation du mot "banane" en anglais.</p>

Now we've broken a budding linguist's ability to learn how to write IPA.

<span role="text" aria-label="Hello, I'm some text for screen reader users."></span>

This conflates an entirely different (and IMO controversial) concept into this already problematic paradigm. Semantically, screen reader only text is very different to "how something should be pronounced". This sort of conflation is poor design and leads to a lot of future pain.

To be clear, I'm not suggesting that incorrect pronunciation isn't a problem. It is, especially something like IV as "Roman 4" or AED as "aired". However, completely overriding the text is absolutely the wrong solution. Providing some sort of speech hint might be a better solution, though we should prefer hints like "this should be spelled" over hints like "pronounce this as I V" where possible. This way, an AT (or even the user) can make a choice about what context something is being presented in. If it's speaking a line or continuously, it will honour the speech hint. If it's moving character by character, probably not. On a braille display, definitely not.

[sinabahram]

As a screen reader user and someone whose been working in/around accessibility/inclusive design for 15+ years, I absolutely and unequivocally agree with every single point made here by James. Thank you for such a detailed treatment of the issue. +1, and all that.

[brennanyoung]

I totally understand that "Roman 4" is not desirable. However, simply overriding it with "I V" (with no indication to the AT that this is an override) means the user will never know this wasn't the way it was originally written.

I get your point in the abstract, but equally, users can't be expected derive the spelling "IV" (in upper case) from the announcement "four" using the current spec, so people are going to try and work around the problem in whichever way works if ARIA doesn't propose a viable solution.

Besides, in this very case I'm not proposing "simply overriding it with I V". The more serious problem is more that it's already getting overridden. In this case we just want "IV" to be communicated as written, with no space in between, exactly as it appears on the screen, exactly as domain professionals say it and write it everywhere. This case, unlike some of the others mentioned here, is not about spoken vs. written forms, it's about content authors losing control of the content entirely.

Additionally, even if we wanted to help fix things, we have little clue whether it's the browser, the OS, the speech synth, or the AT, or perhaps some combination of all which is making these arbitrary substitutions. I don't even know who to address my bug-reports to! (I don't believe it's the AT folks, btw). The lack of transparency here is a significant part of the problem.

The cases of ❤️ for "love" or ASCII art are qualitatively different, and (in my mind) call for a role=img implementation.

The case of "mmHg" is perhaps different again, and could perhaps be handled with <abbr>, although <abbr> becomes tiresome or inappropriate after a few instances of the same sequence. (That problem needs solving too).

But if "mmHg" is always announced by a screen reader as its written, my editorial and educational colleagues would find that just as incorrect as always announcing it as it is spoken by medical professionals. Rather than privileging the spoken form, it privileges the written one. I can't see that's any better or worse. Am I misrepresenting your argument?

An important part of the nursing curriculum is to learn how to speak out loud what you are doing (it's called "closed loop communication"). You know, like in fictional surgery scenes "Scalpel?"... "Scalpel"... "IV?"... "IV"... etc. Saying "Four" in the operating room, when "IV" was intended would not just be wrong, it might even be life-threatening. So, an important learning goal for our products is training a certain formal kind of speech between medical professionals. Exact, unambiguous utterances are essential.

And when the sweating surgeon with all eyes and fingers on an exposed internal organ asks for "BP", the nurse really will utter the words "BP so-and-so millimeters of mercury" instead of "BP so-and-so mmHg", even if it would be written with more characters. Simulation verity is more important than brevity, for training purposes, at least, and I imagine that even disabled medical professionals would agree.

IMO, screen readers shouldn't even be trying to guess this kind of thing. If a screen reader or speech synthesiser maps this to "care of", it's wrong.

I completely agree. Yes. It's obviously wrong. Meanwhile in the real world this is exactly what happens. And content authors need to solve the problem today, whether or not ARIA has got around to it. We have a viable workaround in role=text dangling in front of our noses, and gatekeepers saying "don't use that".

Accessibility audits often flag violations because of browser/AT/ARIA implementation discrepancies which we are (apparently) expected to work around. If there's a bug with aria-live in VoiceOver only, our auditor expects us to work around it (which often requires fragile hacks) before they'll say we're compliant. The a11y blogs are stuffed full of weird workarounds which eventually become obsolete, exactly like the rest of the web authoring literature. Taking a conservative approach is understandable, but at some point, a culture of cautious criticism becomes a culture of learned helplessness, and concrete problems are simply abandoned without solutions, because the only solutions on offer are imperfect ones. And yet various parts of the aria spec are broken, (aria-haspopup? aria-flowto? aria-controls?), and even the most compellingly useful parts of ARIA have their imperfections.

I'm regularly asked when we can tell students with disabilities that they may use our e-learning products without missing important parts of the curriculum. If I could say "there's a solution coming in the next version of ARIA, but the spec is still being finalized", that would be great, but in this case I can do little more than shrug and say "there's a workaround which was pulled from the spec, because reasons, and there's no alternative on the table". Time passes. People with disabilities who might have become good nurses choose other educations, or don't get an education at all.

So, what role=text img has going for it is that it's already implemented 'almost everywhere', and offers an acceptable solution which works today, for exactly the case of "IV" (if not for mmHg, too). I would so welcome a better-considered alternative, but those alternatives aren't exactly laying thick on the ground. Neither role=img nor <abbr> solve the problem of communicating the sequence "IV" predictably in speech. Both put the precise interpretation beyond the reach of the content author. And that sucks.

I'm (of course) prepared to bow to better-informed judgement on why role=text is not the right approach. I would certainly have appreciated seeing some record of the discussion about the last-minute removal of role=text from the proposed spec. (Where is that discussion archived, please? It appears to have happened in private.)

So... is there a discussion ongoing somewhere about an alternative mechanism for solving this problem? Is this that discussion? Is it even considered a problem? If not, why not?

Maybe a solution such as offering a speech hint (please tell me more!) has been proposed (and rejected for other reasons). Have any other suggestions been made? Are there any spec drafts? Prototypes? Another thread on this board? Another board? What's a good search query for this topic? I want to follow any such discussion very closely, so that I can inform my editorial colleagues when they might expect their AT-dependent users to get the correct domain-specific terminology, both written and spoken, in the courses we produce. They are more than eager to know.

If there is no such discussion, then for now, it seems that role="text img" actually gives us exactly the behavior we need today to get "IV" and similar text sequences communicated in a predictable way to all users with a reasonable fallback for FF users. So it's going to get used, warts and all. If there is a preferred and viable alternative I will gladly use that instead of the compellingly appropriate but conceptually flawed workaround.

role=text may be conceptually broken, but as W.R. Ashby put it "Every system changes its mind by breaking".

[carmacleod]

@brennanyoung

I would certainly have appreciated seeing some record of the discussion about the last-minute removal of role=text from the proposed spec. (Where is that discussion archived, please? It appears to have happened in private.)

Found it!
https://www.w3.org/2016/03/17-aria-minutes.html#item09
https://www.w3.org/2016/03/31-aria-minutes.html#item04
RESOLUTION: Move role=“text” to ARIA 2 as the group does not believe it can address the issues well in the ARIA 1.1 time frame.

Note that the group did try again 2 years later, with role=static
https://www.w3.org/2018/01/11-aria-minutes.html#item02
jd: dont have consensus... what are the next steps
mk: think we need to be thinking about the problem we are solving and whether we are solving 1 problem and creating 10... don't want us to go down that path

---

So... is there a discussion ongoing somewhere about an alternative mechanism for solving this problem?

Not to my knowledge. For ARIA 1.2, the group was focused on achieving role parity with HTML.
Let's reopen the discussion here. :)

@jcsteh made a good start:

To be clear, I'm not suggesting that incorrect pronunciation isn't a problem. It is, especially something like IV as "Roman 4" or AED as "aired". However, completely overriding the text is absolutely the wrong solution. Providing some sort of speech hint might be a better solution, though we should prefer hints like "this should be spelled" over hints like "pronounce this as I V" where possible. This way, an AT (or even the user) can make a choice about what context something is being presented in. If it's speaking a line or continuously, it will honour the speech hint. If it's moving character by character, probably not. On a braille display, definitely not.

My 2c:
Since the group tried twice to solve this problem using a role - and failed twice - I think it's pretty clear that we need to explore using an attribute instead. Jamie is suggesting something like aria-speechhint that would take tokens, like for example "spell". This might work. What do others think? What other tokens might be needed? (we can always add new ones as needed, but we should start with the most useful ones).

[JAWS-test]

aria-spechhint sounds good because it is able to meet the requirements formulated here by @brennanyoung and @jcsteh:

• correct acoustic output when reading out text
• correct display on the Braille line and correct acoustic output when spelling

[jnurthen]

Please be aware work going on in APA for pronunciation.
https://www.w3.org/WAI/pronunciation/

[carmacleod]

Please be aware work going on in APA for pronunciation.
https://www.w3.org/WAI/pronunciation/

Thanks, @jnurthen. Very interesting. They are already working on solving the problems we have been discussing in this issue, and they have made a lot of progress.

@brennanyoung I encourage you to consider joining the Pronunciation Task Force - I think you have a lot to offer them, and you are clearly interested in the subject. You could ensure that your use cases are covered while keeping close tabs on progress. :)

My apologies for not knowing about the pronunciation work before - it would have saved us all some time. :)

I think this issue can be closed. Any objections?

[carmacleod]

@cookiecrook Looks like the history is all here in this issue (either directly, or in links). You'll probably want to read through from the very first comment all the way to the last... have fun... 😄

[cookiecrook]

Joanie mentioned an old branch exists too. Among other edits, it changes the text role to static. Noting that exists here so I'll remember it when I start work on the issue.

[cookiecrook]

Also, since both WebKit and Chromium Edge support the text synonym, I think that's worth a note in the spec. UAs can modify it so that the returned computed role is static, but may choose to leave the old name for legacy interop and backwards compatibility.

[cookiecrook]

@carmacleod wrote:

@cookiecrook Looks like the history is all here

I don't see the earliest proposals from @stevefaulkner, but I'll dig for them unless he beats me to it.

[carmacleod]

@cookiecrook

I don't see the earliest proposals from @stevefaulkner, but I'll dig for them unless he beats me to it.

Pretty sure this 2011 wai-xtech mailing list thread from ARIA tracker ISSUE-435 is the earliest proposal from Steve.

Joanie mentioned an old branch exists too. Among other edits, it changes the text role to static.

Here's the role-static branch and here is the generated content for role=static.

Also, since both WebKit and Chromium Edge support the text synonym, I think that's worth a note in the spec. UAs can modify it so that the returned computed role is static, but may choose to leave the old name for legacy interop and backwards compatibility.

Interesting that role=text is still implemented in 2 user agents. Note that you might want to read these 2 later comments first, before reading the rest of the comments in this issue (of course, after reading everything to refresh your mind, your take on this whole thing will be really valuable):

• Consider early re-add of role=text #870 (comment) - Since the group tried twice to solve this problem using a role - and failed twice - I think it's pretty clear that we need to explore using an attribute instead...
• Consider early re-add of role=text #870 (comment) - Please be aware work going on in APA for pronunciation... Thanks, @jnurthen. Very interesting. They are already working on solving the problems we have been discussing in this issue, and they have made a lot of progress.

[cookiecrook]

Removing my assignment because I will not be able to address this in the 1.3 Milestone.

[cookiecrook]

• WebKit intends to drop its never-standardized text role implementation #2011

[jnurthen]

as webkit intends to drop this I think we should close this issue.