-
Notifications
You must be signed in to change notification settings - Fork 843
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nav drawer a11y problems #2252
Comments
@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? |
Related to #1712 |
@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. |
Updated ticket to reflect what was covered by PR #2417 |
I've updated the above list with some new items as we look into a grouped nav |
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? |
@thompsongl I think it's safe to checkoff for now. We can always add it back as we iterate. |
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. |
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 ( |
This appears to be fixed (MacOS, VoiceOver, Chrome). Shows up in the Form Controls rotor menu as "Dock navigation [selected] toggle button" |
Awesome, I marked those completed and can make sure things get implemented correctly in the upcoming nav revamp in Kibana. |
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 |
Sounds good to me. |
Critical (imo):
EuiNavDrawer
a11y, pt. 1 #2643)nav
element (covered by Improve a11y in EuiNavDrawer #2417)EuiNavDrawer
focus management, flyout auto-close #2749)EuiNavDrawer
focus management, flyout auto-close #2749)Less so:
aria-pressed=true|false
defined on them to communicate their state.aria-pressed=true|false
defined to communicate state. This can replace therole=switch
andaria-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.
The text was updated successfully, but these errors were encountered: