-
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
Keyboard interaction: standardize the blocks behavior #2031
Comments
See also #552 for approaches. |
Re:
Yes! And we've also discussed a bit to keep ALT + F10 (which is suggested as an example in the ARIA Authoring Practices) but also use the new Cmd or Control suggested by @iseulde. See #552 (comment). Quoting myself 🙂
Re: the toolbars. I'd recommend to keep them as simple as possible and adhere to the interaction model described in the ARIA Authoring Practices. See https://www.w3.org/TR/wai-aria-practices/#toolbar Worth noting a potential problem in Gutenberg is that what we see as a single toolbar, it's actually made of multiple toolbar components: multiple |
Re: toolbars, see also #632 |
I'm starting to implement some of my ideas in try/2031-manual-focus though it is early days and I have so far broken far more things than I have fixed. I will update when I've got something worthwhile to try out which I hope to have in the next few days. So far I've been mostly removing things from the default tab cycle which does at least result in a lot quicker keyboard navigation. I can see that Embeds may be tricky to figure out because they add a lot of things to the default tab cycle which we probably don't want there. |
I have a WIP pull request at #2392 |
Marking with the high priority label to indicate it's an a11y priority. |
See also #2990 |
Extracting a little bit from #3016 which touches on this, and I'd like to add some mockups as well. See also #2983 (comment). The high level goal with keyboard interactions is that everything should be keyboardable. That serves as an umbrella goal, where two sub-goals are:
If we do it right, modes (as has been brought up by Andrea countless times) can help this. When using just the keyboard, you can quickly enter and exit modes, pick the block you want to edit and get going. On the flipside, if we do this wrong, it's unobvious how to edit even basic text, and interactions like selecting across paragraphs or moving up and down using the arrow-keys becomes obtuse and encumbered by having to make sure we are in the right mode. We want to avoid Vim, in other words. To be clear, both the modes, and the selection enhancements have to happen for the whole picture to form. Here's how it could workYou click "Add New" to write a post, same as you would any editor. You click the text field and start typing. You can select across paragraphs (see #3038), and you can arrow-key across paragraphs without losing your place (see #2990). You are in edit mode, and if you don't know what that is, it's fine. You can also press In navigation mode, the arrowkeys (or tab for forward, shift tab for backwards), advances the highlight. Press If you are in navigation mode (invoked with In navigation mode you can also hold shift and select downwards using arrow-keys, same as you can in text (pending #3038). In fact, the "multi select mode" is sort of the beginnings of navigation mode. In navigation mode you can also press Navigation mode can also be entered by mouse-clicking any of the movers, or the ellipsis, or mouse-selecting across blocks to invoke multi select. All these three interactions select blocks, which happens in navigation mode. Use cases
Pros and consIn my head, the above feels like it gives us the best of both the keyboard and the mouse world. It feels like it's a modern selection paradigm for a block-based editor. It feels like it has a lot of benefits and flexibility. The only concern I have, is whether it's discoverable or not, and whether you ever feel like the navigation mode becomes obtuse or cumbersome. I'd be worried if people accidentally entered navigation mode, and didn't know to press But perhaps that concern isn't valid, especially if Escape takes you right back to where you were? We already sort of have a navigation mode when you've multi selected blocks, and entering/exiting that mode doesn't feel like a problem. One benefit of having a navigation mode is that you can easily select arbitrary blocks by navigating between them, "checking" them by pressing Can it be done?The above is a suggestion, walking through the flow. It is a technically very difficult challenge, and so devs should chime in on the feasibility of the various interactions. Even if there's wide agreement that this flow is desirable, we should consider parsing microscopic action items into separate pieces and implement them one by one to make sure we do it right. "Focus hell" is a real thing, and I don't want to make it worse with the above. |
Trying to think the "Can it be done?" question. I'd say mostly, yes. Here are the points that require some clarifications from my end:
|
Yes, I think that'd work great. Say you have a paragraph and an image placeholder, and you press down from the paragraph, it would be great if the first button of the placeholder (upload) gets focus.
Can we sort of do what we do now? For example if you have a paragraph and a separator, press down from the paragraph to put "focus" on the separaotr. Right now you see the movers and ellipsis, which lets you (in the future) use shortcuts to access these, or press
No, you don't exit edit mode ever, with only the arrow keys. I think it would be good if we could visually show where your "cursor" is, even if the cursor is hidden. For example if you arrow down into an image, you get the resizing handles. I'm sure I can think of a visual style to give to blocks like the Separator, to indicate where the "cursor" is.
Even if it technically does the same as "Enter"? I know the caret position would probably reset, but perhaps that's fine?
Yes. I'd say we'd want for the user to almost always be in edit mode. The challenge here is making it clear how to enter navigation mode, and how to get back to edit mode again. |
Yes, that's the part that worries me, resetting the caret position |
The worry is that you lose your place, correct? Or is there a technical concern? |
I've just noticed that 58bd5f7 removed the In navigation mode, when tabbing through the blocks, the blocks need to be focusable of course. They also need to be labeled with an aria-label otherwise assistive technologies users will land on a focusable element and hear just a resounding silence. |
@jasmussen Yes yes, you lose your place, it's not easy to save "a position" and restore it back knowing the caret could be in a textarea, input, an editable, a button... |
I'd definitely agree 🙂 When in edit mode, navigation through contiguous editable blocks should work as close as possible to how a native textarea works. The challenge is about non-editable blocks.
As discussed during last Editor chat, maybe this would be easier if all the blocks always had 2 focusable containers: the outer one for navigation, the inner one for edit mode. For example, focusing the separator inner container should also allow to delete it with Backspace/Canc. Maybe this would also help reinforce the 2 modes paradigm and standardize the blocks. Would probably also make developers life easier because all the blocks would have consistent behaviors. To my understanding, editable blocks already have 2 focusable containers: the outer labeled one and the contenteditable one. In the screenshot below I've added some padding and border to highlight them: However, there's the need of a container that wraps all the block including the mover, the ellipsis menu and other controls. How it worked before 58bd5f7 – see #2934 – was ideal for navigation mode and should probably be revisited. Other blocks don't have the inner focusable container or they have mixed content of focusable and not focusable elements that would be difficult to handle. Maybe adding an inner focusable container to be used for Edit Mode and arrows navigation through blocks could help? Navigation mode: Tabbing > focus is moved through the outer containers Overall I really like the idea of having two modes. "Navigation mode" and "Edit mode" could also be visually communicated someway (see "The only concern I have, is whether it's discoverable or not") and also announced with
Mouse/touch users will click for sure. They click everything 🙂 Keyboard users would need to be informed about the two modes and documentation and communication is a very important point here. The paradigm "Enter" to edit and "Escape" to exit is pretty intuitive though. |
Right, I'm saying maybe it's okay to lose your place. But thinking about it, yeah maybe not. Perhaps we should go with Escape to enter navigation mode, Enter to go back to edit mode for now, and have only that. |
See #2934 (comment) and #2934 (comment). Having nested focusable items seems like a bad thing? |
As commented also on #2934 we should distinguish a bit. Things like: Instead, a focusable container that is part of the layout is a bit different. For example, in WordPress We could also use |
What's the latest progress on this issue? @iseulde @mcsf @youknowriad @aduth @jasmussen @afercia. Has anyone started implementing the different modes on a branch anywhere? |
A few questions about selecting non-contiguous blocks. I'll start with mouse questions because they require fewer changes at the moment, and it will give me a chance to get my head around what is being requested and how to best implement it: a) I I have made a multi-selection of continuous blocks, should Ctrl+Click on another block add that to the selection? If so, what would a Shift+Click do after that? Can we have multiple non-contiguous block selection ranges? |
@ephox-mogran good questions :)
I'd say from the last clicked one to the currently clicked one, preserving the previous selection. See for example how selecting checkboxes in the WP list tables work, although that's jQuery and it's a not so known feature. |
So I'm going to try a slightly different approach here. Let me know what you think of it. Basically, the idea is that I'll expand the redux state slightly to make
This would give enough information to focus both the blocks in navigation (wrapper) and edit (blockEdit) mode, and would allow any of the hard-coded find selectors for focusing within blocks code to be removed. I'm going to experiment with this, and see how spaghetti-like it gets. I'd like to keep mover and settings in there from the beginning, so that we could dispatch convenient actions to focus them immediately (based on keyboard shortcuts, perhaps), but I understand if you feel that's overkill for the time being, and we only need |
First part of an attempt at having a navigation mode and streamlining selected / focused state: #3195 . Far from finished. Did only include |
To add multi-selection, we would just need to listen to the target of the keydown event (or check the focus state), and if it is the block container, then ignore the need to do any edge calculations and just expand selections. This would complement #3038. Or should we just have a |
Question: will custom components added by plugins be required to have those? |
I'm not all that familiar with the extensibility of the WordPress UI, unfortunately. Can plugins do that? That's always the problem here. I feel there's a tension between handling focus in an orchestrated way (through redux state), and handling focus in a way that supports custom components that the application doesn't know about. We can just have two options like this PR, and assume that the rest of the components can be found by tabbing in the appropriate mode. So all they'd need is a tabindex the way that it currently works. |
Quoting a couple points from the (now closed) issue with first accessibility recommendations #297, so they don't get lost:
Not saying they should be implemented at all costs, mainly because many things have changed in the meantime. However, in my opinion they support the idea of navigation mode / edit mode experimented in #3195 Especially the point 3. is interesting to me: I'd consider to try to constrain tabbing within a block while in edit mode. Arrows would always let me navigate content through blocks. About the point 10, I'd leave that to the contenteditable experts here 🙂 |
Edit mode is next on my mockups list. I know we've dabbled in the discussions, but I think some detailed mockups might help. |
I'm going to close this issue and start a fresh new one to proceed with the navigation mode / edit mode experiment, see #3195. The accessibility team has identified a list of 10 high priority issues for version 1 and agreed with the Gutenberg team to mark them with the "merge proposal" milestone. |
Splitting this out from #1516
See also:
Unexpected reverse-tab behaviour #1934
Image block keyboard focus and tab order #1829
Improve the block multi-selection and keyboard interaction #1308
Currently, the Tab/focus behavior across the blocks is inconsistent. Some blocks (e.g. text) have 2 focusable containers, while other blocks (e.g. image) have just one focusable container. This is particularly noticeable when tabbing backwards, see #1934 for more details.
On the first type of blocks (e.g. text), Gutenberg automatically moves focus from the outer container to the inner container (the one with
contenteditable
). On the second type of blocks, there's only one focusable container and users are forced to tab through all the toolbar controls.This leads to an inconsistent experience for users and, I guess, to some complication codewise. Standardizing this behavior would improve usability and user experience. It would be great to also preserve quick navigation through blocks when tabbing.
What if all blocks had 2 focusable containers? This way, each container could have a different purpose, and expose different controls to users. However, at the same time there should be a mechanism to allow quickly tabbing through blocks with just one Tab press.
The outer container could be used for navigation through blocks, the inner container for editing the block.
On #1516 (comment), @jasmussen proposed a new flow to improve keyboard interaction and multiple selection that could be combined with two focusable containers:
tab when "hovered" sets focus on a checkboxWith some adjustments, this approach could serve both purposes. Interaction details still to lay out but I'd propose to give this some serious thinking 🙂
The text was updated successfully, but these errors were encountered: