Improve keyboard navigation experience in all the block editors

[tellthemachines]

The problem

Keyboard navigation (and by extension, screen reader navigation) across the block editors is difficult and unintuitive. This is in part due to the complexity of the interface, and in part due to rapid iteration on features changing the interface frequently, with the keyboard experience not always taken into account along the way.

We often find ourselves having to fix regressions, or add in functionality piecemeal where it's missing.

How can we improve this?

There are a few ideas that have been floating around GitHub and WP Slack. I was inspired to open this discussion by two recent chats in the accessibility channel:

Thread on keyboard navigation in the Widgets editor

Discussion on improving keyboard interaction for screen readers

Here's a high-level observation on keyboard experience from the first link, that applies across all editors:

Most of this is about having a natural functional flow: [the editor is] possible to use, but only if you know how to do it. Arrow keys are not mentioned in the keyboard shortcuts, there's not visible text mentioning that arrow keys might be useful, no graphic affordances to suggest the use of arrow keys, etc. But without using arrow keys, it's unusable.

A major point of contention regards the Tab key behaviour when a block is selected, moving focus to the sidebar instead of the next focusable element in the editor canvas. This behaviour was implemented so that keyboard users could easily access the sidebar controls for the selected block, but it makes it harder to navigate the blocks in the editor (see #24728). This in turn led to the development of the Navigation or Select mode (activated by the Escape key when a block is selected), that allows navigating blocks with the Tab key. But Tab only takes us through blocks that share the same direct parent; if we want to access nested blocks we still have to use the arrow keys (see #25126).

Arguably, Navigation mode wouldn't be necessary at all if we provided the default editing mode with better keyboard support. The second Slack discussion linked above provides some ideas:

I think it would be better to refactor the editor to use other keyboard shortcuts for Toolbar/Sidebar that way Tab/Shift+Tab can be freed up for focus. Then the CTRL+` command or similar could be used to move around. Alt+F10 could still focus the Toolbar.

a Common pattern for navigation among sections that is starting to spread is the use of F6 and Shift+F6, or combined with CTRL when in a browser. Slack and Discord use this, depending on whether the Electron app or the browser is being used. In all Browsers, F6 and Shift+F6 are used to move between toolbars, the web content and any other notifications or bars. So when in the browser, CTRL+F6 to move between sections is a not too steep learning curve to master.

That still leaves us with the problem of navigating through nested blocks. We could give the Tab key its default behaviour back and let it tab through all elements, or we could keep using the Arrow keys, but provide some hints about them in the interface.

Further thoughts

Once we agree on a way forward, there are a couple of things we can put in place to avoid regressions and inconsistencies:

• Have a detailed spec of how keyboard navigation should behave across the interface, that can be referred to when implementing or changing features, to keep the experience consistent.
• Add more keyboard navigation checks to our e2e tests.

Cc. @joedolson , @alexstine and @MarcoZehe who participated in those Slack chats.

[tellthemachines]

Another relevant issue exploring improvements to nested block navigation, particularly with regards to screen readers, is #30620.

[alexstine]

I think we are trying to solve a lot of great big issues all at once.

1. Can we figure out how to build a reliable interface for these newer Blocks such as the Columns Block, Navigation Block, etc?
2. Once done there, I really think we should make the List View accessible and ditch the Block Selection Button (Gutenberg Modes). The List View, you use your Arrow Keys to move around and I think we can communicate this better, but it is currently structured like a tree view visually. We just need some additional ARIA support. If you insert a Columns Block and open the List View, you will see all the child Column Blocks under the Columns Block. Wouldn't it be so much cleaner to just rely on the List View and get rid of the different Modes which confuse most contributors who haven't seen the code behind it?

Thanks.

[MarcoZehe]

If the blocks are arranged in a tree view like style visually, meaning the hierarchy is immediately visible, we need to also use a similar pattern for screen reader exposure. List views, by their nature, are more flat, unless you're dealing with the Mac where the lines in multi-column list views are sometimes a bit blurred. But on Windows and Linux, list views are usually not hierarchical, tree views, and by extension on Linux, tree tables, are. So, a tree grid, to keep the two-dimensional characteristics in addition to nesting of elements, sounds appropriate. Since the list view component is already built upon tree grid AFAIK, we should expand this and make sure all relevant information is communicated.

I agree we should get of the different Gutenberg modes and get this navigation right once and for all.

[talldan]

I did a lot of work on the Tree Grid. It has had a lot of criticism (see #32294), but at the same time there aren't many accessible patterns that suit this hierarchical structure. Tree grid isn't a perfect fit either, as it's usually for more table-like content. The main reason a tree grid was chosen is to support multiple focusable elements in each row, as there was a desire to add block movers and the block settings menu (which is now implemented).

There are other options, like going back to a more basic list structure and using contextual keyboard shortcuts for those other features.

It'd be interesting to hear both of your thoughts on what you think would work.

[MarcoZehe]

Note for the F6/Ctrl+F6 comment quoted in the starter comment, on the Mac, CTRL+F6 would map to Cmd+F6, so F6 and Shift+F6 remain untouched for browser navigation.
So when within a block, and editing it, CTRL+F6 would jump to the side bar with that block's options, and from there, Shift+Ctrl+F6 would jump back to the editing position. Both keystrokes would act as circles around major containers, like they do in Slack or Disord when used in a browser.

If running in an Electron context, these would be just F6 and Shift+F6, since in Electron, the keys are free. Slack and Discord also do this.

[MarcoZehe]

I just had a play with the enhancements @alexstine added in #38358 and like them a lot. The way this is with that PR, it makes a lot more sense keyboard-wise. As for the fact that columns are arranged side by side, this is just something users have to be aware of. Some blind users may never have had multi-column layout text or elements under their fingers. But that's more a matter of training than one Gutenberg has to solve I think.

[tellthemachines]

Thanks for all the feedback, folks!

Coming back to this now that the List View enhancements in #38358 have been merged: how far does this improvement go towards fixing the overall issue?

I'm thinking that if we're relying on List View to provide a good keyboard experience when navigating within the editor content, perhaps we don't have to change the whole tabbing behaviour as suggested in the initial comment. That saves us from making a huge change with potentially lots of side effects, but leaves a few things yet to be solved:

• We should be able to easily move into List View from anywhere in the content. Currently, that can be done with the shortcut Ctrl + Opt + o, but it doesn't work in VoiceOver because the Ctrl + Opt combo is used by VoiceOver for different purposes. (Same issue affects other shortcuts, see Keyboard shortcuts that use the access modifier don't work with VoiceOver #11154)
• If the "Contain text cursor inside block" preference is enabled, block inserters inside container blocks (e.g Group, Column, Navigation) can't be navigated to with the keyboard, because navigating inner blocks relies on arrow keys, and these don't move between blocks with that preference enabled. List View doesn't allow for adding new blocks except in very limited ways - insert before/after for some blocks, and duplicate - so it doesn't really cover that functionality. We have Empty inner block area isn't keyboard accessible when contain text cursor inside block preference is enabled #36710 to track this.
• If we continue to rely on arrow keys to move between blocks in Edit mode, we should at least add that to the keyboard shortcuts modal, if not find a better way of explaining/making obvious that arrow keys are needed to navigate.

I'm probably missing a few things, so please add to this if there are any further issues (tracked or untracked)

[alexstine]

We can't avoid it forever, we're eventually going to have to make Tab work. 😞 If I am a screen reader user and I land on a button, Tab and Arrow Keys need to work. Should probably get a different Issue started for discussing what this pattern should look like. I agree we are 100% moving in the right direction.

[tellthemachines]

By "make Tab work", do you mean it should have its default behaviour of moving through all focusable elements in DOM order? I'm happy to look into it, just want to be sure it's needed/useful, because it'll require quite a bit of work 😅

[alexstine]

@tellthemachines I think it is very useful. If I insert a Navigation Block and focus is placed in the Block wrapper, you should press Down Arrow to focus the first button. Tab should do the same thing in this situation. Does that make sense? Then when I reach the end of tabbable elements in the Navigation Block, focus can go to the Sidebar.

[tellthemachines]

Oh I see, just saw your comment on #36710. So we want to make Tab work only inside each block. That should be easier to manage!

[alexstine]

Okay, in an attempt to summarize my thoughts again, here goes nothing.

Lately, I've been working on improving the table block accessibility and as a result, opened this issue: #41014. However, it just occurred to me that this solution will not work. If the Tab key is used to move to fields within a block, Shift+Tab should be used to move to previous fields. The only problem being what if you wanted to jump to the block toolbar to bold some text in column 2? You could not do it since you would be at the beginning of the block in column 1 before Shift+Tab would focus the toolbar. With this being said, here is what I now think.

1. Is it unreasonable to expect users to use Alt+F10 to jump to the nearest block toolbar? If not, we can remove Shift+Tab triggering the block toolbar.
2. Is it unreasonable to allow landmark jumping to access the block sidebar? If not, Tab key can no longer jump to block sidebar. My only concern is for sighted users. Does the current landmark navigation commands work visually (Ctrl+`)?
3. I think navigation mode can be fully replaced by the list view now. It is very accessible and works well. List view makes a lot more sense with inner blocks since you must expand the parent block to view the children. A lot better than trying to communicate horizontal/vertical positioning to users who may not have an idea what that means.
4. Tab and Shift+Tab keys while in a block can be used to navigate block specific content but not anywhere else. If I had inserted a table block for example, I would expect to focus on the description instructions, Tab key to first input field, Tab key to Create Table button, and then Tab key should bring me back to instructions. Not switch to another block as this will be too hard to communicate. If there are inner blocks, the only way Tab would make sense would be to place focus in every inner block before moving back to root blocks. Very confusing so I propose keeping Tab/Shift+Tab for block content navigation only. What I am getting at is blocks should use constrained tabbing but sighted users should be able to use Arrow keys to move to other blocks just as long as the next option is not enabled.
5. The contain cursor in block option will still be necessary to restrict Arrow key navigation for screen reader users.

Gosh, I've had a lot of time to think about all of this. Have I left anything out?

Easiest to hardest:

• Number 1 is likely the easiest.
• Number 4 is probably next. I believe there is already a hook in wordpress/compose for this. Not sure if modifications will be needed.
• Number 2 doesn't seem all that simple but something to maybe give a test. If it works as I describe, this becomes a non-issue. All we must do is communicate to users about another keyboard shortcut vs. using Tab key. The hardest challenge here is going to be updating all the E2E tests to not rely on Tab jumping to sidebar.
• Number 3 I think will be something of a nightmare. This feature is tied in to multiple parts of the editor. Probably best to leave this one for last as the others are low hanging fruit in comparison.

Given everyone is okay with the proposal I put together, the next thing to discuss is who will have time to work on this during 6.1? Would be awesome to start getting some of this going in the right track. These are the features, I think, can bring huge potential for great accessibility.

I could volunteer to go after numbers 1 and maybe 4. I believe most of number 1 is handled in writing flow and number 4 is as well.

For now, I'll keep working on other stuff that I think may be easy fixes but the further I go, the more I find myself getting blocked by big architectural issues. This is why I decided to revisit this tonight.

Thanks all. 👍

[alexstine]

The fun has begun. Opened the first PR to try to remove Shift+Tab for block toolbar focus. Hoping to get some feedback.

#41645

[ellatrix]

The editor content should be one tab stop, which is the same of all editors out there. Arrow keys are used to navigate the content. The editor should be seen as one big area that is contenteditable, similar to a textarea. The tab key moves focus out of the editor (before or after). We've worked hard on getting it to this place. Could you elaborate on why arrow keys wouldn't work for navigation within the content?

[alexstine]

@ellatrix

Could you elaborate on why arrow keys wouldn't work for navigation within the content?

For multiple reasons, let's think about this.

1. It all started with this: Edit mode: arrow up/down should not move to other blocks #22190 It was important to implement this for accessibility and it's a setting I would not want to live without.
2. However, as the editor moved away from text only blocks, this became tricky. E.g., the navigation block is a block that requires tabbing or arrow navigation but arrow navigation is not possible when the above setting is enabled for good reason.
3. I believe it is perfectly reasonable for screen reader users to use Tab key to navigate content within a block but not from block to block. After all, Tab does allow us to move forward and backward in traditional websites.
4. I'm not sure how other block editors work but I doubt they are very accessible if they operate like this. It may be fine for text only blocks but the one thing the Gutenberg Team didn't consider was how FSE could wreck accessibility.

I think we are at the point where we have to let Tab/Shift+Tab do more as we're running out of options. Could I in theory change useArrowNav to allow navigation even with the setting enabled from number 1 if non-contenteditable? Sure. However, keeping the experience consistent is important. This discussion was created to figure out how to do that for all blocks, not just a few here and there.

Hope this helps explain things a little more.

Thanks.

[alexstine]

Just as a side note, I put this on the Accessibility Team meeting agenda for tomorrow so it can be discussed further.

https://make.wordpress.org/accessibility/2022/06/15/accessibility-team-meeting-agenda-june-17-2022/

I also requested further feedback from the Core Editor Team to see if maybe the idea is good or could use improvement.

[talldan]

the navigation block is a block that requires tabbing or arrow navigation but arrow navigation is not possible when the above setting is enabled for good reason.

@alexstine Do you know what it is about the navigation block that causes navigation issues? Is it because it's a block that contains only other blocks? I was wondering if the same issues exist with blocks like Buttons, Columns or Group? I'm not surprised it's difficult to use because it is quite complex, but I wouldn't expect it to be quite as complicated as Columns, since that may have more freeform content. Navigation is usually just a set of links, so it should be possible for it to work in a more consistent way.

I'm guessing this is separate to the focus loss problems that have been documented elsewhere.

BTW, when I was testing the site editor just now, I noticed this bug - #41811

[alexstine]

@talldan It is the whole idea of Arrow key navigation that makes these blocks not work well. For example, if NVDA switches from edit mode to browse mode, Arrow key navigation no longer works reliably. This is likely because the ARIA spec is drastically lacking for a dynamic editor like this.

Here is another example that may help.

1. Enable the Contain text cursor inside block option.
2. Insert a table block.
3. Allow the defaults and press Tab to Create Table button. Press Enter.
4. First column/row should receive focus.
5. Press Right Arrow to move to the 2nd column.
6. Notice how focus doesn't move because the cursor is restricted from Arrow navigation.
7. Now use Tab, notice how before my PR focus jumps to the block settings sidebar.
8. After my PR, the block follows logical tabbing order until the sidebar is reached.

See what I mean? These more dynamic blocks and accessibility are really tricky to get working consistently. This is why I made Tab key work as Arrow navigation just didn't meet the needs of accessibility.

This make sense?

[tellthemachines]

This is a hard one to get right 😅

if NVDA switches from edit mode to browse mode, Arrow key navigation no longer works reliably

Is this a problem generally, or only when "Contain text cursor inside block" is enabled? We could make Tab work differently when that option is enabled, and keep the current behaviour when it's not, but if Arrow keys don't work well with screen readers in general, then it's not worth going down that path.

If the Tab key is used to move to fields within a block, Shift+Tab should be used to move to previous fields. The only problem being what if you wanted to jump to the block toolbar to bold some text in column 2? You could not do it since you would be at the beginning of the block in column 1 before Shift+Tab would focus the toolbar. With this being said, here is what I now think.

This is a good point, but we could still have Shift+Tab move into the toolbar once it reaches the first focusable element inside the block. Pressing Tab when in the toolbar moves into the block, so I'd expect the inverse to also work. I guess we could also have Tab move into the sidebar once we reach the last focusable element. Or would that cause any problems?

Is it unreasonable to allow landmark jumping to access the block sidebar? If not, Tab key can no longer jump to block sidebar. My only concern is for sighted users. Does the current landmark navigation commands work visually (Ctrl+`)?

The main obstacle to this is backtick not existing across all languages, so some keyboards may not have it. @Ryokuhi brought this up on Slack specifically for the landmark shortcut, but in general it would be good to have essential shortcuts rely on keys that are more universal (although we'd have to work out which ones - this may be best addressed as its own issue). This would be less of an issue if we kept Tab jumping into the sidebar on reaching the end of the block.

Tab and Shift+Tab keys while in a block can be used to navigate block specific content but not anywhere else. If I had inserted a table block for example, I would expect to focus on the description instructions, Tab key to first input field, Tab key to Create Table button, and then Tab key should bring me back to instructions. Not switch to another block as this will be too hard to communicate. If there are inner blocks, the only way Tab would make sense would be to place focus in every inner block before moving back to root blocks. Very confusing so I propose keeping Tab/Shift+Tab for block content navigation only. What I am getting at is blocks should use constrained tabbing but sighted users should be able to use Arrow keys to move to other blocks just as long as the next option is not enabled.

I think this makes sense, but there's an argument for considering toolbar and sidebar to be part of the block-specific content - in which case we should be able to Tab/Shift+Tab to them at some point.

One thing we should do anyway is put some design thought into making keyboard behaviour more obvious, possibly through strategically placed helper text, because it's hard to guess which keys are expected to do what at any given point.

Regarding the Navigation block, we have a bunch of issues tracked in #38786. In terms of its content, once it's set up, I think the problems with Arrow key navigation are the same as with other container blocks.

[ellatrix]

How do you navigate more complex content in plain contenteditable? Just trying to understand things better.

[alexstine]

@ellatrix That is what I am trying to solve as currently that is not possible with Gutenberg. As far as just any complex content in contenteditable, I am not aware of any other application that may have such a problem. Gutenberg truly is unique in the way that it is like nothing else, at least to my knowledge.

In the coming days, I am going to record a demo of what it is like to use the editor before and after my linked PR. I think you will find the results interesting. I'll record it from Windows so you can see just how different the interaction model is with Windows vs. Mac.

I'll be back shortly... 👍

[alexstine]

Hello all, happy Sunday!

I know I am a bit behind, but I finally finished the video.

https://drive.google.com/file/d/1vDR7Yn0k7iErwl7xBFVlyK4_tERUjOdH/view?usp=sharing

I know this probably makes things more confusing, but this at least allows you to see my experience live before and after my PR. It is not a perfect solution but it is better than what we currently have.

Please let me know your thoughts.

Thanks.

[ellatrix]

Thank you, I watched your video.

Apologies, when I commented earlier, I didn't think about the "contain caret" option. I completely agree that this option's implementation is lacking. We rely on the arrow key behaviour to navigate within the editor and that behaviour is disabled with this option without a replacement. For this option, it does seem to make sense to enable tab to navigate tabbable elements within the editor canvas.

To be honest, I still don't quite understand why this option is needed. You explained it at the end of your video, but it still doesn't make sense to me. When you use arrow navigation in any editor, and you're at the end, the caret will move to the next paragraph. It's even announced, no? If that's unexpected, you can use the opposite arrow key to move the caret back to where it was? I don't see how this is different from other editors.

The option also doesn't work as advertised. It says it contains the caret in the block, but by doing that it also disables caret movement inside the block.

Another question. Are you're proposing that only the selected block contents are tabbable? So after going through all tabbable elements inside the block, focus is moved to the sidebar?

Regarding the NVDA modes (browse/focus), is there no way we can influence with the correct aria roles and ensuring focus is not lost? Why doesn't NVDA switch back to focus mode when you're in a content editable element? In the video you imply that this is possible ("Gutenberg is not marked up with the correct aria specifications"), so could we attempt to fix these issues first? It seems like there's a lot of issues with navigation mode as well, so it would be good to fix that.

Are these NVDA modes only there for Windows or also Mac? If not, do you know why it's different?

Sometimes you can get lost in other blocks and not even realise it.

Can we speak a message when this happens?

[alexstine]

@ellatrix

To be honest, I still don't quite understand why this option is needed. You explained it at the end of your video, but it still doesn't make sense to me. When you use arrow navigation in any editor, and you're at the end, the caret will move to the next paragraph. It's even announced, no? If that's unexpected, you can use the opposite arrow key to move the caret back to where it was? I don't see how this is different from other editors.

It is different because Gutenberg is pretty hard to understand for the blind. The only reason I have an idea is because I used to be able to see. When we are talking editors, I am thinking Microsoft Word, Google Docs, etc. I am not thinking Gutenberg which is not a canvas for say because it contains blocks. In the blind world, blocks are conceptualized as self-contained boxes/containers. When you are reading along and you bounce in to another block, you can start to see how users could get confused. Especially if they think the paragraph block includes 2 lines of text but it only includes one. This means, when the user presses Down Arrow key, they are automatically thrown in to the next block. Adding more messages will likely make the problem worse due to verbosity issues. This type of visual editor already gives a ton of dynamic updates, I do not think we should be adding to it.

Another question. Are you're proposing that only the selected block contents are tabbable? So after going through all tabbable elements inside the block, focus is moved to the sidebar?

Yes. That is how I designed it to work for the best compatibility at the moment.

Regarding the NVDA modes (browse/focus), is there no way we can influence with the correct aria roles and ensuring focus is not lost? Why doesn't NVDA switch back to focus mode when you're in a content editable element? In the video you imply that this is possible ("Gutenberg is not marked up with the correct aria specifications"), so could we attempt to fix these issues first? It seems like there's a lot of issues with navigation mode as well, so it would be good to fix that.

That is something that will take a long time to get working at this point and I am not sure any team has the resources for it now or in the future. I would like to see it happen but right now, I am trying to get something workable at the very least. Even Slack has it's problems because of the confusing ARIA spec so it is not just Gutenberg that has issues.

Are these NVDA modes only there for Windows or also Mac? If not, do you know why it's different?

NVDA and JAWS on Windows. For Voiceover, it is a totally different interaction model. NVDA/JAWS read the screen element by element like a flat canvas. Voiceover follows similar model but if you want more details for say a table, you actually have to directly interact with the table element.

https://gist.github.com/cfarm/b3539ae8c1665f6fe931c10453bb42ae

That actually probably makes things more confusing. The only way you will ever understand the difference is by knowing/using both. It was hard for me to get used to the differences as they work so differently.

[ellatrix]

In the blind world, blocks are conceptualized as self-contained boxes/containers. When you are reading along and you bounce in to another block, you can start to see how users could get confused.

I guess what I'm saying is: if we properly announce everything, it should be clear and unconfusing? We indeed have the concept of blocks, but they were never meant to be self contained in terms of writing flow.

Adding more messages will likely make the problem worse due to verbosity issues.

How verbose are we currently when you switch between blocks that way? We should try to be concise and helpful. Maybe "End of the editable element. You're now in the next editable [name] element. Use [key] to move back." The wording can probably be clearer and improved. We could even add the Escape key to go back, in addition to the opposite arrow key.

It's worth noting that this behaviour not only allows you to navigate between blocks, but also between content editable elements in a single block. Just adding that for clarity.

That is something that will take a long time to get working at this point and I am not sure any team has the resources for it now or in the future.

Could you point me to a resource that describes the correct aria specification (that would ensure the right mode in NVDA)? I'm just really interested in learning more.

I guess I should try it out at some point on a Windows (virtual) machine.

Maybe for now, we can add the new tab behaviour to the "keep caret in block" option? But it would be great to avoid that option if possible in the future.

Yes. That is how I designed it to work for the best compatibility at the moment.

So if Tab to sidebar from the end of a block still works, why wouldn't it work to Shift+Tab from the start of the block to the toolbar?
What we also have to keep in mind is nested blocks. If there's a huge amount of deeply nested blocks in the selected block, it's probably not a good idea tab through every one of them. Maybe tab should navigate through the directly nested blocks only, and maybe on pressing Enter you actually select the block and can then navigate inside that block.

[alexstine]

@ellatrix

I guess what I'm saying is: if we properly announce everything, it should be clear and unconfusing?

In a perfect world, yes. However, this just is not the interaction model users of assistive tech expects. It is much easier for us to deal with one item at a time.

How verbose are we currently when you switch between blocks that way? We should try to be concise and helpful. Maybe "End of the editable element. You're now in the next editable [name] element. Use [key] to move back." The wording can probably be clearer and improved. We could even add the Escape key to go back, in addition to the opposite arrow key.

Screen readers often suffer from information overload. The information we provide now is okay but if you add up all the unintentional block switch messages per day, it gets to be unruly. Think about it. You are reading along with Up/Down Arrow keys and since you cannot see where your cursor is, you keep switching blocks every time you come to the end of a good length paragraph. I understand when you return to the block you will pick up where you left off, but in traditional textarea fields, you would be placed at the beginning. What I am trying to say is we will likely never overcome the potential for user confusion in this area since this part of the editor just does not go along with what the community believes. As I mentioned, blocks being self-contained elements. This is how all form controls are for screen reader users so in the context of Gutenberg, I wanted to make sure screen reader users could keep what they are most used to and less likely to complain about.

It's worth noting that this behaviour not only allows you to navigate between blocks, but also between content editable elements in a single block. Just adding that for clarity.

You are assuming screen reader users know they can do that though. This is super uncommon UX and I myself had trouble figuring this out. It is not a common interaction model for screen readers/web content. Tab is common and supported on all platforms. The whole Left/Right Arrow thing, that is most likely to be known on Mac but not at all on Windows. Another thing I do not think you have given much thought is jumping from field to field while the field contains content. E.g. in a table block, if you filled in one of the columns, to go next, screen reader users would have to use Arrow keys to navigate all the way through that text. This UX is horrible and Tab key is again, a clear winner.

Could you point me to a resource that describes the correct aria specification (that would ensure the right mode in NVDA)? I'm just really interested in learning more.

Essentially, we would need to manage it all ourselves. Read this for more info.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/application_role

Maybe for now, we can add the new tab behaviour to the "keep caret in block" option? But it would be great to avoid that option if possible in the future.

I think this will be here to stay. You should understand more after testing on Windows.

So if Tab to sidebar from the end of a block still works, why wouldn't it work to Shift+Tab from the start of the block to the toolbar?

Because of context. Let's go back to our table block for example. If you are in column 2, row 3 and you press Shift+Tab, you will go all the way back through the rows/columns before finally reaching the block toolbar. I just thought this could be bad UX as Shift+F10 would need to be used to customize anything that was not in the first column/row so I decided to apply this model of Alt+F10 to all blocks. After all, this is a very common Windows shortcut used throughout most programs. Generally, F10 will bring you to the ribbon in all Microsoft programs such as Word, Outlook, etc.

This is by no means a perfect solution but it meets most of our limitations right now and solves them with minimal effort.

[ellatrix]

If you are in column 2, row 3 and you press Shift+Tab, you will go all the way back through the rows/columns before finally reaching the block toolbar.

What happens if you're in the first cell? Will you land in the block toolbar? That would be a good behaviour to keep.

What if we also use the Home and End keys to move focus to the block toolbar and sidebar (so focus to before or after the canvas). Currently these keys are just scrolling the page, which isn't so useful. It would be a nice shortcut that semantically makes sense: Home is the block toolbar, and End is whatever comes after the content.

I will start reviewing your PR. Should we take the discussion there?

And what do you think about what I said before:

What we also have to keep in mind is nested blocks. If there's a huge amount of deeply nested blocks in the selected block, it's probably not a good idea tab through every deeply nested tabbable element. Maybe tab should navigate through the directly nested blocks only, and maybe on pressing Enter you actually select the block and can then navigate inside that block.

[alexstine]

What happens if you're in the first cell? Will you land in the block toolbar? That would be a good behaviour to keep.

You do not think it would confuse users since that is the only way you can Shift+Tab in to the block toolbar? I thought Alt+F10 would be okay since it should work in all contexts.

What if we also use the Home and End keys to move focus to the block toolbar and sidebar (so focus to before or after the canvas). Currently these keys are just scrolling the page, which isn't so useful. It would be a nice shortcut that semantically makes sense: Home is the block toolbar, and End is whatever comes after the content.

What happens if we are in a paragraph block or other text block? Then it would move the cursor from beginning or end of text field/line in text area. It is not a bad idea but the idea likely needs refining to not be confusing. Something like Modifier+Home/End? That would make sense to me.

The other option is to improve landmark navigation shortcuts so all areas of the editor can be accessed. However, this is more of a global helper, not a block by block helper.

What we also have to keep in mind is nested blocks. If there's a huge amount of deeply nested blocks in the selected block, it's probably not a good idea tab through every deeply nested tabbable element. Maybe tab should navigate through the directly nested blocks only, and maybe on pressing Enter you actually select the block and can then navigate inside that block.

We cannot have more interaction models. It is already far too confusing. We would have navigation mode, edit mode, and a secondary edit mode to handle nested blocks. Currently, this is a non-issue because Tab key will not cycle nested blocks. It respects the borders of each block. For example, if you insert a navigation block, pressing Tab will jump to the sidebar, not the custom link or submenu blocks contained within navigation. To access those, you still require navigation mode while the contain text cursor setting is enabled.

If there is no high-level overview stuff to continue discussing, happy to move over to the PR. Looks like we still need to hammer out the last couple details. 👍

[ellatrix]

You do not think it would confuse users since that is the only way you can Shift+Tab in to the block toolbar? I thought Alt+F10 would be okay since it should work in all contexts.

I think it makes sense to keep for visual users since the toolbar is the previous tabbable element visually.

What happens if we are in a paragraph block or other text block? Then it would move the cursor from beginning or end of text field/line in text area. It is not a bad idea but the idea likely needs refining to not be confusing.

For me, on Mac (Chrome and Safari), this currently only scrolls the page all the way to the top or bottom, which seems a bit unexpected. If that's what we're currently doing, it seems nice to replace it with something more useful.

Currently, this is a non-issue because Tab key will not cycle nested blocks. It respects the borders of each block.

Hm, ok, I'll have to test your PR. I'll try to check it out today.

[MarcoZehe]

On Mac, the keystroke to go to the start or end of the line isn't home and end, AFAIK, but CMD+Left and CmD+Right Arrows respectively. Am Do., 14. Juli 2022 um 11:15 Uhr schrieb Ella van Durpe < ***@***.***>:

…

You do not think it would confuse users since that is the only way you can Shift+Tab in to the block toolbar? I thought Alt+F10 would be okay since it should work in all contexts. I think it makes sense to keep for visual users since the toolbar is the previous tabbable element visually. What happens if we are in a paragraph block or other text block? Then it would move the cursor from beginning or end of text field/line in text area. It is not a bad idea but the idea likely needs refining to not be confusing. For me, on Mac (Chrome and Safari), this currently only scrolls the page all the way to the top or bottom, which seems a bit unexpected. If that's what we're currently doing, it seems nice to replace it with something more useful. Currently, this is a non-issue because Tab key will not cycle nested blocks. It respects the borders of each block. Hm, ok, I'll have to test your PR. I'll try to check it out today. — Reply to this email directly, view it on GitHub <#38311 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL66PT3JVZJXI3EMQTU2YTVT7LB3ANCNFSM5M7TLGNA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[alexstine]

@MarcoZehe Do you think we need to have something cross-platform though? Home/End or Ctrl+Home/End are used on Windows.

Home: Move to beginning of line.
End: Move to end of line.
Ctrl+Home: Move to beginning of text.
Ctrl+End: Move to end of text.

[alexstine]

@ellatrix

I think it makes sense to keep for visual users since the toolbar is the previous tabbable element visually.

That makes enough sense for me. Let me work on restoring that in my PR.

For me, on Mac (Chrome and Safari), this currently only scrolls the page all the way to the top or bottom, which seems a bit unexpected. If that's what we're currently doing, it seems nice to replace it with something more useful.

We will probably need to agree on different shortcuts per platform. As I noted above, these shortcuts are reserved already in Windows.

[MarcoZehe]

The best is to stick to platform conventions. For Mac users, CTRL+Home and End to go to start of text and end of text are totally unconventional. They use Cmd+Uparrow and Cmd+DownArrow for that respectively. Am Do., 14. Juli 2022 um 14:30 Uhr schrieb Alex Stine < ***@***.***>:

…

@ellatrix <https://github.com/ellatrix> I think it makes sense to keep for visual users since the toolbar is the previous tabbable element visually. That makes enough sense for me. Let me work on restoring that in my PR. For me, on Mac (Chrome and Safari), this currently only scrolls the page all the way to the top or bottom, which seems a bit unexpected. If that's what we're currently doing, it seems nice to replace it with something more useful. We will probably need to agree on different shortcuts per platform. As I noted above, these shortcuts are reserved already in Windows. — Reply to this email directly, view it on GitHub <#38311 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL66PVHXVIA5DFZAKZZI3LVUAB6NANCNFSM5M7TLGNA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ellatrix]

Another thing I do not think you have given much thought is jumping from field to field while the field contains content.

You can use Alt+Arrow to skip over text?