Navigation Component: Accessibility

[Copons]

Currently the Navigation component uses a waterfall navigation.
When entering a child menu:

• The parent slides out to the left, and unmounts.
• The child mounts and slides in from the right.

Accessibility concerns were raised in the original PR.
Since this component is currently in __experimental state, I've decided to merge it anyway, slating the a11y discussion to a follow up — and here we are!

These are some of the concerns that we should address (cc @afercia):

When a new sidebar "slides in", the previous content disappears producing a loss of context that's hard to understand for users, especially screen readers users.

Whether a part of a UI that is currently used by users gets hidden or removed from the DOM, that's a big accessibility problem. There's a complete loss of context. Information on the number of items in the list and their nesting level is broken. Screen reader users wouldn't have a clue that a part of the UI just doesn't exist any longer (why should they?)

Moving focus programmatically should be rare and only implemented when it's the expected behavior for some ARIA pattern.

Let's figure out an accessible way to create a hierarchical navigation!

---

EDIT: Let's have a look at the Inserter accessibility audit that presents similar challenges to this component.

[Copons]

@afercia in the other PR you mentioned explorations and discussions:

Also, I would like to note that in other parallel issues about sidebars, there are ongoing explorations and discussions on how to move away from the concept of sidebars.

Would you be so kind to link them here, please? It would be of great help! 🙇

[afercia]

@Copons some initial discussion on the general "sidebar pattern" happened during the latest weekly accessibility meeting on Slack. A good summary of the main accessibility concerns regarding sidebars is here: https://wordpress.slack.com/archives/C02RP4X03/p1599839238147900

We didn't come to a conclusion though, I think this needs to be further discussed, also with the Design team.

[jeryj]

We're trying to use the Navigator on the inserter, and I'd love to be able to use a menu-like behavior of having the menu be one tab stop with arrows to move between items, and escape to return to the previous level. Is this something the @WordPress/gutenberg-components team would consider adding? I can contribute dev work if so.

[mirka]

@jeryj I think that would be possible in consumerland by combining it with the Composite components.

[jeryj]

@mirka, yes, it is possible. That's what I ended up doing, but I felt like I was hooking up a bit of complexity that could have been provided by the component. I'm not sure if that's too far-reaching for the component though. It would make implementing the navigation component far easier and consistent if the component could provide arrow key and escape to go back out-of-the-box.

[mirka]

I'm not sure if that's too far-reaching for the component though. It would make implementing the navigation component far easier and consistent if the component could provide arrow key and escape to go back out-of-the-box.

I see. I don't have a strong opinion, but I guess it would depend on whether this is a common use case. There is also #60927, where we're assessing whether/how to stabilize Navigator. It might be helpful to chime in that thread with this use case — seems relevant.

[ciampo]

I think that Navigator (not to be confused with the deprecated Navigation 😅 ) should not implement Composite internally. Navigator's goal is to allow navigation across different views. The component is completely agnostic about what such views render, and therefore it can't assume what keyboard behavior should be implemented. The only focus management-related assumption made by the component is that focus should be moved to the new view after each transition.