Landmark label ignored if aria-labelledby refers a child element

[hrvojegolcic]

Seems like a landmark label/name defined as aria-labelledby will be announced or ignored inconsistently based on:

1. Position of the element referred by aria-labelledby (inside or outside of a landmark)
2. Interactive content in the landmark reached by TAB key when entering it (e.g. in my case the different behavior for links inside of lists and tablists)

Steps to reproduce:

1. Use NVDA in combination with IE 11, FF or Chrome (my setup specified below)
2. Open https://codepen.io/Hrvoje-Go/pen/eYJrZEY
3. Navigate the page ONLY by using the TAB key
4. Notice how the landmark label/name is announced or ignored inconsistently. The landmark role itself (main, navigation, region) is always announced, but not the label/name
   

Actual behavior:

1. FAIL: Landmark label/name is ignored if defined as aria-labelledby that refers to an element contained inside of the landmark HTML element
   • The example code uses <nav> and <section> elements to define a landmark
   • The example code uses <h3> element as a reference for aria-labelledby, but it's the same case is with <span> and/or random visible or visually hidden HTML element
2. OK: Landmark label is announced if implemented as aria-labelledby that refers to an element outside of the landmark
3. STRANGE: If the inner element is a link with a role tab in a tablist then the landmark label is announced regardless if the referred element is inside or outside of the landmark
4. OK: Landmark label is announced always when aria-label is used instead of aria-labelledby

Real use-case (detailed information)

Our actual product implementation includes a header with 4 navigation menus each containing it's own visually hidden heading (for better outline, and for users who navigate by headings) e.g. "Quick access" nav, "Main" nav, sub nav, etc.. One of those menus is implemented as a tablist and others as a list of links. When navigating with a TAB key the tablist navigation menu does announce its landmark label/name and the other 3 menus do not. There would only announce the role "navigation landmark" without a label to distinguish from. That was confusing and also how we recognized the issue in the first place.

I assume that NVDA wanted to ignore the landmark label if contained within the landmark HTML element itself. Probably to avoid duplicate announcement when navigating in virtual mode. There are a few points, in my opinion, where this might not be the best idea:

1. Not analog to aria-label behavior which is always announced. One would logically assume that aria-labelledby could easily replace aria-label retaining the same behavior - always announcing the label regardless of the position of the referenced element
2. Not intuitive. Unexpected behavior. One would not expect that the landmark labeling will not work or stop working if the referenced element position has changed (e.g. from inside to the outside). Can be broken easily during the development or maintenance (e.g. by developers/designers who focus on a different problem). Who could constantly keep track of the position of the referenced element and follow up how will this impact the screen reader?
3. Inconsistent. As recognized in our navigation menus example where lists of links and tablists are used sequentially but the behavior is different although it's the exact same implementation of the container element - navigation landmark (nav + aria + h3)
4. If a user uses only the TAB key to navigate the menus, which is not so difficult to imagine, then both landmark label and actual heading announcement is skipped. In this case the trial of NVDA to avoid duplicate announcement led to not announcing anything at all (?)
5. Might be controversial but there are a few good points that NVDA would not be doing anything wrong if the announcement would be duplicated. First time for the landmark and second time for the heading. It's two different things nad it's kind of expected if that's how it was developed. See Draft guidance to help authors understand the difference between landmark regions and outline sections w3c/aria-practices#575 (comment)
6. JAWS imho behaves correctly here as one would expect, not trying to assume anything and outsmart the implementation. In this specific case maybe NVDA might not be doing better

Expected behavior:

1. Landmark label/name should be always announced aside to a landmark role when defined as aria-labelledby. It must be regardless if the referred element is outside or contained inside of the landmark HTML element as a child. Also regardless if navigating by TAB key caused entering the landmark region first onto a link in a list of links or a tab in a tablist. The behavior should be analog to the announcement when aria-label is used - The label should be always consistently announced!

System configuration

NVDA installed/portable/running from source:

installed

NVDA version:

2020.1

Windows version:

Windows 8.1

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

• Chrome 80.0.3987.122
• Edge 83.0.478.61
• Firefox 77.0.1
• IE 11.0.9600.19724 (version update 11.0.195)

Other information about your system:

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 addons are disabled, is your problem still occuring?

• No NVDA addons.
• No browser extensions (clean installation)

Did you try to run the COM registry fixing tool in NVDA menu / tools?

Yes

[Adriani90]

cc: @jcsteh may you have some thoughts on this?

[alanfluff]

+1

I was actually thinking "Do I need to consider telling the W3 authors of this page that their example is wrong?", because tabbing into a link in the nav AT (NVDA) does not announce the text of the h2 even though it is referred to via aria-labelledby (if the h2 is outside the nav then it does get announced).

Relieved to see this is not my misunderstanding the correct HTML/ARIA pattern, but a bug with NVDA.

Forgive the following question (I am a bit of a newbie when it comes to understanding how fast NVDA devs are able to respond to issues such as this), is this likely to be fixed soon (I assume not if this issue is from 2020)?

[Adriani90]

cc: @seanbudd, @michaelDCurran, @jcsteh this is also related to #10512 or more exactly, this is actually the symptom causing that repetition probably.

[jcsteh]

Actually, #10512 is the opposite of this in the sense that #10512 wants less repetition, where this issue proposes that we introduce more repetition.

NVDA should only avoid speaking the label of a landmark if you move directly to its label. For example, if you press down arrow to move to a heading which is both the first thing inside that landmark and also labels the landmark, NVDA will not report it. In contrast, if you tab to a button inside the landmark, the label of the landmark should be reported.

Even with the test case you provided, this is the behaviour I am seeing in Firefox. I suspect this might have been fixed since NVDA 2020.1 against which this was reported.

[jcsteh]

This is probably a duplicate of #13307, fixed in NVDA 2023.1.

[jcsteh]

Additional testing suggests this is indeed fixed. Closing as a duplicate of #13307.