tabbing out of the mobile sidebar should collapse the sidebar?

[drammock]

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]

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]

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]

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.

[gabalafou]

I came across this issue today while searching for another issue and I want to add some updates.

I think that #1942 address the main annoyance brought up originally in this issue, which was about being able to focus on some part of the page that was outside of the mobile sidebar. With 1942, that is no longer possible.

However, before closing this issue I want to address two other questions raised in discussion:

1. Should the tab key cycle back to the beginning when you get to the end of the sidebar?
2. Should we add a "x" close button to the sidebar?

For the first question, there is a bit of a contradiction between the modal dialog UX described by the ARIA patterns site and the behavior of the HTML dialog modal.

The native HTML modal (at least as implemented by Chrome) does not prevent the tab key from leaving the modal. Instead when the user gets to the end, it behaves like the last tab stop in the document. So instead of cycling back to the beginning of the sidebar, the tab key press at the end takes you up to your browser tabs, through some browser toolbar items, and then back into the sidebar.

My suggestion is that we let the native HTML dialog follow its default behavior, unless we get user feedback or other information that this causes an accessibility barrier.

Should I close this issue and open a new one for adding a close button to the sidebar? (Currently there are two ways to close the sidebar: pressing the escape key or clicking outside the sidebar on the dimmed out part of the web page.)

[drammock]

Should the tab key cycle back to the beginning when you get to the end of the sidebar?

The ARIA patterns UX that you linked to says

If focus is on the last tabbable element inside the dialog, [TAB] moves focus to the first tabbable element inside the dialog.

@gabalafou I'm curious why you suggest to follow what Chrome does rather than what is suggested by the ARIA site. I'm generally happy to defer to your expertise / more informed opinion, but in this case my initial instinct was "it should cycle back to the start" and the ARIA site says the same. Can you elaborate on why you disagree?

Should we add a "x" close button to the sidebar?

the same ARIA site says:

It is strongly recommended that the tab sequence of all dialogs include a visible element with role button that closes the dialog, such as a close icon or cancel button.

so +1 for an "X" close button.

[gabalafou]

@gabalafou I'm curious why you suggest to follow what Chrome does rather than what is suggested by the ARIA site.

Thanks for asking. Happy to elaborate.

Mostly it boils down to my strong preference to not muck with how the browser handles tab navigation because it quickly gets complicated. So I'm not sure that the cost-to-benefit ratio is there. We would have to start listening for tab key presses when the sidebar opens, then run a function with each tab press that detects if the user is at the end of the sidebar, and if so, find the first focusable element at the beginning of the sidebar (but careful! this is not trivial, especially to implement in a generic way), and then focus that element. The reason that finding the first focusable element is not trivial is that there is no browser function like node.getNextTabStop(). So in order to find the first focusable element, the JavaScript for the ARIA modal dialog example does a depth-first traversal of all descendant nodes of the dialog node, until it finds one that it can focus, but avoiding gotchas like, a node with node.tabIndex === -1 can be focussed (i.e., node === document.activeElement) but is not actually a tab stop. This seems like quite a lot to add and maintain, especially when we consider that the user already has three different methods to get back to the top of the sidebar: (1) by repeatedly pressing the tab key past the browser tabs and controls, (2) by pressing the escape key and reopening the sidebar, or (3) by shift-tabbing backwards. Yes, cycling the tab key is what the Google and Microsoft

Furthermore, to me, the WHATWG HTML standard seems pretty accessibility-aware, but there's nothing I can find in the dialog specification about looping the tab key. It could be an oversight, but it could also mean that they considered the accessibility implications. I would have to investigate. But let's assume it was an oversight. The dialog element is still fairly new. If the modal mode really should change the tab key behavior to cycle from the end to the beginning, then in a year, without us doing anything, the issue might be fixed.

I'm happy to close this issue and open two new ones, one for the tab key cycling, another for the "x" close button. I can add a caveat to the tab key cycling one about the complexity involved.

Also to be clear, we should definitively answer the question posed in the title of this issue: tabbing out of the mobile sidebar should collapse the sidebar?

To me, the answer to that question is no. There's no ARIA pattern for that. I haven't seen it on other sites. And my gut is that it could be considered an accessibility anti-pattern. The general idea is that context changes should be the result of explicit user input. A user won't necessarily know (if they are blind or low vision) that they are at the end of the sidebar when they press the tab key, so for it to just disappear would be an unexpected side effect of the tab key. So from my point of view, if the user opens the sidebar, it should not close until they explicitly close it, either by pressing the Esc key, clicking an "x" button, or clicking the dimmed area outside the sidebar.

[drammock]

Mostly it boils down to my strong preference to not muck with how the browser handles tab navigation because it quickly gets complicated. [...]

I'm convinced.

Also to be clear, we should definitively answer the question posed in the title of this issue: tabbing out of the mobile sidebar should collapse the sidebar? To me, the answer to that question is no. [...]

I'm now convinced of that too.

I do still lean toward including an "X" button that is the last element of the sidebar (in tab-order). But OK with me to have a separate discussion of that in a new issue. AFAIC we don't need a new issue to discuss the tab cycling because (I think?) I'm the only one who was asking for it.