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

Must be possible to close the Nav block offcanvas list view #47009

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

Must be possible to close the Nav block offcanvas list view #47009

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

Comments

@getdave
Copy link
Contributor

getdave commented Jan 10, 2023

As reported in #46939 (comment) it must be possible to hide/close the list view for screen readers. Currently it is always open and it's impossible to close it.

@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
@scruffian scruffian self-assigned this Jan 10, 2023
@scruffian scruffian removed their assignment Jan 10, 2023
@draganescu
Copy link
Contributor

I don't think this is a valid issue. The list view is a panel in the inspector. Given it has options in a panel header more menu, it is not collapsible. We cannot hide just this panel. Moreover if this will be its own tab in the upcoming tabbed inspector experiment we can't and should not hide only one tab.

I think in the live testing the need to hide it came from the poorly functioning list view button in the navigation block's toolbar, which I think we should hide.

@getdave getdave added the Needs Accessibility Feedback Need input from accessibility label Jan 10, 2023
@getdave
Copy link
Contributor Author

getdave commented Jan 10, 2023

We'll probably need to ask Alex for more detail as this request came from his video as referenced in the Issue desc.

@alexstine
Copy link
Contributor

How do you propose keyboard users move back to the navigation block? If you are thinking shift+tab, wrong answer. It should be easy for users to navigate back and forth between the areas if this navigation list view is going to truly compliment the editing experience. Even a previous region shortcut is a bit overly complicated due to the need to still tab in to the block. There must be a better way.

@jasmussen
Copy link
Contributor

I understand the need to navigate from the inspector back to the block in question, especially since that's where you started. As I'm constantly working to improve my skill in this area, forgive me if I'm asking obvious questions. At the end of the inspector's tabbables there's a "Skip to the selected block" link. I.e. if you press Tab on a selected paragraph, you navigate to the top of the inspector, and about 12 tab-stops later, the skip link receives focus. Is that link not sufficient? And if not, would something similar work for the list view panel?

@getdave
Copy link
Contributor Author

getdave commented Jan 14, 2023

I wonder if each node could have a means to select the block from the list view? This could be hidden for visual users as (I think) it's easy enough for them to achieve this.

FYI currently block selection in the Nav list view is purposefully disabled to avoid the list view being replaced by the inspector controls for the block being selected (which would be an even larger focus / context issue).

If we need a means to jump to the block in the editor canvas then this seems like the only way forward. Happy to be told I'm wrong.

@alexstine
Copy link
Contributor

@getdave That likely is the best way without duplicating the skip to block button. I just wish we had a better region navigation system to handle this.

By the way, would there be any option to move the list view higher up in the DOM for the inspector sidebar? That way it is the first thing users tab to after entering the sidebar content, after the close and tab buttons? Might need a different issue.

@jasmussen The skip to block button is too far away. 11 tab stops is a bit much. Go by the rule of 3-5 because users likely expect a way back in each section. This could use an issue in general, duplicate skip to block for each sidebar section. Likely will not look great visually but the more content in the sidebar, may not hurt.

Thanks.

@getdave
Copy link
Contributor Author

getdave commented Jan 31, 2023

If #47608 lands then each block will have the ability to select the block in the canvas. Currently focus is transferred to the block in the canavs anyway due to the problems explained in #47607.

That is a wider problem that we can't solve until we create a new API for programmatically managing focus on different parts of the editor UI.

@getdave
Copy link
Contributor Author

getdave commented Jan 31, 2023

Back to the original Issue reported here. Ultimately now we have tabs for the Inspector controls, users of assitive tech can choose other tabs and no longer have to traverse the entire list view to reach the block's other controls (e.g. Styles/Settings).

Therefore I think it safe to close this one. Happy to be corrected if I'm wrong.

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). Needs Accessibility Feedback Need input from accessibility [Type] Experimental Experimental feature or API.
Projects
None yet
Development

No branches or pull requests

5 participants