-
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
Experimenting with navigation and edit modes #3195
Conversation
Nice experiment. Overall it seems like the gist of the idea is right. When you are typing or editing or interacting, which should be most of the time, you never see this. Pressing Esc enters navigation mode and you can arrow key across blocks. Enter should be same as a mouse click on the selected block, to enter edit mode again. So far so good. There are a couple of bugs and little things probably not worth mentioning since it's experimental (navigation mode exits if you press down at the end of the last block, enter on a placeholder block doesn't do the same as a click on it). We'll also want to make sure that the implementation can address the use cases suggested here. But from testing this branch as an incomplete prototype, I do very much get the feeling that this interaction method adds value! I would encourage @mtias, @karmatosed, @afercia and others to test this out. For full implementation, we'd likely want to wait for the docked toolbar, multi select improvements, and keyboard selection improvements to land in master and stabilize, so we have the right base ingredients to work with. |
Tested a bit and I also have the same feeling: this interaction model makes things predictable and easier for keyboard users. Enter/Escape are pretty intuitive, navigation works pretty nicely. I think also Tab should navigate through blocks. I've always imagined tabbing as the primary action for navigation. Tested a bit with Safari/VoiceOver and totally like the way blocks are announced in navigation mode (screen readers will read out the blocks |
A few more questions:
A few run-throughs
That's all for now. |
64d93cf
to
0b51c5a
Compare
0b51c5a
to
151293d
Compare
I've updated this WIP PR to have some basic tab navigation, and added some navigation for the
|
I've also moved across @jasmussen 's use cases into the description of the PR (as checkboxes). Feel free to add more behaviours that are required. |
Great question. It depends a little bit, and I would appreciate input from @afercia on this, but I imagined it could work like this:
Not sure what the best approach is.
A few options here, also depending on whether we let the tab button switch only between block manipulation options and not tab between blocks. It could just be part of the circle of block options — edit a block, tab through the options around it. It could not be tab accessible on its own at all, requiring either a direct shortcut like Ctrl + ⌘ + M or picking the "Insert After" option we've discussed adding to the ellipsis menu.
I would be, yes.
Again depends on whether we're okay with tab being only for the controls surrounding the selected or focused block, and having arrow keys be sufficient to navigate between blocks. If we're okay with this, tab will always go to these controls. I'm open here, but if we want tab to navigate through blocks, they should probably do this in both modes, and we should find a different way to access the ellipsis menu and movers from the keyboard. Would requiring direct shortcuts to access these (⌘+Shift+arrowkeys to move, something like ⌘+, for ellipsis) be okay?
Depends on the tabs vs. arrowkeys discussion, I would say.
Probably best to worry about this separately — there's a separate codemirror discussion going on, and I don't know how that handles tab — not in a great way I'm told.
I would suggest you deselect all. Let's say you've been writing something and you hate it. You Esc Esc, ⌘+A, Del to delete it all. Tab then sets focus on the title field and you can start fresh.
Deselect.
Once again a matter of tabs vs. arrowkeys. Good that you brought this up.
In a separate issue I suggested when an image block receives focus, the first button inside actually gets focus. However @afercia convinced me otherwise. I have on my todo list to give our placeholder blocks, as well as image blocks, some focus styles. So imagine an image block, or a placeholder, as being content same as anything else. When your cursor is in text, the text has focus. When your cursor is on an image block, the image block has focus. This will be helpful if you'd like to delete it — just press Del, or you can start to tab through its innards. But you need a focus style for the block for this. So, same behavior as is in master, in other words (when in edit mode). Was that helpful? |
Hey
I assume you mean this issue: #3142 (comment) My interpretation of that in light of this change was that focus for the block should always start at the outside container when in navigation mode (and not inside it arbitrarily on some button). However, if you were already in |
First off, you've been doing quite stellar work, and this is an exceptionally tricky task with lots of "we thinks" and "it feels like"'s. Given those circumstances, an applause is in order, thanks for working on this. 👏 Bear with us as we explore this togeter. It's okay, perhaps even best, to implement this stuff in phases, so we can learn and steer along the way.
Yes.
Right. To try and put it as simply as possible — navigation mode never involves the text caret/cursor. No block actually has "focus" in the traditional sense — they have a navigation mode specific focus, right now you've highlighted this with the 2px blue border. All good 👍 👍 In Edit mode, it's all about the more classic focus. That is — when you see the text caret it's because you're typing, and the paragraph has focus. When you click an image that's inserted, you see the resizing handles — the image has focus. What I meant to imply with placeholder block focus, was that — just like we have a button focus outline, perhaps the placeholder block itself should also have a focus outline. It would be the equivalent of clicking the placeholder block. You're still in edit mode, you can still use arrow keys or tabs. The focus outline on the block would just serve two purposes:
Right — to clarify when a block receives focus in edit mode, it's not multi selected, and it has nothing to do with navigation mode. I hope to work on these focus outlines today, and hopefully that'll help visually explain it. It's key that you would never switch from edit mode to navigation mode unless you take explicit actions to do so, like:
Did I understand your questions right? Did the above clarify things? |
It's probably best for me to demonstrate my confusion with an example. Say the image block is this:
Now, if I was in navigation mode, I would give the focus to Assume we're going with the tab goes to the next block with the editable part focused. Now, if I press a) it would make no sense for me to move into So my main issue is that if I have to press So in summary: Is the workflow: Navigation mode:
Edit mode:
In all modes, I would also assume that if I'm within Do my questions make sense? @jasmussen @afercia Now, if I was in edit mode in a previous paragraph, and I pressed |
Thanks for clarifying, appreciate it. I think we are in what @iseulde call's "focus hell", and it would probably be good to get input from @youknowriad and @aduth also, as some of the focus work is being actively discussed, and will probably overlap with work done here. Here's a quick GIF — the following is edit mode: As you can see, when I tab to the image placeholder, the gray outlines appear surrounding it. When I press Delete, the image placeholder block is deleted. Which is cool. If I tab further, I tab into this block. Which is also cool. This works, and is in master. Despite my previous comments about a glowing blue halo focus style for this placeholder block, I realized the block already has a focus style, it's this gray border. My apologies for the confusion. In a way, this already works then, the primary issue being that if you use the arrow keys, the outlines fade out. Should we do it so using the arrow keys or tabs do not fade out the outlines? Only typing would fade those out? It would make it clearer where your edit focus is. Long story short — if we can fix the boundary fading issue so it's clear when an image or placeholder block has edit focus, then edit mode is in order. Navigation mode This works reasonably well in this branch already. Notion.so uses a very similar pattern: Escape gives you that blue indicator, and Enter edits the block. |
I think I sort of understand what you want. So to clarify, from the previous question. If I was in edit mode, and I pressed Once in edit mode, and with |
Buttons/input fields inside a block, like a placeholder block, should probably still be tabbed to, right @afercia? |
@jasmussen I'd say yes. I think for native elements like buttons and input fields we should just use the native interaction (tabbing) because that's what users and software expect. Only for non-native UIs like the blocks themselves or toolbars, menus, etc. we should try to implement alternate interaction models that make sense (the ARIA ones when possible). |
Reporting some first feedback from assistive technologies users, originally reported on #3691, see https://make.wordpress.org/accessibility/2017/11/28/screen-reader-user-experience-with-gutenberg/ first user:
second user:
This was in some way already mentioned on other issues. Ideally, the interface should be simplified as much as possible and should show controls only when needed. Reducing as much as possible the tab stops is a must for keyboard navigation. These two modes could help, and ideally the "navigation mode" should be the default for keyboard users. Note: the above feedback was not just about blocks, more a general feedback on the whole interface. |
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 experimented in this PR. 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 🙂 |
Closing in favor of more recent efforts (tracked in #5694). |
Description
Exploring #2031
First stage of trying to have a navigation and edit mode. Work in progress. Hacky code.
How Has This Been Tested?
Just manually tested. No automated tests.
Screenshots (jpeg or gifs if applicable):
Types of changes
Checklist:
Uses cases from Issue: