-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Shift between edit & selection/navigation modes with Esc/Enter #4382
Comments
I'm not sure Escape should select or perform any action other than "canceling" whatever is in progress. It's counterintuitive, as Escape it's always used to abort/exit/cancel the current operation. This was also mentioned in the initial Accessibility recommendations see #297
I'd rather consider a two-steps process:
One of the biggest accessibility challenges in Gutenberg is that there are way too many UI controls "popping out" here and there in the interface. When navigating through the interface using only a keyboard or a screen reader, this multitude of controls makes very hard to understand where you are and what is happening. We've had a few assistive technologies users who just gave up while testing. Providing a "mode" that makes navigating through the interface way simpler would be great. I'd consider such a mode the only way to give keyboard and screen reader users a chance to be able to use Gutenberg. Also, as I've recommended in previous conversations, I'd strongly recommend to make this "mode" the default for keyboard users. When I've proposed the "Navigation mode", I meant just that: providing a way to quickly Tab through blocks and get just the blocks, without all the UI controls showing up. Think at that as sort of switching command/insert mode in VIM 🙂 For example, in a post with 20 blocks, I'd just want to be able to navigate through all the blocks with just 20 Tab presses. So about:
I'm not convinced about the above. When a block is selected at the block level (which I assume is an equivalent terminology to "Navigation mode") Tab should just navigate to the following bock. Shift+Tab should navigate to the previous one. |
Overall, this seems good. I have to say it's hard to judge until we get into prototype, but we can do that then. I really like the focus on writing flow, it's important to smooth out the flow of creating within Gutenberg. Right now it's got a few hitches and I think if you knew about this, it would ease those. My main point that swims around over this is how discoverable it is. Maybe this is where we expose in some NUX or some other tutorial method. However, I do wonder how we can expose this. I come back to Tips :) I would like us to consider the mobile experience in conjunction. I don't see it as a blocker, but it's a requirement that has also the same ease. |
Thanks so much for the detailed thoughts, Andrea, really appreciate it. Definitely a bunch of edges to smooth around when the popout UI shows up, and when it doesn't. Perhaps even reconsidering when it shows up in the first place, i.e. maybe it shows up only in edit mode. As we continue to refine we have to remember that all options are on the table. As is the option to use Space to select a block, like a checkbox. However I'd like to give a quick backgrounder on why the version mocked up in this thread makes sense to me as a simplified version.
I'm aware that Escape should always let you Escape ;) — but in a way this is still the case. When you are in edit mode, you escape to selection mode, but we have to set focus somewhere so your focus is still on the block you were just editing. If you press Escape again, you escape that selection too, but we still have to set focus somewhere, which is the editor canvas. It's like having two modals that you're closing/escaping one by one. I don't mean to be all Obi-Wan Kenobi "from a certain point of view" on this, but I'm just trying to clarify my thinking and why I don't think it's necessarily wrong to use Escape for this action. It's not that the action is to select the block you were editing, it's about escaping the deepest editing mode, to a higher level selection mode, and you can escape further up to the document level if you like. The chief benefit of this approach, as I see it is that it's not really a separate mode that could potentially be confusing to users, but it can potentially accomplish the same. The main downside is the lack of ability to select non-contiguous blocks. Going to the next level — a more explicit navigation mode as you describe — this is an option, but before we go there I'd love to see if the simpler approach can accomplish the same.
In the end it seems like the chief difference between navigation and selection mode is that in navigation mode, a block is focused, whereas in selection mode, a block is focused and selected. Is that correctly understood? |
Yes, please 🙂
Maybe I'd need to see it in action, and maybe it's just about a different terminology 🙂 Until now, "select" meant to me a block is being edited. I'd be OK when in navigation mode you land on a block, the block is also selected (meaning not in edit mode, just selected to be highlighted and expose higher level commands like move, delete, etc.). What I'm really interested in, it's to reduce the clutter keyboard users and assistive technologies users experience when navigating through blocks. So this navigation/selection mode should be the default for keyboard users. They should be able to Tab through 20 blocks with just 20 Tab presses. I'm OK if when tabbing to a block, it becomes also "selected" (highlighted). When landing on a block in this mode, no UI should be shown and no additional controls should be focusable. Just the block. The focused block wrapper should be the one with the aria-label that announces what the block is, for example: |
Focus and Selection mental model for GutenbergThe aim of this document is to clarify when a block has focus, what that means for the actions you take, and how that looks in mobile, desktop, and nested block environments. Top level: Canvas layerFor the purpose of this flow, let's assume you've just opened up an existing post full of different blocks, completely fresh. The editor canvas now has focus. If you instead had clicked "Add New" to write a fresh post, we'd set focus not on the canvas, but on the empty Title block at the top, putting you straight into the editing layer. When no blocks are selected or being edited, what you see is a preview using the stock Gutenberg stylesheet. Future iterations of Gutenberg might load the theme stylesheet instead. Canvas layer: Second level: Selection layerIf you start using the
A selected block has a blue selection background around the entire block. Same color as text being selected. One or more selected blocks can be deleted, cut, copied, or transformed. On a selected block, the block container itself has focus. The previous term for this has been "multi select". Selection layer, first block selected: Selection layer, second block selected: Third level: Editing layerIf you select a block with the keyboard and press Enter, or if you click a block with the mouse, you are now editing that block. For example:
When a block is being edited, it has a thin gray border surrounding the entire block. It may also have a quick toolbar, and the block might surface additional controls not shown in its unselected preview state. A block being edited has these qualities:
Editing layer, second block being edited: Nested blocksWe need to consider how arrowkey navigation affects nested blocks. Here are the two most obvious approaches. Option 1, arrow-key enters nested blocksAnimation showing a user pressing Option 2, arrow-key does not enter nested blocksIn this animation, a user presses This seems less desirable than option 1, but may be necessary for more complex block containers such as a columns block where cycling through first column 1, then column 2, then column 2 may not be sensible. Implications for complex or nested blocksFor blocks that have a single textfield:
For blocks that have multiple edit fields:
For blocks that have nested sub-blocks, like a list that has list items:
For complex blocks that have nested sub-blocks, such as a columns block:
|
CC: @afercia @iseulde @mtias @karmatosed @aduth, would appreciate your thoughts on the mental model for simplifying selection and focus as shown in #4382 (comment). |
I can see option 1 being more ideal for something like a product block. As you say it comes down to the usage, does a person need to navigate each element in a block or not. @jasmussen do you have an example of a block that might not want to navigate each element in a block? Have you considered Option 3: If you press FWIW I found this thread today when I discovered |
I honestly can't think of any, no. But keep in mind there would be two types of blocks here:
In the case of option 1, the suggestion in this thread is that arrow keys, at least, work for those (except for child blocks in option 2). In the case of option 2, the tab button should at least enter those elements.
This is actually what I imagine option 1 is, as mocked up above. I just didn't mockup the column option, but I imagine it would work as you describe. I think this is the most ideal, personally, as it also leverages the fact that the markup underneath is also vertically orientated.
Agree, this is not ideal, and is a result of us having to have a way to let users enter the formatting bar with just the keyboard. We explored a command key for doing this, but there were side effects that were hard to address. |
I think pulling out and highlighting focuses like this is beneficial and makes a lot of sense.
This feels more desirable for me also. |
Noting that this is being worked on in #5709. |
Note: it as also proposer to try a "global" switch using a keyboard shortcuts e.g. F7 (needs to be tested carefully to see if it conflicts with other shortcuts) |
Consolidating with #5694 |
The concept of this ticket has been discussed in various tickets and replies, most notably this one. An implementation of this has even been valiantly attemptedy by @ephox-mogran with some success in #3195.
One of the purposes of this is to make it easy select multiple blocks and move them around easily, using just the keyboard, but there are a number of other accessibility related benefits that this has the potential to give us.
Having simmered on how this could work for a while, here is a flow with mockups that has been tweaked based on discussions. It boils down to this:
This is different from the previously discussed proposal, which added a 3rd focus mode — a highlighted block that wasn't selected, but which could be selected by pressing Space. The new approach is simpler, but it also means you can't select non-contiguous blocks using just the keyboard (similarly to when you select text in an editor using just the keyboard).
Mockups
Focus is on the first paragraph:
User presses "Esc". Now the first paragraph is selected at the block level:
User pressed down arrow key and sets focus on the 2nd paragraph block, which is now selected. If the user had instead pressed Shift + down arrow, both the 1st and the 2nd block would've been selected.
User presses Enter, and edit focus is now on paragraph number 2:
The above flow changes nothing about what works today, but builds on it by adding a few features:
Use cases
Making lists
Start typing. Type out five paragraphs. Realize you meant to make a list. Shift+uparrow starts a selection. As soon as you cross the boundary between inline level and block level, you're effectively in "selection/navigation mode". Once you've selected all five paragraphs, you press tab three times (focus lands first on move down, then move up, then on ellipsis), then you press Space to open the ellipsis, then you tab down to the "convert to list" transformation.
Deleting blocks quickly
You wrote a draft before lunch. It's elaborate with lots of different blocks. Nothing has focus, so you are in selection/navigation mode, but no block is selected. You start using arrow keys, and because you are in selection/navigation mode, as soon as you press down the first time, the first block is selected. Then you arrow down until you're at the end of the block list. You realize the 2nd to last paragraph is superfluous. You arrow-key up to select it, then you press Delete to delete it. At no point did you use the mouse, or enter Edit mode.
Moving a sequence of blocks from one space to another using basic keyboard shortcuts
You wrote a draft after lunch, and decided that the lavish gallery you created and the little paragraph of text you wrote below it make for a great opener, and want to move it away from where it is. Your focus is on the text block below the gallery. You press Esc to select the text block, hold shift and press up arrow to add the gallery to the selection. Press ⌘X to cut it out of the flow. The block before the gallery is now selected, and you press the up-arrow until you're at the first block, then you press ⌘V to paste.
Other benefits of this approach
Other notes
⌘+Shift+Uparrow
for moving a block upwards one slot) work in either mode (except for Delete as mentioned under "benefits").For touch screens
Probably not a blocker for a first stab at this, but on mobile, a tap should always set focus on the text block. A longpress could select the block at the block level. Subsequent longpresses would then add to the selection.
Nested blocks
Nested blocks are coming (follow #428). For this feature, being able to quickly and easily select a block at the block level becomes still more important. The approach would be the same. Let's say you set focus inside a paragraph block nested inside a blockquote:
Press Esc to select this paragraph:
If you press the down arrow, you'd select the 2nd paragraph. If you pressed the down arrow twice, or the up arrow once, you'd select the entire blockquote itself:
Similarly, if you were in selection mode and arrow-keyed down from a paragraph block into a blockquote block, you'd first select at the parent level, subsequent down arrows would select nested paragraphs inside the blockquote.
Next steps
Is this a good approach? Does it feel intuitive? Would you like to see an animated mockup? Would this be hard to build? What are the accessibility implications? Let your thoughts be known.
CC: @mtias @karmatosed @afercia @ephox-mogran
The text was updated successfully, but these errors were encountered: