Escape moves focus to editor region when in select mode #62196
Conversation
|
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: +158 B (+0.01%) Total Size: 1.76 MB
ℹ️ View Unchanged
|
|
@MaggieCabrera Do you have any ideas on reworking the CSS for this? The 
This is the focus ring on the body, which will respond to |
|
@jeryj Why not just return false? I'm not seeing the value of Escape press going back to root level. Actually, I find this interaction created very challenging to understand.
I'm kind of unsure why you went down this path in the first place. Deselecting a block makes total sense on escape but I think you may have slightly over complicated the select/edit mode shortcut interaction. Enter should activate, I think you would have quite a challenge finding a UI where escape could also activate. Thanks. |
|
Okay, I think I may understand a bit more. You are reverting the change. I still don't understand why you are using escape to back all the way out though. If you press escape to switch to select mode, you could use the arrow keys to navigate. I do not think escape should focus the iFrame body ever, this would sound like focus loss to blind users using a screen reader. Not being able to see the focus ring would make the UX quite bad.
|
|
@alexstine The challenge I'm trying to solve is, where does focus go when we deselect a block? I was hoping that by using Escape to "back out" of the levels of nested blocks, it would make the path from nested block to root level clearer. And once you don't have any more blocks to select, the root level canvas was the best place I could find to clear selection without losing focus. Very open to ideas here! And thank you for reviewing this interaction! |
There was a problem hiding this comment.
Interesting exploration! I think for me, while testing it out, I'd expect the Escape key to effectively escape out of interacting within the editor canvas, rather than walk up the block hierarchy. So, when pressing Escape the second time from Edit mode to Select mode, I expected to move out of the editor canvas with no blocks selected at all.
Deselecting a block makes total sense on escape but I think you may have slightly over complicated the select/edit mode shortcut interaction.
To me this made it feel more complicated, too. Was walking through the block parent hierarchy something that folks have been wanting to be able to do via the Escape key?
The CSS we are trying to apply here is going to be hidden by any backgrounds of elements inside, check this: 
|
|
@andrewserong - I'm mostly trying to see how to make escape not feel like a focus loss when you press it in select mode. This is more of a bandage so you don't go so far away from where you are if you press escape. I would love if we could press escape from select mode and:
I'm not sure what to do here, so I'm playing around with ideas. Any recommendations are welcome! |
I'm trying to apply this it to the |
|
@jasmussen @richtabor, how do you feel about this interaction? Escape while in select mode will:
|
jeryj
added
[Type] Regression
|
This is feeling much nicer to me after the update and it going straight up to the editor canvas 👍. One question: when we back out up to the canvas, would users expect it to also switch back to edit mode, so we're kind of escaping out of the current mode of what we're doing? Essentially, if after hitting Escape the second time you then go to select a block, would you expect to be back in Edit mode again? I'm a little biased here in that I find the selection mode a bit confusing to use in general. Keen to hear what the designers think. Thanks again for digging in here! |
|
As a quick test, this works well. Perhaps separate, but the breadcrumb for selecting the document — the only way to deselect in trunk at the moment — is setting focus on the
|
I see what you mean. I tried it out, but this would be a heavier lift, as it looks like the editor gets set to navigation/select mode when you tab into it and nothing is selected. Basically, when I
Yeah, it takes a little to get the hang of, but it's especially useful to select nested blocks. It makes moving focus between blocks with a keyboard soooooo much faster. If you use it with List View open to see the structure of the blocks at the same time it will make more sense too. What made it click for me was thinking of the actions as Up/Down/In/Out instead of Up/Down/Right/Left.
I think that's a great idea. Let's do it on a follow-up. |
|
Follow-up for template footer click fix: #62290 |
|
@jeryj What if it followed a path like this?
Just so you can hear it, this is what it sounds like from a screen reader when we place focus on an iFrame wrapper.
I seriously think escape should simply switch to navigation mode and then do nothing after that. Placing focus on the wrapper offers no meaningful experience for blind users. There is no other place I could think of that would make more sense. Thanks. |
|
@alexstine Yeah, that announcement is a bad experience :/ The idea is to be able to clear block selection and begin from top again. But, if we clear block selection on the canvas, then we need a place to put focus that is actually useful. 🤔 |
|
@jeryj What about the title field? It would be the previous focusable. |
| // Float an outline on the top of the iframe to show focus on the canvas when pressing | ||
| // escape while in select mode. | ||
| &:focus::after { | ||
| @include selectedOutline(); | ||
| position: fixed; | ||
| } |
There was a problem hiding this comment.
Is this potentially too broad? I notice that in the post editor, if I have multiple blocks selected in the canvas, then the iframe outline is also rendered, which looks unexpected:
There was a problem hiding this comment.
Just gave this a re-test, and noticed a couple of subtle issues. Here's a video:
2024-06-05.16.44.44.mp4
In the video, when selecting multiple blocks in the iframed post editor, the overall canvas outline is displayed, which looks unexpected.
Then, if I go to editor preferences and enable the custom fields, which switches off the editor iframe, pressing Escape will still clear the block selection, but there's no longer an editor iframe to be focused, so it looks like there's eventually a focus loss from pressing escape. I noticed a similar issue in #62290 — I wonder if there should be a tab stop for the non-iframed post editor, too? 🤔
Please let me know if I missed something obvious in my testing, though, I'm not too familiar with the expected behaviour for the editor wrapper when it comes to focus 🙂
That was my first thought too, but it would work for the post editor since the site editor doesn't have a title area. I'm still looking for a better place to put focus. Maybe even adding something or possibly a way to have a better announcement like "Editor canvas"? @andrewserong Good catch on the multi-selection! Fixed and updated. The css selector is getting a little long, but it works :) Should work with both the iframe and div block editor now too. |
|
@alexstine - I'd never done this before, but I put an aria-label on the body element and it's testing pretty well on safari with voice over. It's announcing "Block Editor, group with [number] items" which does seem useful for knowing where you are after clearing block selection. I'll let you be the judge if it's actually useful in practice though :) |
|
@jeryj This does not work with NVDA on Windows with Firefox. I'm actually quite shocked this works with Voiceover. The same announcement I posted above is given. Placing focus on a wrapper and having it make sense to all users of screen readers is a non-starter. What if you simply return focus to the "Editor content" region? This might be better but I won't know until you try it. Thanks. |
|
@alexstine I've updated it to focus the editor content region. Code is sloppy. If this announcement works well for you, let me know and I'll try to get it working in a cleaner way. |
|
@jasmussen - Here's an update to the focus styles for after this PR is merged: #62881 |
An escape keypress previously toggled the state between editing and select mode. This returns the behavior to the previous implemenetation of Escape clearing block focus... eventually. Now escape will select the parent element all the way up until there are no more, at which point it clears block focus and focuses the body iframe (showing blue outline).
- moves selected-block-outline to base styles css so it can be used anywhere - renames the mixin to match mixin naming convention - moves editor canvas outline to block-canvas styles because it needs to work for both iframed and non-iframed versions of the editor - restyle to make canvas focus work for both iframe and non-iframed versions
…dle sending focus from canvas
jeryj
force-pushed
the
try/escape-to-select-parent
branch
from
ed018ef to
387ed23
Compare
|
Thank you for the work here! |
An escape keypress previously toggled the state between editing and select mode. This returns the behavior to the previous implementation of Escape clearing block focus. Now, when in select mode, escape focuses the editor region (showing the blue outline from region focus styles).
What?
Why?
How?
Clears block selection and focuses the region wrapper by:
Testing Instructions
Escape to focus canvas wrapper
Edge cases to also test
Region outline showing when you don't want it to
Navigating regions
Testing Instructions for Keyboard
Screenshots or screencast