standards-support icon indicating copy to clipboard operation
standards-support copied to clipboard

JAWS ignores the text in aria-roledescription

Open sergeicodes opened this issue 5 years ago • 5 comments

Summary

When specifying the custom text in the landmarks with aria-roledescription, JAWS ignores the text and keep pronouncing default role descriptions.

Expected result

JAWS to pronounce the custom text.

Actual result

JAWS ignores the custom text.

Example

https://codepen.io/anon/pen/jXmyqY?editors=1100

Additional Information

  • since codepen doesn't support IE, there is no way to open the link above there, but I tested in the local machine and got the same result

  • an example above is also tested with roles specifies explicitly with the same result

JAWS version and build number

JAWS version 2018.1811.2 ILM

Operating System and version

Windows 8.1

Browser and version:

Internet Explorer Version 11.0.9600.19204

Google Chrome Version 71.0.3578.98 (Official Build) (64-bit)

Firefox Quantum 64.0 (64-bit)

sergeicodes avatar Dec 23 '18 13:12 sergeicodes

@krigersergei there is already an internal issue to implement aria-roledescription in JAWS: Bug 101891 - Add support for the aria-roledescription property to Chrome and Firefox. I have referenced the issue you raised and also have commented the following:

Reviewing NVDA role description support - NVDA announces the role first then announces the role-description on container elements such as landmarks (test case: https://codepen.io/stevef/pen/dwZzLG). On interactive elements such as links or buttons (test case: https://codepen.io/stevef/pen/NewwZr) only the roledescription is announced. Note that although the role "link" or "button" is not announced using the NVDA virtual cursor navigation keys "B" for button or "U" for unvisited link results in the elements receiving focus as per the unannounced native role. I strongly suggest that JAWS implement roledescription so that the native role is always announced along with the role description as this will provide the user with an undertanding of how to interact with the element.

related: https://tink.uk/using-the-aria-roledescription-attribute/

stevefaulkner avatar Dec 31 '18 11:12 stevefaulkner

In this example, the regions could be labelled with aria-label instead of aria-roledescription, so that the role is kept and the specific purpose of the region can be seen from the label.

JAWS-test avatar Jul 18 '19 12:07 JAWS-test

I still see no fix for this (Jaws 2019.1812.49, tested in most recent version of Chrome and a slightly older version of Firefox)) What is worse, if you use the aria-roledescription attribute on a container element, Jaws will announce the value of that attribute for all semantic elements inside that container. For the following code example, Jaws will say "next carousel" and "previous carousel" for the two buttons in the carousel container (oddly it will not mention the word "caoursel" as you enter or exit the carousel landmark).

<div role="region" aria-roledescription="carousel" aria-label="My favorite things">
  <button>Next</button>
  <button>Previous</button>
</div>

Since aria-roledescription is now recommended as a mechanism to identify the carousel and slide elements in the the ARIA Authoring Practices carousel entry this bug is going to make carousels implemented according to that specification all but impossible to access and operate with Jaws.

Wildebrew avatar Jul 29 '19 15:07 Wildebrew

We are hitting similar behavior when trying to override menu, created ticket: https://github.com/FreedomScientific/VFO-standards-support/issues/286

kolaps33 avatar Sep 04 '19 12:09 kolaps33

Any updates to this? Still running into this problem on a div with role="group". Thanks.

ArmandFrvr avatar Apr 29 '22 21:04 ArmandFrvr

tested using JAWS 2023.2307.37 and Chrome Version 115.0.5790.171 (Official Build) (64-bit) https://codepen.io/stevef/pen/QWzLgpw

works as expected: JAWS announces role-descriptions

stevefaulkner avatar Aug 16 '23 11:08 stevefaulkner