Skip to content
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

tabbing out of the mobile sidebar should collapse the sidebar? #1737

Open
drammock opened this issue Mar 11, 2024 · 3 comments
Open

tabbing out of the mobile sidebar should collapse the sidebar? #1737

drammock opened this issue Mar 11, 2024 · 3 comments
Assignees
Labels
tag: accessibility Issues related to accessibility issues or efforts

Comments

@drammock
Copy link
Collaborator

When reviewing #1736 I noticed an odd interaction: keyboard navigation through the mobile sidebar eventually gets you to the "ReadTheDocs Ethical ads", then tabbing further will focus the first landmark on the main page --- but the main page is still (partly) obscured by the slide-out sidebar and by the dimming layer over the part of the main page that is still visible. Moreover, once focus is on a main-page landmark, pushing Esc no longer works to collapse the sidebar.

Is there an a11y / WCAG standard for how to handle overlays / slideout menus?
My instinct is that the sidebar should automatically collapse when tabbing beyond its last element... but that could be a bit annoying because if you accidentally overshot, you couldn't immediately Shift+Tab to "go backwards" to where you just were --- you would have to start over at the hamburger menu to tab through to the items in the sidebar again.

Another possibility would be to have tab focus loop back to the beginning of the sidebar, such that the only way to get "out" of the sidebar would be to hit Enter (follow a link) or hit Esc (send the "close sidebar" command). Again: if there's an industry standard we should just do that. If not, folks can weigh in on these two ideas and/or suggest better alternatives.

@gabalafou
Copy link
Collaborator

I think one could argue that our mobile sidebars are a form of modal dialog. If so, then we should probably follow that pattern, which states: Tab and Shift + Tab do not move focus outside the dialog.

This is what we find (at narrow width) at https://inclusive.microsoft.design and https://support.google.com/accessibility.

For https://w3.org/wai, we get something that's more like a disclosure widget, rather than a modal.

I think the VS Code Docs have a pretty interesting way of handling section and page navigation, but it's pretty different from the path we've chosen.

My vote: let's follow the pattern at Microsoft Inclusive Design and Google Support Accessibility.

@drammock
Copy link
Collaborator Author

I think one could argue that our mobile sidebars are a form of modal dialog. If so, then we should probably follow that pattern, which states: Tab and Shift + Tab do not move focus outside the dialog.

What happens at the end? Does focus cycle back to the first element in the sidebar?

@trallard
Copy link
Collaborator

trallard commented Mar 14, 2024

It seems both of these follow the modal-like pattern where one tabs through all the items then tabs to the x or Close button. Which seems to be the general recommendation I have also seen for modals.

So for PST it would mean adding an equivalent close button/component.
Edit: I did not check if pressing Esc exits the sidebar in the examples above but that is I believe also the default for modals.

@trallard trallard added the tag: accessibility Issues related to accessibility issues or efforts label Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tag: accessibility Issues related to accessibility issues or efforts
Projects
None yet
Development

No branches or pull requests

3 participants