-
Notifications
You must be signed in to change notification settings - Fork 448
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
fix(core/form/inputs): fix issue with tabbing to popover toolbar buttons in PT-input #5057
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
No changes to documentation |
Component Testing Report Updated Jan 16, 2025 1:35 PM (UTC) ❌ Failed Tests (2) -- expand for details
|
1c5d6a8
to
517727f
Compare
517727f
to
c8914ae
Compare
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.
Thanks @skogsmaskin, this is a huge improvement.
Just had a look and noticed a few things:
- When pressing TAB for the first time over an annotation, it will try focus the next element briefly before then focusing buttons within the popover.
If you look at this video and pay attention to the 'No items' box, you'll see what I mean:
Screenflick.Movie.30.mp4
I'm very certain this is the case due to buttonRef.current.focus()
being wrapped within a setTimeout
. This does seem like a bit of a smell!
One possible alternative is that rather than focusing the button directly, we create an invisible anchor element (with tabIndex=-1
), and then on TAB:
- initially focus the anchor element. Since it has
tabIndex=-1
, it will be ignored in sequential keyboard navigation - the browser will then 'naturally' tab to the next button in the list
Here's an example video with that approach:
Screenflick.Movie.31.mp4
-
This popover doesn't trap focus – making it very easy to accidentally tab or shift-tab away completely out of the form. We should probably trap focus here.
-
Focus isn't restored when closing the popover – ideally, closing the popover with ESC returns you exactly where you were.
We could probably punt on 2 + 3, but should capture these if we do.
@skogsmaskin I'm assuming that this PR can be closed? 👀 |
3de982b
to
4987734
Compare
It is intentional from my side yes, so that you get back to editor again (which is probably what you want in 99% of cases). Closing the popover (ESC) will break out from the focus trap and let you move focus with tab normally. |
4987734
to
24e7206
Compare
24e7206
to
50ded22
Compare
50ded22
to
9c4e5ce
Compare
…able Text Input This will allow a user to purely use the keyboard when editing links and inline objects, which was not possible before.
… Portable Text Input
9c4e5ce
to
2d8b5d2
Compare
Okay, thanks for explaining! I just wanted to make sure it was on purposes. In that case, this looks good to me! |
Description
There is currently an issue with reaching the annotation and inline object edit toolbar buttons with the keyboard leaving annotation editing impossible with the keyboard.
This will make sure that when these toolbars shows, it will be possible to press
Tab
in order to get to the buttons with the keyboard.keyboard.navigation.mov
Also added component tests for this.
What to review
That you are able to tab into the buttons when the toolbar is showing.
Notes for release