Can't review/spell text of accessible names applied with aria-label/labelledby in focus mode

[jscholes]

When a control on a web page is given an accessible name via aria-label or aria-labelledby, and NVDA's focus mode is active, the text of the control's name cannot be spoken or spelled with the "report current line" command, nor reviewed with text review commands. This is a significant problem in apps like Slack, where each message is wrapped inside a list item with a custom accessible name. In focus mode, the message cannot be repeated, spelled, or moved through by character without reverting to browse mode first.

Steps to reproduce:

1. Navigate to https://jscholes.github.io/invisible-names.html in Chrome.
2. Press NVDA+Space until focus mode is active.
3. Tab to the first button, which has an accessible name of "Button 1" applied with an aria-label attribute.
4. Press NVDA+Up Arrow (desktop) or NVDA+L (laptop) to report the current line. Press the same keystroke quickly to spell it.
5. Press other text review keystrokes, like Numpad 1 and Numpad 3 to navigate through the name of the button by character.
6. Tab to the second button, which is named "Button 2" via an aria-labelledby attribute, and repeat steps 4 and 5.
7. Repeat steps 2 through 6 in Firefox.

Actual behavior:

The name of the button is announced when focused, but the "report current line" command and other text review commands behave as though the button has no name. For the button using aria-label, NVDA explicitly announces "blank" when trying to review its name. But for the second button that uses aria-labelledby, the relevant commands only result in silence.

Speech Log

NVDA+space Focus mode tab Button 1 button NVDA+l blank numpad 1 Left blank numpad 3 Right blank tab Button 2 button NVDA+l

numpad 1 Left

numpad 3 Right

Expected behavior:

The name of the focused button is announced when using the "report current line" command, while other text review commands allow the name to be reviewed as text. There is no difference between controls named via aria-label and aria-labelledby. Here is a speech log of how it might sound:

NVDA+space Focus mode tab Button 1 button NVDA+l Button 1 numpad 1 Left cap B numpad 3 Right u tab Button 2 button NVDA+l Button 2 numpad 1 Left cap B numpad 3 Right u

NVDA logs, crash dumps and other attachments:

None

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2023.1

Windows version:

Windows 10 Pro, 64-bit, build 19045

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

• Chrome 114.0.5735.199 (Official Build) (64-bit)
• Firefox 115.0.2 (64-bit)

Other information about your system:

None

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

No

If NVDA add-ons are disabled, is your problem still occurring?

Yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Yes

[amirsol81]

I can duplicate this. @seanbudd @jcsteh This may also describe NVDA's inability to report some controls, via NVDA key+Up, in the Skype application for Windows - namely in the Search results section for people and bots.

[jcsteh]

The review cursor explicitly navigates text content, only falling back to name and description when the object doesn't support text content. The problem on the web is that almost every object supports text content, even if it doesn't contain any. To provide a simple example of why NVDA does this, consider a text box. In a text box, you absolutely want the review cursor to review text content, even if the text box has a name. So the question then becomes: when should the review cursor review name and description despite an object's support for text content?

Browse mode has a bunch of rules for when to render name instead of content. I guess similar rules could be applied to the review cursor, though it's not a direct mapping. For example, browse mode shows the full subtree for list items instead of just the name, which is why you can read rich content (links, etc.) in a Slack message in browse mode instead of just the flat label.

A simple rule would be that in focus mode, the review cursor should only review text content in editable text boxes. However, there's likely some case that breaks for someone or other.

[jscholes]

@jcsteh Thanks for the additional context! One aspect I didn't include in my original report, underlining the importance of this, is that NVDA's current behaviour can be actively misleading (or at least confusing) when the review cursor falls back to text content for elements with an overridden name. For example:

<button aria-label="X">Y</button>

If this button has focus and users press NVDA+Tab, they hear "X button focused". If they press NVDA+L in browse mode, they hear "button X". But if they press NVDA+L in focus mode, they hear "Y". Pretty weird.

[jcsteh]

Yeah, I'm aware of that and I agree with you. The more I think about it, the more it makes sense to make the review cursor only review text content in web focus mode for editable text controls, since that's the only time the review cursor will properly handle embedded objects anyway.

[jscholes]

@jcsteh I was trying to think of cases other than editable text where reviewing the name would not be optimal. All I came up with was a slider, with or without aria-valuetext, where it seems helpful for the review cursor to reflect the textual representation of the value rather than the slider's name.

[Emil-18]

Another problem related to this is that in the example above, a user that only uses braille can't in any way get the 'y' displayed, because _hasNavigableText returns False. What about only allowing text review if the _hasNavigableText returns True, and adding a setting that toggles if _hasNavigableText should return True where text review was previously available?

[jcsteh]

If the proposed change is made here, a speech user wouldn't be able to see the "y" either. That would mirror the behaviour in browse mode and is the appropriate thing to do for both speech and braille, since aria-label should override text content for buttons.

[jscholes]

@seanbudd This seems to have been assigned a p5 label, but in https://github.com/nvaccess/nvda/issues/15159#issuecomment-1639432784, I provided an example case of where NVDA's behaviour can be actively misleading. This, along with the frustration the issue can cause, would seem to make it a better fit for p3:

Misleading information or misleading handling

It certainly does not match the description of p5 as written, given how common it is to label focusable elements on the web using ARIA:

Other feature requests affecting a small subset of users

Could you please reconsider the assigned priority? Thanks!

[seanbudd]

Based on our new definitions, [this is a p4(https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md):

Web standard not followed causing app/web authors to require workarounds

Misleading information or misleading handling

I don't believe this is misleading information or handling, it is simply something not working at all.

Task not supported and no work around

It is not a p3 as there is a workaround.

[jscholes]

@seanbudd

I don't believe this is misleading information or handling, it is simply something not working at all.

With the following mark-up, NVDA's review commands will convey the wrong accessible name in focus mode, rather than no text:

<button aria-label="X">Y</button>

The name of this button should always be "X", no matter how the user interacts with/queries it. But when using review commands in focus mode, the accessible name is conveyed as "Y", rather than nothing at all, which is actively misleading/confusing for users. Wrong output is far more misleading than no output in this case.

[seanbudd]

Thanks for explaining, I'll bump the priority

[jscholes]

Thanks, appreciate it!