Link to issue number:

partial fix for #11829

Summary of the issue:

ARIA 1.3 adds a aria-brailleroledescription attribute, which allows the web author to specify a string representation for an element's role, specific to Braille.
For example:

<button aria-roledescription="planet" aria-brailleroledescription="plnt">Saturn</button>

A button whos spoken role description will be "planet" but in Braille it will be shown as the abreviated "plnt".

Description of user facing changes

NVDA will honor the aria-brailleroledescription attribute if set by the web author, when presenting web content on a braille display.

Description of development approach

The internal work to support custom braille role text had already been added to NVDAObjects and controlFields to allow for Braille abbreviations for landmarks. this PR:

• Implements roleTextBraille on the IA2Web NVDAObject, exposing the content of the brailleroledescription IAccessible2 attribute if available
• In the Gecko ia2 virtualBuffer, normalizes the brailleroledescription IAccessible2 attribute to the roleTextBraille NvDA attribute on controlFields.

Testing strategy:

Given the test uri:

data:text/html,<p>Big <button aria-roledescription="planet" aria-brailleroledescription="plnt">Saturn</button></p>

In Firefox, Chrome and Edge:

• Ensured that reading by line in browse mode spoke "Big planet Saturn" and Brailled "Big plnt Saturn".
• Ensured that tabbing to the button in focus mode spoke "Saturn planet" and Brailled "Saturn plnt".
• Also adding contenteditable="true" to the paragraph, ensured that the above actions still caused Braille to show "plnt" and not "planet".

Known issues with pull request:

None known.

Change log entries:

New features

• Added support for the aria-brailleroledescription ARIA 1.3 attribute allowing web authors to override the type of an element shown on the Braille display.
  Changes
  Bug fixes
  For Developers

Code Review Checklist:

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