Nav drawer a11y problems

[myasonik]

Critical (imo):

• The expand/collapse button needs a focus state (covered by Improve a11y in EuiNavDrawer #2417)
• On clicking the expand/collapse button, focus management is lost and is returned to the body. (It should stay on the button.) (EuiNavDrawer a11y, pt. 1 #2643)
• The navigation docking button sometimes has a focus state but also it blends into the hover state of the expand/collapse button so it's difficult for me to tell what's really going on. (covered by Improve a11y in EuiNavDrawer #2417)
• All of the "pin to top" buttons have the same label so in a rotor they're indistinguishable. Should be changed to something like: "Pin {link name} to top". (covered by Improve a11y in EuiNavDrawer #2417)
• Should be wrapped in a nav element (covered by Improve a11y in EuiNavDrawer #2417)
• Tab order in the nav list is backwards of what it should be. It starts from the bottom of the nav and moves it's way up. Likely it should be the opposite.
• Clicking on a grouped item should move focus to the inner menu, likely similar to trapped focus in popovers. Right now it just exposes the menu, but you need to cycle through the other items to get to them. (EuiNavDrawer focus management, flyout auto-close #2749)
• Group buttons need to announce themselves as much. Right now they are just listed as a button. (EuiNavDrawer focus management, flyout auto-close #2749)

Less so:

• The dock/undock button doesn't show up in a screen reader's rotor when the nav is expanded. (Should work the same as the "pin to top" buttons which do show up.)
• All of the "pin to top" buttons should have aria-pressed=true|false defined on them to communicate their state.
• The dock/undock button should have aria-pressed=true|false defined to communicate state. This can replace the role=switch and aria-checked=true|false.(EuiNavDrawer a11y, pt. 1 #2643)

Up for debate:
1. I think the focus order would be better in visual order. I get the argument that it's to keep users from having to tab through all the options, then hit "expand", then potentially go back to the option they want but I think it's so unexpected that it's difficult to find and you lose your place instead of it feeling smooth. I tried playing around with a super obvious focus state and that grabbed my attention enough that I knew what was going on but that'd be pretty far away from our current focus state styles.
2. I think EUI should provide a skip link past the navigation.

[barlowm]

@myasonik I think I opened an issue on that sometime back about initial focus and opening flyouts and then having to navigate (via kbd) through all the controls again. Is this the main nav bar on the left of the page?

[ryankeairns]

Related to #1712

[myasonik]

@barlowm and I discussed (with the a11y scrum) and we're not sure what to do about the focus order thing. But we heard that there are at least loose plans to redesign the nav so it's probably not worth digging into these more nebulous things. Going to cross it off from the ticket.

[andreadelrio]

Updated ticket to reflect what was covered by PR #2417

[snide]

I've updated the above list with some new items as we look into a grouped nav

[thompsongl]

Tab order in the nav list is backwards of what it should be. It starts from the bottom of the nav and moves it's way up. Likely it should be the opposite.

Not sure who added this or when, but this is no longer what happens. Now, when the navDrawer is first focused, the expand/collapse button gains focus. Tabbing then moves to the lock/unlock button (if applicable). Subsequent tabbing moves through the nav items from top to bottom.

Can this task be marked as resolved? If not, how should it be updated?

[snide]

@thompsongl I think it's safe to checkoff for now. We can always add it back as we iterate.

[myasonik]

I want to bring up again the item that I crossed off earlier.

In short, I want to put the expand/collapse button back in their visual tab order.

We crossed it off because we were expecting a nav redo so we were just tabling the discussion. Designs for that new nav are now available so I think we can hash out a good way forward.

With the new planned nav, with only a small handful of items to tab through, I think the cost of the moving focus so drastically for outweighs the benefit of not having to tab through the same list twice.

[thompsongl]

All of the "pin to top" buttons should have aria-pressed=true|false defined on them to communicate their state.

This is something that needs to be done in the consuming application. Currently, what is seen as "pin to top" is an implementation decision in the EUI docs for what EUI regards as an arbitrary extra action button. That "extra action" isn't necessarily a toggle, and there isn't any real mechanism to make it so (onClick is a generic action).
As of now, Kibana does not use this extra action in any way, toggle or not.

[thompsongl]

The dock/undock button doesn't show up in a screen reader's rotor when the nav is expanded. (Should work the same as the "pin to top" buttons which do show up.)

This appears to be fixed (MacOS, VoiceOver, Chrome). Shows up in the Form Controls rotor menu as "Dock navigation [selected] toggle button"

[myasonik]

Awesome, I marked those completed and can make sure things get implemented correctly in the upcoming nav revamp in Kibana.

[thompsongl]

This ticket is pretty much resolved. I think we could close and track the remaining feature request (skip-to-content link component) in its own ticket: #2356

[snide]

Sounds good to me.