Indent/outdent on tab (list, code) #56474
Conversation
|
Size Change: +631 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in df81bbf. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6969602242
|
|
With the current developments on editor DOM form @jeryj 's work on block top toolbar shift tab has been considered a still needed way to navigate from content to editor UI - particularly when the toolbar is floating because of visual proximity. Considering the deep discussions in previous PRs about shift tab it may be good to decouple tab to indent from shift tab to outdent in separate PRs because one of them (tab to indent) is probable to land easier. |
|
@draganescu I don't get why it's still needed? It's the same problem as trunk? Can you share links? |
draganescu
added
Needs Accessibility Feedback
|
In previous discussions such as this one the shift tab shortcut to block toolbar was meant to be removed but it was persisted because of various arguments the most powerful one being that floating UI is the closest to the current selection so shift tab would intuitively move focus to the closest previous UI. However, this PR - a thing which I missed on my previous comment - removes the entire tab based navigation of the block editor UI unless the navigation mode is on or the This direction is "releasing" tab and shift tab to act as they normally do in text editing contexts and there is no need for 2 PRs like I previously suggested. |
|
Let's not rush into this please. This is going to receive A11Y pushback because of the following.
I really do want to achieve this goal at some point but people just need to be patient. We're trying to unravel editor accessibility from the beginning of Gutenberg so we need to be smart about how we go about it. A compromise for now could be adding it to the command pallet. CC: @afercia @joedolson @jeryj. For now, this might be worth discovering with the top toolbar setting but otherwise, I think this is the wrong time to introduce this across all modes. I can only imagine how many E2E edits were also required. @ellatrix This actually might be a perfect time to revisit region navigation. Both you and I tried but never were able to land a complete solution. You added more regions so that way you could jump to the block toolbar and I suggested a PR that would add some code to find the first tabbable in a region and focus it. Simply placing focus on a region makes a Windows screen reader read the entire region which is why I attempted my fix and did not want to move forward with yours. The reason why my fix was ultimately rejected is because the focus indicators broke around the regions as focus was placed on the first item inside the region, not the region itself. That might be a way forward.
My point, there's still a lot to think through. 😞 |
I've gotten used to it now, even though I don't use it often, I do remember it in muscle memory. That said, I'd love it if Escaping to navigation move would preserve the toolbar so that shortcut can be used additionally. Probably for a separate PR though.
I'm not following here. Since Tab is not used for navigation, why should Shift+Tab be? We're in a different content here.
This applies to all blocks. Tab is not used of navigation for consistency, and used for input if relevant.
Ok, so Esc will open the List View? If not, maybe we could use Esc then to exit the canvas and focus the toolbar. Maybe the toolbar (or a button inside) could be used to Enter the canvas. Just thinking out loud here.
Not too many actually. There were just 11 cases where I had to replace Shift+Tab with Alt+F10.
I can try that. So include the toolbar as a region, change focus to first item, while keeping the highlighting of the region? That should be possible. |
|
I included the block toolbar as a region in #56560. We can look at focusing the first element in a follow-up? |
|
@ellatrix while testing this I noticed that tab indents list items indifferent of where the cursor is in the text. Is this intentional? Shouldn't the indent happen only when the cursor is at the start of the line? |
|
@draganescu That's intentional and how it works in most editors. :) |
|
@ellatrix I recorded this comparison of Google Docs, MS Word, Textedit and Gutenberg on this branch. tab-indent-comparison.mp4The common thread on most editors is that pressing tab in the middle of a list item inserts a TAB char, it does not indent. As a separate note, in text editors pressing tab again after indent, indents again, but that would require us to create empty LI elements I guess and it doesn't look useful. |
|
Note: I spent the day using this and thinking about it. Here's my essay 🙈 Don't feel like everything needs responded to. This is more of a public thinking-out-loud.
I think this would be possible with how the Block Toolbar and Breadcrumbs (Navigation Mode Block Popover) are being split out at #56335.
This is a really big mental model shift for me. I love how simple of an idea it is as well. I am concerned about educating people that you can't Tab out of the editor, since it has been a way of navigating before. Could we detect if someone is pressing Tab repeatedly with no editing effect, and offer an educational popup to teach them about Alt + F10, region navigation, or pressing Escape to use Tab to navigate? Some thinking out loud/Notes from trying this outIf I can enter into the content using Tab, I expect to be able to exit the content using Tab. It feels like a focus trap if I can't exit using Tab. This is where an educational alert would be useful to tell me what to do, since it's diverging from the norm I'd expect on the web. To address that, we could turn on Navigation mode when tabbing into the editor so you have to choose to enter editing mode. Then I have to escape to leave editing mode since I chose to enter it, but, in practice that feels clunky. I'd rather get dropped back to the editor in the same place I was. I don't want to have to Tab through all the blocks, then press enter, then arrow over to my previous location.
The above idea won't work, since an arrow up on a paragraph block moves the cursor to the next paragraph in the same location. As it should. Maybe we can codify it as, "If Tab/Shift+Tab is not in use by the block, then allow it to function natively." I'm not sure if I'm hesitant to remove it because I'm so used to using Tab in this way, or if it's because it is a better experience to preserve it. If Tab and Shift + Tab are still useful in many instances of the editor to navigate, do we need to remove it entirely to have indent/outdent on list and code blocks? Or is the inconsistency in Tab usage OK? If I had to decide right now, I'd say that keys useful to the editor in editing context should "win" over all else. After all, it is an editor. So, I feel comfortable with the inconsistency of, "If Tab/Shift+Tab is not in use by the block, then allow it to function natively." This would impact:
Well… That's starting to be a lot of blocks, and as paragraph is the most common, it's going to be the default for Tab to not function. At that point, maybe it is better to remove Tab in editing mode entirely to encourage people towards learning a more consistent keyboard navigation... I'm concerned by the learning curve though, but a nudge to educate when tab or shift tab is pressed repeatedly would be really helpful. I'm going to keep using this and thinking through it. I'm very undecided on how I feel about it at the moment. I'm excited about the possibility of opening up shift + tab and tab to be used in the editor. I think that's a really important thing that needs to happen. So far, this idea to remove Tab as a navigation for the editing context does feel like the best way forwards. |
|
This was already discussed at length years ago at the time of the first implementation of the List block. It received a 'no-go' for accessibility reasons. Tab and Shift+Tab should be reserved for navigation, as the WordPress Editor is not Google Docs. Why this gets repurposed now? It's still a no-go for accessibility, as also noted in the related issue. |
|
Aside:
I'm not sure I'd agree on these two points. Will comment on the related PRs. |
|
@draganescu It does indent from anywhere for TinyMCE (and thus the classic editor), CKEditor, Draftjs, Apple Notes and Pages. I'd say it's the common behaviour whenever inserting a literal tab character is not allowed. |
Yes, that's a good point. To me, ideally, it behaves like a modal or dialog where you explicitly
This could work in navigation mode: arrow keys navigate blocks in 2d, and tab goes outside the editor. |
|
@afercia Tab has always worked to indent in the classic editor. Why can't we just see the canvas as an area that you enter and exit where tab behaves differently? What's the problem with that? That fixed the tab being reserved issue to me. If you had a code editor on the web, you'd need a similar thing since you really do need tab. |
|
@afercia it's resurfaced because what we have clearly is not working. We cannot be the odd one out that refrains to implement what is an expected experience across virtually all rich text editors for indenting lists. The current shortcuts with space and backspace are not growing familiar—and they won't be—since people are constantly trained by other experiences on the web and apps. It doesn't really matter that the editor is not Google Docs. So we are back at figuring out how to bring this in the best possible way. Given the top toolbar situation, it might be time to look at adding a preference for a user-configurable shortcut to access the toolbar given it's proven hard to come up with something that works for everyone under all circumstances. It might also be a way to get rolling on allowing customization of other keyboard shortcuts, which has not caught traction before. |
That's what I was thinking too when I was testing it out. That part does feel nice to explicitly Enter into editing then escape to exit. To make that a consistent pattern, I think it would end up being a worse experience though. For example, on a new post we couldn't place focus on the title in editing mode since it would break the explicit enter/exit model. Also, we can exit the editor region shortcuts, alt + f10, etc. To make it consistent, we might have to switch to navigation mode anytime focus is outside the editor. It's really nice being able to return the text caret to the same spot in the editor when focus is sent to it rather than focusing the block in navigation mode, having to press enter, move the caret back in place, etc... So, while I 100% agree that the enter to edit and escape to exit idea feels like a good technically accessible solution, I'm worried about the overall UX impacts it that would make it worse for everyone. I'd prefer leaving it as inconsistent in terms of entering/exiting so we can keep the UX improvements, but have the educational popup when we suspect someone needs help navigating via keyboard.
Ah, so Navigation mode becomes one tabstop and arrow keys to navigate. That sounds like a good change! Potential way forwards?I do still like the idea of in the editor canvas Tab/Shift+Tab being an editor-first level key and navigation secondary. So, if the Tab keypress can be used for editing (indent/outdent/insert tab space) then it is. If it can't be, then it functions for navigation. It's when my tab keypresses don't do anything that it feels broken. If I'm pressing Tab within a paragraph and I see it insert a Tab character, I understand it's doing something, even if it's not doing what I want. If that was the case, I'd try to navigate a different way or move to a different mode. If we detect the keypresses aren't doing anything, such as when trying to repeatedly indent a list that is already indented as far as it can go, we show the navigation helper notification. |
Right, if you use Alt+F10 to access the toolbar, you shouldn't leave the editing mode.
There's a risk of getting trapped in a block that uses Tab completely, like Code and probably List as well. If people only use Tab and there's no other obvious solution, you're stuck. I also really don't like the inconsistency. You can press Shift+Tab to access the toolbar in a paragraph and not in a list? That's strange and feels broken. We can for sure log a notice or something when you try pressing Tab elsewhere. And maybe also if you press tab, and then undo it (high chance it wasn't what's intended). |
Yeah, I totally agree. I was hoping it would feel less broken since Shift+Tab at least operates for navigation in most scenarios and Tab would be functional, even if it doesn't do what you want it to. For me, pressing Tab and seeing it do something feels less broken than if I press Tab and don't have any indication it was pressed. Having something happen allows my brain to skip the thoughts of, "Is my Tab key broken or is my keypress being registered?" The Tab + Undo or Tab + Backspace to show a notice is a great idea. Admittedly not ideal, but the times where Shift + Tab it is an issue is pretty limited and has a few fallbacks/hopefully easily discoverable ways out? I'm not sure though. It might feel totally broken in practice. Alternative DOM restructure ideaPossibly a bad idea and sweeping a larger issue under the rug... but what if we moved the editor to be the last spot in the DOM? Tab to move past it would be less necessary, and shift + tab could always move you backwards. I know Tab should cycle you back to the beginning of the page though, so you would have to enter into navigation mode to move to the beginning of the page again. This would mean shift+tab would always be reserved for navigation, so list interactions would be Tab indent and Delete to outdent. The default DOM structure would look like:
Again, not committed to this DOM restructure idea because it feels quite hacky. Maybe it would make the lack of Tab forwards in edit mode less of a problem? Trying to throw out some ideas. Maybe it'll lead to a better one 😅 |
|
Thanks for all the feedback and discussion. I'm at AWS re:Invent this week so thoughts may be delayed.
No, don't do this. I'm not sure we should change native keyboard behavior. Delete key should delete forwards text. Tab/Shift+Tab make sense for indenting and outdenting. Problems to solve:
I agree Tab/Shift+Tab need to be freed up keys, I'm just not sure how to accomplish it. Region navigation is not good enough because you could move to the sidebar and then back to editor content, but how would we communicate moving focus back to the block? For apps like Slack and Microsoft Teams both desktop client and web, the F6 shortcut key is used to move focus around different regions but focus actually gets placed inside the region, not just placing focus on a One thing is for sure, we all need to be open to exploring other ideas because I too would like to see Tab/Shift+Tab for the code block and other blocks that could benefit. |
|
If it's a given that Tab/Shift + Tab need to be freed up for use in Edit mode, and Tab/Shift + Tab not have mixed usage, then this PR accomplishes that. I'll stop throwing out ideas around mixed usage :) The issue with removing the Tab for navigation is that it's a keyboard trap in edit mode since you can navigate in with Tab, but not navigate out with Tab. This is a keyboard trap, but it looks like a notification is an acceptable alternative in a situation like this.
So, would providing the notification on how to navigate away should allow us to meet this criteria of "user is advised of a method for moving focus away? We can surface notifications for:
This interaction will probably feel broken to all of us who commonly use a keyboard for Gutenberg, but I imagine it'll get better as we modify our workflows. I don't see any alternative, and I'd rather change my keyboard habit and have a tab keypress function as an editor key. |
We can't because those are two very different cases.
What I expect in the editor is to just be able to use the Tab key for its native purpose: navigating the UI. This was already discussed at length years ago. Honestly, I'm not sure I understand why we're discussing again these points. I'd agree with almost everything @alexstine said above, with one difference:
I think your idea of 'expected experience' is a little biased and actually depends on the fact your keeping into consideration only a group of users. Instead, we need to design user interfaces that work for everyone. Keyboard users would be highly impacted by the change in this PR. Things would get worse for a group of users and I wouldn't call this the 'expected experience'. That said, since I don't want to block exploration of a better solution, I'd like to propose an option that could work for everyone. Similarly to what Google Docs does:
I'd like to invite you to test this behavior on Google Docs. Animated GIF to illustrate:
|
|
On this point:
@mtias I would like to remind you that the WordPress accessibility team asked for this feature long time ago and created a dedicated issue on October 28, 2017, see #3218. That was never prioritized. I'm glad to see that after more than 6 years allowing keyboard shortcuts customization will maybe get more attention. |
|
@afercia I agree, the selection and then Tab/Shift+Tab to indent outdent seems perfectly reasonable. One question. If you want Tab/Shift+Tab to become navigation keys, how does Shift+Tab move backwards if it always had to focus the block toolbar? For example, in a table block where each cell is editable, Shift+Tab could only go to the toolbar, not navigate cells. It makes total sense why you want to keep Shift+Tab to navigate to the toolbar but I keep trying to get around other keyboard impacts and it isn't easy. Arrow keys should not navigate fields, Tab/Shift+Tab should. We're kind of at a cross-roads in SPA accessibility as a whole. Sites like Google Gmail are forcing users to not use screen reader virtual mode and remember all their shortcuts so that JS can customize the experience around their site. In Gutenberg, we're almost doing this with the acception of still having some fairly semantic layouts. I've always long said that keyboard users are going to be in a world of hurt if each website requires very different shortcuts and it seems like we're hurtling towards that direction, not slowing down. For this PR, I think it is totally reasonable to require highlighting for the indent/outdent. We'll continue to try to figure the rest out as we go. Thanks. |
I disagree. The multiple contenteditable thing is just an implementation detail. Doesn't have anything to do with this. In TinyMCE each "block" also has its own buttons, while just like TinyMCE we have buttons that are shared between similar content. |
I don't think it's a good solution. People are used to be able to use Tab to indent in a list without selecting anything. That's the point of this PR: to restore that what people are used to. It's also again making things inconsistent. If I happen to be at the start of a list item or I have some text selected, Tab will indent the list and if I happen to be elsewhere it will navigate away? It doesn't make sense to me. |
Thing is, when you have one large content editable the semantics really disappear. So yeah, it is much different. Each block has a totally different interaction model from a keyboard perspective and this is why you can't compare it to a single editing canvas like TinyMCE. It may look the same visually but the technical happenings behind the scenes are different enough. I agree this isn't the best solution but until the larger problems are fixed, highlight is as good as we're going to get. I don't see us all coming to agreement in this PR about how to remove Shift+Tab/Tab functionality for navigation. It will be required one of these days because eventually we're going to run out of work-arounds. |
|
Let's close this since we have #59199. |
What?
Allows indenting/outdenting list items through tab/shift+tab.
Why?
See #45404.
How?
This PR removes tabbing from the editor when in writing mode.
keepCaretInsideBlockis on and disables custom tab behaviour in blocks.Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast