Better regions and shortcut #45157
Better regions and shortcut #45157
Conversation
ellatrix
added
the
[Feature] Writing Flow
ellatrix
requested review from
ajitbohra,
draganescu,
talldan,
noisysocks,
tellthemachines,
adamziel and
kevin940726
as code owners
|
Size Change: +3.45 kB (0%) Total Size: 1.28 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
@ellatrix Thanks for exploring this and trying to find a global solution. However, we must not use escape or shift+escape for any reason going forward. This has nasty issues for accessibility on Windows and I am trying to back us out of this situation, not introduce more issues. Maybe look at using ctrl+f6 and ctrl+shift+f6?
Related PRs:
- If you look at the commits on this PR, I tried to refactor how focus was handled. I received agreement from another contributor but push back from another. useNavigateRegions: Use closest to determine the next region to navigate to #44883
- I am trying to get the list view usable so we can remove navigation mode all together. List view: Modify the shortcut to focus while open #45135 This is a really good step. I just cannot see supporting multiple systems especially since the list view is very much accessible and the tree view does a great job of showing me parent/child blocks.
Thoughts?
Could you elaborate on this? We are using Escape already and it's super common for web apps to use this shortcut. |
|
@ellatrix Okay, please bare with me, the logic behind this is non-existent.
Further reading: As you can see, the escape key is really the only key we can for sure not use based on screen readers hijacking it's usage. If the screen reader were to switch in to browse/virtual mode every time we press escape to navigate to another region, it would get pretty out of hand quickly as users would have little clue as to why all the mode switching was occurring. Picture this:
I do not expect you to ever have a good understanding of this from Mac because Voiceover does not work this way. One more example, which is a current bug in NVDA only.
Related issues:
Sorry this is so hard to understand but you are going to have to trust me that this is not a good idea. Just because other applications use it does not make it right. I could list hundreds of problems with Google Docs, Slides, etc. Probably not the answer you were looking for, but hope it helps. Thanks. |
|
So we shouldn't be using Escape ever? How do you suggest we close modals, popovers etc? |
|
@ellatrix Ah, you found the only use for escape in applications. Using escape inside a modal is okay because the screen reader is already likely in browse mode anyway. As far as menus go, sometimes depending on the markup, escape on first press does not work with screen readers because of the mode switching. Sometimes it takes 1 escape press to switch to browse mode and 1 escape press to close the menu. I agree, it doesn't make sense because in browse mode keys are not sent to the application, but escape seems to have always had some weird behavior this way. |
|
I don't get it. If they key down event is not sent to the application in browse mode, how can the modal be closed on Escape? |
|
I'm worried that we start to optimise too much for screen readers while we do provide alternatives to use. From what you're saying it doesn't hurt allow the usage of Escape, it's just that you cannot use it on Windows. In that case, you can still use the old shortcuts to navigate regions. I'm not removing those. |
|
In fact, this PR is actually adding two other ways to get to navigation mode with the current region shortcuts. |
|
@ellatrix Answers.
Yeah, I believe it is considered to be a navigational key and that is why it works. Just like tab. Tab key really does not act that differently between the different modes. The letters on the keyboard do, they could be used to jump to headings, links, lists, edit fields, etc. The arrow keys move the screen reader cursor in browse mode but allow the application control in edit/focus mode. Some keys operate almost the same way in either mode and some do not.
Agreed to a point but designing around accessibility and screen readers is something that should be more important then it currently is. As devs, we should be making things easy to use for everyone and ensuring everyone has the same experience. Trust me, I did not wake up one day and say I want all the problems that come with a screen reader just to have some level of independence online. If we document escape key as a working solution, we'll find out real quick what types of problems those introduce for screen reader users. For other alternatives, I'll quote what you said.
It is the edge of a slippery slope. You find those hard to remember but because escape would not work well on Windows, they are okay for the screen reader users. Another thing to think about is how this might tie in with the list view. I just do not find the block navigation 100% necessary any longer and it would be great to working towards something everyone can use without having to maintain two systems that do essentially the same thing. List view and navigation mode. Thanks. |
alexstine
added
[Focus] Accessibility (a11y)
This is where I'm not following. So Escape does work in browse mode in Windows? So then it is fine? |
Not exactly. Escape is a multi-function key in Windows depending on the screen reader. JAWS for example has the most trouble with this because it is directly responsible for switching modes. This is one of the developers of JAWS echoing the same. #29526 (comment) The ctrl+f6 and ctrl+shift+f6 shortcuts are used in many browser-based applications and f6/shift+f6 is used in many Windows/Mac apps for navigation. I suggest this shortcut because it does not have any effect on screen reader mode switching and it is getting to be quite a well-respected navigational shortcut in the screen reader community. Let me put it this way. If there was another key other than the escape key that could close menus and dialogs, we'd probably use it. Not knowing as a screen reader user if escape will switch modes or close the modal you are currently in is a confusing situation. Picture this example.
Hopefully this explains a bit more. |
|
How do you go back to entering edit/focus mode after pressing Escape and going to browse mode? |
|
Another question: you mention that Ctrl+F6 is used for browser based applications. Why are we currently using Alt+F6? If we were to use Ctrl+F6, would this translate to Cmd+F6 on Mac? And why can't we plainly use F6? Does that clash with browser shortcuts? |
So, f6 does clash with browser behavior. I am not sure if it does or not on Mac, but best guess would be yes. By default, f6 will move the focus around the toolbar, tabs bar, main content, etc. Where are we currently using alt+f6? I think Slack used ctrl+f6 but I think the whole idea is just to call some variation of f6 a navigation shortcut. In Slack desktop client, f6 alone is used because it is a native application they wrote. I think Teams uses ctrl+f6 on the web and the desktop client for consistency. I see no problem with using alt+f6 if that is easier. Tagging @MarcoZehe to help explain some finer points if time provides.
I know the basics of how this stuff works, Marco might be able to give us a look at why it works this way. Your next question might likely be if switching from modes is so easy, why am I pushing back so hard on it? Because, blind people rarely receive equal education to sighted people in the US. It is a painful fact but I watched it myself. I graduated with many who barely new how to check their email so when I start these types of discussions, I do so to try to make things incredibly simple with odds that are against us. Others on the project have been known to disagree, but I do not think it is our place to run an educational program for screen reader users. At least, not for just using Gutenberg if that makes sense. All for giving back, but that to me, is the wrong way to go about it. Thanks. |
|
@alexstine Apologies, I confused it with Alt+F10. We're currently using Alt+F10 to focus the block toolbar. If we're adding Ctrl+F6 and Shift+Ctrl+F6 to navigate regions (which now includes the block toolbar), this could be removed, or we make Alt+F10 another alias for navigating regions (so it doesn't stop working). Another question is whether the block toolbar should be positioned before or after the block in the DOM. This matters because positioning it after means using Ctrl+F6 and positioning it before means using Shift+Ctrl+F6. Some people are of the opinion though that the DOM position should be close to the visual position, and the block toolbar does appear just above the block. I don't care much either way. It is something to keep in mind though if we'd consider merging List View and Navigation Mode. The position of List View would matter in how it's accessed. |
|
While I don't mind adding Here's three alternatives:
I'm just trying to be creative so that it's easier for everyone to navigate regions. :) |
I do not fault anyone on struggling with shortcuts, it is a very hard task. If it helps, here are the ones we cannot use as they cause conflicts on Windows.
I do see what you mean about the keyboard usage on Mac, to press f6 or shift+f6 is harder due to the function key. The things suggested on Windows would not be super easy either. Think about this one, ctrl+shift+escape? That is still 2 hands of work for most people. How would you feel about ctrl+f6 and ctrl+shift+f6 if you kept the function keys displaying on Mac? https://support.apple.com/en-us/HT204436 I mean, this would not be unreasonable. Mac is kind of clunky this way and I am always constantly adjusting Voiceover to work different ways per app. It is annoying but this is proof Apple is moving away from an accessibility-first approach. Seems like Windows is too, sigh... |
Agreed, we leave it as is. One thing we can improve here is allow Alt+F10 to cycle through toolbars if there are multiple (e.g. inline toolbar, block toolbar, link UI etc.)
That is not possible. The closest position the toolbar can get is at the edge of the content. We can't insert the toolbar inside the content because it is not content but UI. This is the same as any other editor. What I was wondering is whether the block toolbar should be positioned before or after the content.
When the editor has focus, this will no longer work in the future because we will change Tab to indent in lists and insert a tab character in code, preformatted, code editor etc. Hence this PR to improve alternatives to navigate/escape out of the editor content.
It's still one key less in either direction by default (2 keys forward, 3 keys backward). What do you think of the first alternative I mentioned? I will give this a try in a separate PR maybe. For now let's more forward with this. I will fix the tests and polish the code. |
We just need to figure out how to dynamically change the labels so that way users know what toolbar does what. Right now, it chooses the closest one so if it cycles through, users need to know where they are.
That is fair. Put it at the start, before the content.
Yes, but don't you envision this improving the navigation within dynamic blocks such as the image block as well? For example, accessing the Upload, Media Library, other tabbable content, etc. I think for blocks that do not include a specific use for the tab key such as the list or code blocks, it should have a roving tabindex pattern. Looking forward to giving this a test! |
|
@ellatrix So apparently Firefox uses ctrl+f6 and ctrl+shift+f6 as well. In theory, we could switch to just using f6/shift+f6 as we're going to need to throw By any chance, is ctrl+< or ctrl+> being used anywhere? It does not follow the model of using shift key to go back, but it may be easier on Mac and Windows. Only if it does not conflict with an existing shortcut. Thanks. |
|
Testing in Chrome, ctrl+f6/ctrl+shift+f6 work fine. Strange. |
|
Just to add, looks like Mattermost also uses a similar pattern. https://docs.mattermost.com/channels/keyboard-accessibility.html The ctrl+f6/ctrl+shift+f6 cycles regions in the browser. The tab/shift+tab navigates a regions content. How hard would it be to make this fully work in Gutenberg? Seems this is the way of the future with JS apps. At least until someone finds another way for keyboard users. |
What?
[Please note that the code is still a WIP, but it works for testing.]
As we are looking at changing tab behaviour in the editor (for list and code blocks), we need to strengthen other types of navigation.
There's two existing mechanisms:
Proposal: additional regions with easier to remember shortcuts.
The additional regions would be:
In addition to that, offer easier to remember shortcuts:
The (Shift+)Escape combination is a good indicator that it can be used to cycle through the regions, just like (Shift+)Tab can be used to cycle through tabbable elements.
But Ella, won't Escape clash with existing behaviour?
When a block is selected and focussed, we already use it for Navigation mode, which is now baked in the regions.
In other places, it can be used for closing popovers and modals, but that's fine. First the popover or modal must be closed before you can continue cycling through the regions. It makes perfect sense to me.
The main regions can be seen as the roundabout on which (Shift+)Escape can be used to navigate. (Shift+)Tab (default) or Arrow keys (navigation mode, toolbars) can be used to navigate more granularly.
Why?
We need a solid method to navigate the editor because (Shift+)Tab may no longer work when a block is focussed. A single unified way that is easy to remember will benefit all users greatly.
How?
Testing Instructions
Select a block. Test Escape and Shift+Escape shortcuts.
Screenshots or screencast