aria-hidden="true" is ignored for role="listbox" with tabindex="0"

[gdkraus]

Summary

When aria-hidden="true" is applied to an element containing other child elements, some ARIA roles that also have tabindex="0" in the child elements are still read by JAWS.

Here is a demonstration of the problem where the role="listbox" is still announced.

Expected result

Nothing in the div with aria-hidden="true" should be read by JAWS with the virtual cursor. Most of the items in the div are ignored, but not all.

Actual result

The role="listbox" is read.

Example

https://codepen.io/gdkraus-sas/full/NWbbpKQ

Note, while in this example you can still tab to a component inside the aria-hidden="true" div, I did this for simplicity in the example. The place we first found this was with content behind a modal dialog in one of our apps, where keyboard focus was being handled programmatically and you could not actually tab to the items with aria-hidden="true" even if they had tabindex="0".

Additional Information

I have not tested all ARIA roles for this behavior, but based on where we first experienced this, I would not be surprised if other ARIA roles are impacted. Having tabindex="0" also seems to be a key triggering issue.

JAWS version and build number

2021.2012.57

Operating System and version

Windows 10

Browser and version:

Chrome 88

[scottaohara]

Why are there focusable elements within an aria-hidden=true container?

ARIA WG / screen readers are working together to purposefully make sure that focusable elements within or with aria-hidden=true attributes are read out, because situations like this would otherwise mean that screen reader users could keyboard focus these controls and be presented with no information.

see: https://github.com/w3c/aria/issues/1381

[JAWS-test]

Why are there focusable elements within an aria-hidden=true container?

The problem also occurs with listbox when it has tabindex=-1. Furthermore, the problem occurs with linear reading. With tab, of course, the element should be output correctly, but not when reading with the virtual cursor. In my opinion, this is actually a JAWS bug (which does not occur with NVDA, for example).

A JAWS bug is also indicated by the fact that Chrome's Accessibility API correctly transmits button and listbox, but only the listbox is output.

Also, this is a common use case: the background of a pop-up is hidden with aria-hidden and is not accessible due to focus handling (via JS). However, instead of aria-hidden, aria-modal could also be used on the pop-up. However, aria-modal has the disadvantage that the elements are still displayed in the element overview (e.g. INS+F5)

[JAWS-test]

I have checked most of the HTML elements and ARIA roles inside aria-hidden. The problem occurs only with the following elements

Firefox:

• never

IE 11:

• role=tree

Chrome, Edge:

• select size > 1
• role=listbox
• a href=... with explicit label (e.g. aria-label)
• role=link with explicit label (e.g. aria-label)

Listboxes and links differ, however, in that the listboxes (HTML and ARIA) are also displayed with INS+F5, but the links are not displayed with INS+F7.

[gdkraus]

When I read through the latest changes regarding aria-hidden="true" from the WG, it seems like the change is to say that you include an entry in the accessibility tree if an item is "currently focused", not "focusable". If I am misunderstanding that or there is something newer, please let me know. In our case, we were able to read the content marked with aria-hidden="true" with the virtual cursor while keeping focus on another item outside of the aria-hidden="true" section.

Also, if I change the set up a bit and use role="dialog" and aria-modal="true" where the rest of the "background" has aria-hidden="true", if I toggle the restriction mode I can still read the listbox with the virtual cursor, but not anything else in the aria-hidden="true" sections.