-
Notifications
You must be signed in to change notification settings - Fork 2k
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 sidebar: tab navigation not working on Firefox #43972
Comments
The issue is that the only controls inside the sidebar (except for the close button) are
Step 1 being required seems fine, but step 2 is a surprise given it's not how Safari/Chrome/Edge work. This causes a bug in Gutenberg's |
For whoever picks this one up, the sidebar lives in: https://github.com/automattic/wp-calypso/blob/HEAD/apps/full-site-editing/full-site-editing-plugin/wpcom-block-editor-nav-sidebar/src/components/nav-sidebar/index.tsx and the |
@andrewserong First, just want to clarify that I think this issue is about the tabbing, and not about the “clicking the dark background or pressing ESC should close the sidebar” as I verified that closing the sidebar in this way works properly in Chrome, Safari, and Firefox on my Mac. As @p-jackson mentioned in the comment above, the issue has to do with user preferences on a Mac. I did more digging on this. I verified that the tab problem exists in both Safari and Firefox on my Mac, and according to the SO link that Phillip posted, the issue is system and/or browser preferences for keyboard navigation in both Safari and Firefox on a Mac. Mac users must change their accessibility settings in order to take advantage of tab navigation. All the following is for user on a Mac:
My question now is: what problem are we trying to solve?
|
I agree we should consider this. But given it's the "default" setting in Firefox, I wonder how many users would know (and care)? Being able to tab through (what are ostensibly) navigable elements, I'd have thought, is a fairly basic feature of web browsing. Is there a good reason to have these disabled in the first place?
This might be "out there", but could we try forcing
Where Maybe there's a another way? |
Ah, yes @ramonjd , I tested that on both Firefox & Safari (just using any ole website that has buttons & links to see what is tabable) and all good! Buttons & Inputs get hit by tabbing, I will give that a go!!!! Thanks. |
@autumnfjeld I think this one is quite a subtle issue. One part is the slightly odd default behaviour in Safari and Firefox on Mac of not tabbing to links, and I think we probably want to respect the default behaviour where it makes sense. That said, personally I think you should be able to at least tab to the back button in the sidebar. But the issue that Phil describes (if I'm reading it correctly) is that in Firefox, if you start tabbing in the sidebar and keep on pressing the tab key, it'll actually end up tabbing through some of the elements in the right hand sidebar. But the tabbing should be constrained to just the sidebar without escaping that area. Here's a gif where you can see that eventually the buttons at the top of the UI are tabbed to, but because the sidebar should act like a modal, this shouldn't be allowed: |
But yes, +1 to @ramonjd's idea of using a click handler to force the |
Ah, sorry guys! I forgot one bit of info that I think speaks to your point @andrewserong When you turn the accessibility settings on for Firefox, the the tabbing works fine in Firefox, at least in my own tests. Thus I assume if we changed the |
Oh, @autumnfjeld one thing I forgot about when working on the nav sidebar locally, is that the feature is guarded behind both a filter and a config setting check (setting either will enable the feature) here: https://github.com/Automattic/wp-calypso/blob/master/apps/full-site-editing/full-site-editing-plugin/full-site-editing-plugin.php#L307 The way I've switched this feature on for local development is to set the The contents of my {
"config": {
"WPCOM_BLOCK_EDITOR_SIDEBAR": true
}
} Then, running |
Replying to your comment from #45240 (comment) I think I'm starting to agree. The "Mac way" of enabling tab key navigation for links affects every site on the web, not just our sidebar. This answer phrases it well: https://stackoverflow.com/a/49781088
cc @enriquesanchez who might have some ideas on how and whether we should tackle this |
Hi everyone! Folks who rely on keyboard navigation and/or assistive technology usually set their browsers and OS to work the way they need/prefer. We shouldn't change the sidebar's behavior or semantics to force what we think should be the right keyboard focus functionality. I also think we should avoid educating the user about this. The complexity needed to reliably detect the browser and OS would be too much, and then we wouldn't be able to know with certainty what the user's particular needs are. As for semantics, we should avoid changing the behavior of an Related to constraining tabbing to the sidebar, we should definitively do this. Losing focus can be very disorienting. But there should also be an obvious way to close it and get back to the element that toggled it. Last time I checked the sidebar had the
Please feel free to reach out if I can help with anything else. |
I agree that we're better leaving the semantics as they are i.e. using IMO the issue is that the
Interestingly the approach taken in this example is totally different from the one taken by |
@p-jackson Could you clarify what example you are referring to? |
@autumnfjeld This example here: https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html The HTML source is on that same page, and the JS source is here. Took me a while to decipher how it works, but it doesn't look like it makes assumptions about what sort of elements are focusable (unlike |
What are your thoughts here? Can we close this for now, or could we report our findings about withConstrainedTabbing over at Gutenberg? |
I don't think we should close. It still feels like a serious bug imo. We should report in Gutenberg, but it'd be a bug in the component library, not with anything the user can reproduce in vanilla GB so don't think it'll get much attention. |
@p-jackson Hi 👋 Do you think it is still relevant with the Nav unification being rolled out soon? This is how the new workflow would be https://d.pr/i/vitaeA |
@nerdysandy Does that mean that the in-editor sidebar is being removed as part of nav unification? My understanding was that the current in-editor sidebar would be replaced by a new one as part of full-site editing, as seen here pbAok1-1oJ-p2#comment-3154 |
Ah, I didn't know about that bit. In that case, we can leave it open :) |
This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels. |
Most of the a11y issues initially identified with the nav sidebar were fixed, and this was the last remaining one. It only happens on Mac FF. It's an issue with Gutenberg modals in general and a fix would come with tradeoffs e.g. one option is to use I think the proper solution to this is to replace our sidebar component with the one that's built into the site editor. That way we're tying our a11y fortunes to core. I originally implemented this wpcom specific nav sidebar and always assumed that eventually the component would be replaced by the GB component (which didn't exist at the time). |
When you open the nav sidebar in the editor, the sidebar should behave like a modal. So clicking the dark background or pressing ESC should close the sidebar, and also importantly, pressing tab should only focus elements within the sidebar.
This is working on Chrome, but isn't working in Firefox.
My guess is that the call to
.focus()
to initially set the focus inside the sidebar isn't working on FF.Part of #41298
The text was updated successfully, but these errors were encountered: