-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Preserve input focus on arrow key in navigable container #28614
Conversation
…ing focus on left and right arrow
Size Change: +24 B (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
@diegohaz knows more about this then me so I'll defer to Diego's feedback. I'm skeptical about this change, as mentioned on the related PR #25343. Arrow keys are supposed to be used for navigation between toolbar items, and I think it'd be unexpected when they suddenly don't do that, like when focus lands in an input. There's already the Template Part block, which has an input in a toolbar that doesn't work correctly. This PR results in the arrow keys being constrained to that input. This would also need to cover all the different varieties of Finally, we'd need to look at whether an input can be implemented as a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This issue has been discussed in a few places already, like in #23375 (comment), where a solution has been proposed. @adamziel started implementing it on #24021. But I think in the end we agreed on fixing this at the design level by using popovers instead of inline editing on toolbars.
The problem is that it's really tricky for keyboard and screen reader users to navigate within the toolbar (which requires arrow key navigation according to the WAI-ARIA recommendations) when there are text fields in it.
Description
Fixed issue spotted by @draganescu in PR #25343 .
Users can navigate in navigable-container using arrow keys. Nevertheless, this made it impossible to use arrow keys with inputs that are placed inside the navigable-container. The proposed solution is to check if an event-target is an input or textarea and if so then do not use mechanics of changing focus with arrow keys.
How has this been tested?
Tested manually. All e2e tests are working locally.
Types of changes
Bugfix
Checklist: