Site Editor: Navigation: evaluate best option for initial focus

[afercia]

Description

Related: #47730

From a user experience perspective, navigation in Single Page Applications (SPA) should emulate as much as possible the 'traditional' navigation mechanism (page load).

The Site Editor is basically a SPA that implements a routing mechanism. One of the problems with SPAs navigation is establishing where initial focus should be set after navigating to a new 'page'.

In the 'traditional' navigation experience, the browser loads a new page:

• initial focus is on the document root.
• The tab sequence starts from the document root.

In the Site Editor:

• Focus stays on the menu item that was activated.
• The tab sequence starts from the menu item that was activated.

I'm not sure this is ideal. to my knowledge, there are no best practices established though. Setting initial focus elsewhere would have pros and cons. Possible options:

• Force s focus loss by the means of some 'blur' effect so that the tab sequence starts from the document root. While this would replicate the 'traditional' navigation, intentionally triggering a focus loss seems risky to me.
• Set focus to a meaningful place e.g. the main element. Not sure that would be ideal. Could also trigger some page scrolling.
• Set focus to a focusable element at the top of the document. Not sure that would be ideal as well. What element would be the most appropriate? Should we add a dedicated, focusable, labelled, element for this> To me, sounds a bit hacky and would not replicate the 'traditional'. expected, behavior anyways.
• Don't do anything and keep focus on the menu item that was activated.

Thoughts and feedback from the accessibility team and everybody would be very welcome. Cc @alexstine @joedolson

Step-by-step reproduction instructions

• Go to the Site Editor.
• Navigate through the Templates and Template parts.
• Observe focus stays on the menu item that was activated.

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

[alexstine]

I honestly do not know what to do here because Gutenberg kind of breaks the practices of accessibility in every way imaginable. Some parts are improving, but the site editor is off in another dimention. I think I actually consulted on this functionality and decided at the time that this form of focus was better since the heading structure was too bad to reliably allow users to navigate to the newly revealed content from the top of the editor. Too be honest, the site editor is so far out of my scope right now, I have not messed with it. I think it is currently a lost cause given how quickly things are changing.

[joedolson]

I agree that this is tricky to set. If we view the template selection as navigation, then it should be moving the user somewhere. Setting focus to the top of the document root would be predictable, but not necessarily efficient for the user.

However, these selection controls are buttons, not links, so I think that they don't need to operate the same way a navigation link would.

I think that the expected usage of these buttons is to get a view of the template before moving to edit it, which has no value for a non-visual user; a non-visual user can only learn what the template is by going into it.

If focus is moved into the template on selection, that's probably irrelevant for sighted mouse users, who can still just click through everything else; beneficial for screen-reader users, who will move directly to the selected template for editing, and could go either way for sighted keyboard users, who may either want to be glancing through the templates or selecting one.

A compromise could be that selection works as it currently does: selecting the template, but not moving focus, and an edit button is added as the next tab stop that would move the user into the template. If the edit button was only present on the selected template, it doesn't add a lot of tab stops when navigating, and provides good proximity.

[joedolson]

It sounds like we're generally agreed that it would be helpful to be able to select a template, and then be offered a button that moves the user into the template to edit and explore. The button should only be present on the selected template. This would make it easier for users to jump to the editing pane using a keyboard.

[joedolson]

At this point, I think that Template navigation is working pretty much as described here: you select a template, it opens a panel of sub-templates, and the next tab stop is an Edit button to edit the template.

However, clicking on the "Edit" button then moves focus rather weirdly, sending it to (I think) the Options button. When 'Edit' is activated, focus should move - in my opinion - to the 'Open Navigation' button. This offers several benefits:

1. It allows the user to reopen the navigation panel and browse to other templates if this is not where they wanted to be.
2. It orients the user to know where the navigation can be found in the editing view
3. It places focus in a the more predictable top-left corner of the screen, so that tab order flows in a predictable sequence.