<button> element with text-transform: uppercase makes NVDA read letters instead of words

HamletDRC commented 7 years ago

Steps to reproduce:

Here is some simple HTML that triggers the issue. The button has the label "Off" and text-transform capitalize is used to transform this to OFF for sighted users.

<!DOCTYPE html>
<html lang="en">
<body>
<button>
    <span style="text-transform: uppercase">Off</span>
</button>
</body>
</html>

or as a data URI: data:text/html,<button><span style="text-transform: uppercase">Off</span></button>

Expected behavior:

I expect NVDA to read "Off" (this is English OS)

Actual behavior:

NVDA reads "Oh Eff Eff" (which are the letters)

System configuration:

NVDA version: 2017.3

NVDA Installed or portable: installed

Windows version: Windows 10

Name and version of other software in use when reproducing the issue: Firefox 55.0.3

Other questions:

Does the issue still occur after restarting your PC? Yes Have you tried any other versions of NVDA? No

HamletDRC commented 7 years ago

Another example is the text "Add Tag". When the text-transform is present then NVDA reads "Add Tee AYE GEE" (T-A-G). But the word "add" is read correctly.

ehollig commented 6 years ago

I think this is a limitation of the synthesizer. Which synth are you using? CC @feerrenrut

feerrenrut commented 6 years ago

I added a data URI version of the example to the description. I can reproduce this when using the Espeak synthesizer, in NVDA version next-14588,6a175cf6 .

One interesting thing to note is that when reading out the element after pressing down arrow, NVDA reads "Button O F F" as individual letters. When using Ctrl+Right Arrow NVDA reads "Off" as a single word.

Both SAPI5 and OneCore synths speak "off" as a single word.

dlockhart commented 6 years ago

Recently ran into this issue as well, and it caused my organization to abandon our use of uppercase text in buttons.

From our testing, the following words incorrectly read out as acronyms:

Log in (log specifically), New, Off, Tag, Yes, Add

Other tested words, read correctly as whole words:

About, Cancel, Close, Community, Course, Delete, Done, Edit, No, Okay, Print, Profile, Restore, Save, Show, View, Who

Google's Material Design uses uppercase text in their buttons, and is implemented as text-transform: uppercase in their web component. @robdodson, are you aware of this defect and whether Google has done anything to specifically work around it?

robdodson commented 6 years ago

I don't know of any workarounds that are being applied but I'll ask the Material team and report back.

panmona commented 5 years ago

Any updates?

feerrenrut commented 5 years ago

One workaround might be to do something like:

data:text/html,<button aria-label="off"><span style="text-transform: uppercase">Off</span></button>

From our testing, the following words incorrectly read out as acronyms: Log in (log specifically), New, Off, Tag, Yes, Add

I assume that this is only when they are uppercase, and you are using the espeak synthesizer? If they are title case (as written), then with espeak they are announced as words. It is ambiguous whether an uppercase word should be presented as an acronym or not, extra context is necessary.

Ideally the browser would not be transforming the text provided to screen readers. Please feel free to report this to browser vendors. If you do so, please link to it from here so we can keep track.

fallenturtle commented 4 years ago

I'm having a similar issue with it readying "Us" as U-S and then I have some initials, OMS, that it reads out "oh-ems".

robdodson commented 4 years ago

I think the workaround @feerrenrut suggests is a good short term solution.

@feerrenrut I can open a chromium bug on this if that'd be helpful?

Adriani90 commented 4 years ago

Not sure if this can be consistently solved actually. The fact that the synthesizers behave differently here means that this behavior might be controled by some phoneme aspects in the synthesizer code itself.

For example some synthesizers read Usa as "Usa" and USA as "You-Es-A", which is actually expected behavior. Or for example LBGTQA compared to lbgtqa, the pronounciation with capital letters being reported each is the expected behavior when reading the text.

The think is that some web authors might use the text transform capitalize to display Usa as USA or lbgtqa as LBGTQA or something like this.

I hope I didn't misunderstand the issue here.

I agree with @feerrenrut that browsers should not provide such text transform feature to avoid confusions for screen reader users.

cc: @ObjectInSpace, @Aleventhal, @jcsteh

robdodson commented 4 years ago

@Adriani90 yeah it's tricky. My hunch is we could advise folks to write acronyms in all caps in their HTML since, if the CSS didn't load, the content would still be capitalized. Then we could make the argument that text-transform in CSS shouldn't be used or interpreted as truly being all caps. But there are probably a lot of sites that would be broken by this.

dlockhart commented 4 years ago

That's definitely the argument I would make -- CSS applied to text is stylistic, not semantic. So in the same way font-weight: bold shouldn't be interpreted by AT the same way the <strong> (or <em>) element is. And less obviously: how a large & bold font isn't the same as a heading element.

But Rob's right, it would definitely break some existing sites, in the same way treating text-transform: uppercase as a semantic uppercasing is breaking a different set of sites.

feerrenrut commented 4 years ago

I can open a chromium bug on this if that'd be helpful?

@robdodson Yes, that would be helpful. Thanks!

Adriani90 commented 1 year ago

@robdodson is there a chromium bug filled for this? Could you please post a link so we can track that bug here as well?

robdodson commented 1 year ago

Hi @Adriani90, apologies but I don't think I ever opened a ticket for this. I no longer work at Google, but if folks would like to open a ticket they can do so at crbug.com

Adriani90 commented 2 months ago

Actually it seems only eSpeak is affected, and it is also reproducible in Firefox. Not sure opening a bug in Chromium would bring this further. @jcsteh, @SaschaCowley any thoughts? Should we report this maybe to the eSpeak repository rather than browser vendors?

jcsteh commented 2 months ago

Ideally the browser would not be transforming the text provided to screen readers.

...

That's definitely the argument I would make -- CSS applied to text is stylistic, not semantic.

This is tricky. While I can understand that argument, it's not quite that simple. By that logic, accessibility should ignore CSS display: none, visibility: hidden, list-style, pseudo-element content, white space stripping, etc. In practice, that's not what most users or authors want. A screen reader should generally try to present the text the way it appears visually unless it is absolutely clear that the author intends the visual and semantic presentation to be different. Among other things, we need to consider braille, as well as a screen reader user communicating with a sighted colleague. Yes, font-weight shouldn't be interpreted the same as strong, but the information is still exposed to accessibility because it might be relevant; it's just exposed differently. In the case of text-transform, we don't have a way to expose that except to alter the text. This is complicated by the fact that browser accessibility engines need to use the layout engine to retrieve text because of list-style, pseudo-elements, white space stripping, etc.

SaschaCowley commented 2 months ago

I'm with Jamie here - I don't view this behaviour as a bug. I think hiding this information from screen reader users will create more confusion than it solves. Perhaps an option could be added to eSpeak (or possibly already exists) to pronounce all-caps words that are pronounceable according to the rules of the spoken language, rather than the current, which seems to be to pronounce 3 or fewer successive capital letters as individual letters, regardless of whether they're phonotactically valid.

nvaccess / nvda