Inserter: fix 'append-after' keyboard a11y in both modes #63298
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ellatrix
added
[Type] Bug
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: -3.7 kB (-0.21%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
ellatrix
commented
Jul 9, 2024
| <InsertionPoint | ||
| __unstableContentRef={ __unstableContentRef } | ||
| /> | ||
| ) } |
There was a problem hiding this comment.
Note that the order previously didn't matter here, it was available only to pointer devices.
Also note that the zoom-out inserters are actually right below this one now.
|
@alexstine Thanks for testing. I'll fix the e2e tests, it probably needs some updated snapshots etc. |
… events when hidden
afercia
added
[Feature] Inserter
|
@ellatrix thanks for this PR. I haven't looked at the code, just quickly tested the interaction. The inserter is added and reachable with the keyboard. I noticed something to address though. When I move the last block up, the new inserter seems 'attached' to it. When tabbing, it does appear after what previously was the last block, which is now in a new position though. Animated GIF to illustrate:
|
Could you elaborate on what's unexpected? I checked the GIF a few times, but I didn't see anything strange. The insertion point moves with the selected in edit mode, yes. It's similar to the block toolbar, which is also visible for the currently selected block. |
To me, this is unexpected. The whole point of this inserter is to provide keyboard users with the ability to add a block at the end of the canvas. If the inserter moves, they can't add a block at the end easily. |
They can add one at the end of the canvas through navigation mode, as it was the case before.
One idea that I'd like to try in a follow up PR is allow moving the inserter with arrow keys. So once you tab into it, you could navigate it up and down, and maybe even left to move it one block up. Maybe we can also make the home/end keys work or something to move it down the inner blocks list. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Fixes #61391.
Adds a tabbable inserter:
Why?
To make it easier to add a block after the selected block.
How?
The approach here is to leverage the "in-between" inserter. Instead of being accessible with pointer devices only, make it also keyboard accessible.
Testing Instructions
Testing Instructions for Keyboard
See above, this is a keyboard only fix.
Screenshots or screencast