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

Widget areas are difficult to navigate with keyboard only #38260

Open
tellthemachines opened this issue Jan 27, 2022 · 3 comments
Open

Widget areas are difficult to navigate with keyboard only #38260

tellthemachines opened this issue Jan 27, 2022 · 3 comments
Labels
[Feature] Widgets Screen The block-based screen that replaced widgets.php. [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Accessibility Feedback Need input from accessibility

Comments

@tellthemachines
Copy link
Contributor

Description

In the Widgets Editor, focusing on a widget area and then pressing Tab takes us to the Sidebar. In order to enter the widget area, we need to use the arrow keys, but that's not immediately clear, and there are no clues about it in the interface.

The widgets area doesn't have any sidebar settings, so transferring focus to the sidebar isn't as useful as it may be when a regular block is focused.

Also, if the "Contain text cursor inside block" preference is enabled, the arrow keys don't work for block navigation, so it's impossible to enter the widget area using the keyboard.

Step-by-step reproduction instructions

  1. Open the Widgets editor at wp-admin/widgets.php.
  2. Tab into the editor content and land on a widget area.
  3. Press Tab again and verify that focus is transferred to sidebar.

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

@tellthemachines tellthemachines added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Feature] Widgets Screen The block-based screen that replaced widgets.php. Needs Accessibility Feedback Need input from accessibility labels Jan 27, 2022
@joedolson
Copy link
Contributor

It seems to me that two separate issues are being grouped here: the first is a usability issue (the lack of helpful affordances to let users know that they need to use arrow keys); but the second is a pretty major accessibility issue. If a user has enabled the 'Contain text cursor inside block' option, and that option prevents them from navigating the widget area, that's a serious issue, and needs to be addressed. I think these should be broken into separate issues.

@noisysocks
Copy link
Member

Thanks for the issue. I suspect this is a side effect of us implementing the widget area using an internal "widget area" block. There's been some discussion in #33254 about whether that's the right approach.

@tellthemachines
Copy link
Contributor Author

The second issue is a side-effect of us using blocks for widget areas, but it's also not widgets-specific. When 'Contain text cursor inside block' is enabled, arrow keys can't be used to navigate between blocks at all. That's by design, but it means that to move between blocks we have to switch to Select mode.

I misstated the problem when I said it's impossible to enter the widget area; it's only impossible while in Edit mode. But a user with that preference enabled will likely be aware of that, as it's the same behaviour as with any container block with inner blocks. It might be worth looking into ways of making navigation between blocks easier, but there's no straightforward solution to the problem - that's why Select mode was created in the first place, after much discussion 😅 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Widgets Screen The block-based screen that replaced widgets.php. [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Accessibility Feedback Need input from accessibility
Projects
None yet
Development

No branches or pull requests

3 participants