Fix region navigation in the post and site editor

[afercia]

Description

Follow-up to #46525 and #45369

After recent changes, the navigate regions functionality and its focus style don't work well in the post editor and site editor.

1
#46525 partially reverted #45369 moving back to a a focus style that is based on a CSS pseudo element. This approach has already been tried long time ago and it turned out it doesn't work well because the pseudo element on the content section scrolls together with the content itself. We need a different approach. For more details, please see this comment: #46525 (comment)

2
In the post editor, the 'Open publish panel' and 'Open document settings' regions, when they only contain the toggle buttons (i.e. when the sidebar is closed) still show a focus style even when focus is actually on the button. In the screenshots below, the button is focused. However, the small regions around the buttons show a focus style:

This happens only in the post editor. In the site editor it works as expected. Screenshot:

3
In the post editor, the Publish panel always shows a focus style when navigating through the regions, even when the actual focused region is another one. In the screenshot below the top bar is the focused region but the Publish sidebar still shows a focus style:

4
In the Site editor, the keyboard shortcut to navigate through the regions doesn't work well in browse mode when the Navigation sidebar is open. In this view, there are only two regions: the sidebar and the content. Turns out the sidebar region (the element with aria-label="Navigation sidebar" role="region") is actually hidden with visibility: hidden. This comes from the custom-scrollbars-on-hover mixin. Only on :hover and :focus this element gets visibility: visible. As a consequence:

• The navigate region functionality fails because DOM focus cannot be set on hidden elements. Only when, by accident, the mouse pointer hovers the sidebar the functionality works as expected.
• Since this element is initially hidden, its ARIA role and label aren't exposed to assistive technologies. Worth reminding that from an accessibility perspective, visibility: hidden is equivalent to display: none. Screenshot from the Chrome dev tools > Accessibility tab, to illustrate the element is not exposed:

As a consequence, screen readers won't perceive this element as an ARIA landmark. Native landmarks navigation won't work. Screenshot from VoiceOver, where the Navigation sidebar is not listed amongst the available landmark. Only the <nav> element within the sidebar is listed. Notice the mouse pointer hovers the content area.

When hovering the sidebar the landmark gets visibility: visible and it gets exposed as a native ARIA landmark. In the screenshot below, notice the mouse pointer hovers the sidebar. VoiceOver now lists the Navigation sidebar amongst the available landmarks:

5
In the Site editor, the SiteHub component (the one with the 'Go back' link / Toggle navigation and Edit button) is placed outside of any editor landmarks. It's only contained by the main element. The navigate regions feature won't include this part of the UI in the navigable regions because it's not a 'region'. Ideally, SiteHub should be within the sidebar.

Step-by-step reproduction instructions

Post editor:

• Edit a post, make sure the post has some very long content.
• Scroll the page a few lines down
• Use the navigate region keyboard shortcut (Control + backtick on macOS) and focus the content region
• Observe the blue outline did scroll up and its bottom side is displayed in the middle of the page.
• Fully scroll the page to the bottom so that the content that was initially above the fold is now completely out of view
• Test again the navigate region focus style on the content region
• Observe there's no visible focus style at all (actually it's on the part of the content that is out of view).
• Close all the sidebars.
• Navigate through the regions to reach the 'Open document settings' small region at the bottom right.
• Press the Tab key to move focus to the button within the small region.
• Observe that while actual focus is on the button, the small region still shows a focus style.
• Same for the 'Open publish panel' small region.
• Click 'Open publish panel'. The Publish sidebar opens on the right.
• Navigate through the regions.
• Observe that while cycling through the editor regions, the Publish sidebar always shows a focus style, regatdles of whether it's actually focused or not.

Site editor:

• Go to the site editor.
• Make sure your mouse pointer is NOT hovering the navigation sidebar.
• Press the Tab key once to move focus to the WP logo link.
• Use the navigate region keyboard shortcut (Control + backtick on macOS).
• Observe that nothing happens.
• Mouve your mouse pointer and hover the sidebar. Any part of the sidebar except the SiteHub component is fine.
• Use the navigate region keyboard shortcut again.
• Observe that navigation through the regions now works as expected.
• Inspect the page HTML and check the SiteHub component is rendered outside of the navigation ARIA region and that it's not possible to navigate to it by using the navigate regions feature.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[youknowriad]

Thanks for creating the issue, I'll make sure to work on this and see how we can improve things. Unfortunately neither solution seem great so far. The stacker div solution used to cover UI elements if the parent divs had backgrounds (due to the z-index tweaks). I'll see if I can find a solution that works for all cases.

[youknowriad]

I tried to reproduce the scrolling issue but I'm failing so far? Are there any particular requirements aside long content?

Screen.Recording.2023-01-05.at.11.57.38.AM.mov

[afercia]

Looking back into this, I think only the points 2, 3, and 5 needs to be fixed. 1 and 4 have been fixed in other issues.

[afercia]

Noting that this is one more case of regression that reinforces the need for visual regression testing, see #46210

[afercia]

Points 2 and 3 regressed in #46525.