VoiceOver never reads the aria-label attribute of a nav element.

[Jihess]

Mac OS 12.6.1
Chrome 107.0.5304.121
VoiceOver never reads the aria-label attribute of a nav element.
So I add it again in the inner ul but it may cause other screen readers to read it twice :(

[scottaohara]

can you post a test case? I don't encounter the issue you're experiencing, but i'm also on macOS 12.4

<nav aria-label=foo>
  <a href=#>test</a>
</nav>

[Jihess]

@scottaohara sorry, I wasn't clear.
I have no issue with your code neither. Actually the bug appears only (or at least) when I have a list (ul, ol) as immediate nav child. In this case, the nav aria-label is ignored: https://codepen.io/Jihess/pen/WNyKBXE

[scottaohara]

ok. so that codepen doesn't really show anything either, but you seem to be talking about the following

<nav aria-label=foo>
  <ul>
     <li><a href=#>test</a></li>
    <li><a href=#>test</a></li>
 </ul>
</nav>

and if you navigate to those links via the tab key, then the navigation name is not announced. which, ok. i dunno how i'd classify that, as if you navigate via VO focus, one will come to the navigation first and announce the name just fine. but navigating directly via tab key, yeh it doesn't announce the nav name.

@mfairchild365 seems an interesting question to ask, when is something "supported" vs when is something just not matching one's expectations, but it actually behaves exactly as it should?

[Jihess]

Yes I'm talking about keyboard navigation with tab key.
When there's no list inside nav, this "hello" label is announced by VO:

<nav aria-label="hello">
        <button type="button">this is a button</button>
  </nav>

With a list inside, the label is not announced:

<nav aria-label="hello">
    <ul>
      <li>
        <button type="button">this is a button</button>
      </li>
    </ul>
  </nav>

[scottaohara]

right. but that's also my point. different expectations for different markup patterns and navigation methods. this isn't just unique to VO + Chrome, it behaves this way with Safari as well. Nor is this unique to just this markup pattern.

For instance, if you were to test the following:

<main aria-label=hey>
  <section aria-label=example>
    <button>foo</button>
  </section>
</main>

The name/role of the direct parent of the focused button would be announced, "example, region", but not the name/role of the main container.

This doesn't indicate a lack of support for anything, but rather is likely a very purposeful decision from the VO developers to not bombard a user with tons of container element announcements. For instance, there could be a number of named elements that are nested in each other, and the last descendant of that nesting chain (let's say there are 5 named ancestors) contains a focusable element. It'd be incredibly annoying to hear the 5 roles and names of the container elements, so the VO devs probably decided that if someone is navigating by the tab key specifically, then they are likely at least somewhat familiar with the structure of the page and are simply trying to find a specific focusable element. So, VO only announces the direct ancestral element's role (and name if it has one).

To loop this back to your op, and the 'solution' you came up with to use duplicate aria-labels on the nav and the nested list - seems to me that you shouldn't be doing this at all, and instead just name the nav. Again, this seems more a misconception that different navigation methods should produce the same screen reader output, which is not true for any screen reader. Navigating by virtual cursor/scan/browse mode (whatever that particular sr calls it) vs navigating by Tab key vs navigating when one is specifically in application/forms mode (if the sr has this feature) can all produce different outputs. And that's expected if you are familiar with using the software.

[mfairchild365]

I threw together a quick test so that I better understand what is going on here. https://codepen.io/mfairchild365/pen/MWXqrXb

Also, note that we do have a test for this in a11ysupport.io: Named Navigation Test. That currently shows support for the name being announced when tabbing into the navigation region... but only because the first element of that region is not within a list.

I do find it interesting that NVDA and JAWS both decide to still announce the navigation name/role, while VoiceOver does not.

I agree with @scottaohara that this might be an intentional decision on the part of Apple/VO to reduce verbosity. If the user really wants to learn more context about where they are on the page, they have a lot of commands at their disposal to explore and find that information - even if it might not be announced when tabbing.

On the other hand, it might not be intentional and might be a bug. We can't know without discussing it with Apple.

Right now, I'd suggest that conveying the name/role is supported by apple, but there are edge cases/caveats. I'd also suggest that the proposed solution of adding a duplicate aria-label to the UL element is not necessary and might result in unnecessary verbosity in NVDA and JAWS (worth testing).

In these sorts of situations, I lean on documenting the behavior rather than failing the tests. For example, in the Named Navigation Test (that I mentioned previously), the grading method for the relevant expectation is set to "Just one of the listed commands must pass for the expectation to pass." In other words, only one command needs to yield support in order for the broader expectation to pass (it's okay if some commands fail). A potential alternative might be to add this as a separate expectation with a lower strength (SHOULD instead of MUST) - but I usually try to avoid that for edge cases like this. If you think it's better to create a separate expectation for this, please say so and we can discuss it.

Ultimately, to document this within a11ysupport.io, we would either need to modify the existing Named Navigation Test (so that it doesn't start with a button outside of a list) or create a separate test (where the only contents of the navigation region are within a list). I'm leaning toward the latter... but honestly am not sure when I can get around to adding that to the project.

[Jihess]

Thanks a lot for your time guys :)
Yes it might be intentional or not...
Anyway I agree, we shouldn't bombard the user with too much information.
And if he really needs to know the context and where he is, indeed he has ways to do it.
So I remove my duplicated aria-label on the list, I only let it at the nav level :)

[scottaohara]

@mfairchild365 to further my point about needing different expectations for different navigation methods, and even what screen readers may decide to announce or not, take your test now and navigate by button element specifically. Only the button name is announced and never the parent container, when navigating via JAWS or VoiceOver button/form element quick keys, with default settings. But NVDA, also with default settings, WILL announce the button name, and its ancestral context (named nav and list where applicable). Is NVDA wrong because it's giving too much information? Are the other two wrong by not giving enough? Or is this just how these different screen readers have been made to work? I tend to think the latter.

You're right that the only way to be 100% sure on if something is expected behavior or not is to check with the people who work on the screen reader specifically, but it's also a fact that there are purposeful differences between how content is exposed based on how one is navigating a web page. I strongly question the expectation to compare screen reader behaviors to one another in this regard, especially across platforms where VO is purposefully very different in behaviors compared to its windows counterparts.

[mfairchild365]

@scottaohara this is getting a bit off-topic, but you raise some good points. I didn't mean to suggest that screen readers should behave exactly the same across platforms. Just that looking at how they behave across platforms can help to inform expectations. We still certainly need to look at the screen readers individually and account for their own design choices.

I agree that expectations often depend on commands. That's more-or-less the model we have taken over at ARIA-AT, which I hope will eventually replace this project. This project takes a different approach, where just one command needs to satisfy the expectation for it to be considered minimally supported. It does less to say "all the commands that are expected to meet this behavior work correctly" and more to say "well at least there is some support". (I'll also note that this grading behavior can be customized for each expectation... there are some other grading methods). It's not perfect, but I'd also argue that it's not bad either. All of these approaches come with their own pros/cons. I'd like to eventually make the expectations more command-dependent here and better match the data model that we have at ARIA-AT.