Link to issue number:

Fixes #15159. Fixes #11285.

Summary of the issue:

In focus mode in web browsers, when a control specifies a label using aria-label or aria-labelledby, it is impossible to review or spell that label; e.g. using read current line or the review cursor. This is particularly annoying and detrimental to efficiency when using web apps such as Gmail and Slack, among others, where you have to switch to browse mode to work around this even though it might be more efficient to use focus mode for navigation.

The same bug also applies in Google Chrome menus and dialogs where UIA is not used, such as in Chrome 137.

Description of user facing changes:

In focus mode in web browsers, it is now possible to review and spell the labels of controls when those labels are specifically provided for accessibility; e.g. via aria-label or aria-labelledby.

Description of development approach:

When in focus mode, for non-editable controls, both speech and braille report the name, description, value, etc. of the control; they don't use the TextInfo. However, previously, the review cursor and the read line command always used the TextInfo. Since IA2TextTextInfo is used for all objects supporting IAccessibleText, this meant that if the content wasn't a flat piece of text equal to the label, the review cursor and read line command would report something different, often nothing at all. To fix this, use NVDAObjectTextInfo instead of the object's TextInfo for object review and the read line command.

Testing strategy:

In both Firefox and Edge:

1. Followed and verified the steps to reproduce in Can't review/spell text of accessible names applied with aria-label/labelledby in focus mode #15159 (comment).
2. Also tested with the review cursor in the Gmail message list, where previously, the review cursor couldn't read the message details. With this change, it can. Same for read current line.
3. Verified that braille remains the same as before (the expected behaviour) in all of these scenarios.
4. Also tested this test case:
   data:text/html,<textarea>ab
   Verified that in focus mode, formatting info is still reported for the review cursor, indicating that the correct TextInfo is being used. Also verified that the review cursor tracks the caret.
5. With a multi line message in Gmail, verified that read current line reports the correct line when on the second or subsequent lines.
6. I wasn't able to reproduce NVDA+Up fails to read or spell many controls and lines in Google Chrome #11285 myself. However, @amirsol81 verified that this change fixes that too.

Known issues with pull request:

Although this fix is primarily about focus mode in web browsers, the code paths it touches are more generic than that. Anything that has a specific TextInfo but for which _hasNavigableText returns False will be impacted. This is consistent with how we report the focus with speech and what is shown in braille, and thus I think this makes sense. Nevertheless, this potential broader impact is worth noting.

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

@coderabbitai summary