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

Nav block Offcanvas toggle button should toggle and transfer focus #47008

Closed
getdave opened this issue Jan 10, 2023 · 5 comments
Closed

Nav block Offcanvas toggle button should toggle and transfer focus #47008

getdave opened this issue Jan 10, 2023 · 5 comments
Labels
[Block] Navigation Affects the Navigation Block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Experimental Experimental feature or API.

Comments

@getdave
Copy link
Contributor

getdave commented Jan 10, 2023

As reported in #46939 (comment) activation of the offcanvas using the button in the block toolbar doesn't transfer focus to the offcanvas panel which is the intent.

Moreover the button should be a toggle to communicate the open/closed status of the list view.

@getdave getdave added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Block] Navigation Affects the Navigation Block [Type] Experimental Experimental feature or API. labels Jan 10, 2023
@draganescu
Copy link
Contributor

I think we should remove this button. I think it's a superfluous addition for #42257 (comment), provides no extra value, and it is confusing.

@getdave
Copy link
Contributor Author

getdave commented Jan 12, 2023

@draganescu Did we remove the button in the end?

@alexstine
Copy link
Contributor

From what I gather, the navigation list view is always open. It is static in the inspector DOM sidebar. The button still needs to stay as it would serve as a quick focus jump for screen reader users and keyboard only users. Tabbing all the way down to the navigation list view is simply not practical. This part of the editor heavily relies on the different DOM events. For screen readers specifically, they need to stay in edit/focus mode so the application (us) can handle where focus should go. The quickest way however currently would be for screen reader users to force their mode to browse mode and manually navigate to the navigation list view. Then they must force their screen reader mode back to focus to interact with the tree grid. This is work we must do.

Question is, is it better to focus the section or the tree grid? Is it important for users to first understand which menu they are editing? Likely so. At least that moves them much closer.

Thanks.

@jasmussen
Copy link
Contributor

The button seems good to have, not only for transferring focus, but to open the inspector in case it's closed.

Focus could be on the first item as one option, as shown here with the focus ring around the "blog" menu item:

Screenshot 2023-01-13 at 11 04 49

Another option, depending on where focus needs to land, is to just show the focus ring around the panel itself:

Screenshot 2023-01-13 at 11 03 57

Yet another option is to have a region highlight through an animated border, like this codepen.

@draganescu
Copy link
Contributor

#47032 removed the button. Is this issue still relevant?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Navigation Affects the Navigation Block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Experimental Experimental feature or API.
Projects
None yet
Development

No branches or pull requests

6 participants