Implement new mechanism to navigate through blocks with keyboard after removal of Select mode

[afercia]

Description

#65204 removed 'Select mode' from the editor.

Select mode, also known as 'Navigation mode', was a convenient way to navigate the blocks in the canvas when using the keyboard. And it was the only way to do that.

In the past, also in a hallway hangout, contributing developers and accessibility specialists discussed the removal of Select mode and there were no strong objections. The rationale of that is that the 'Select mode' keyboard interaction was designed at a time where the editor had no nested blocks. Blocks were just a list of blocks. A such, a mechanism to tab through them appeared to be the most efficient keyboard interaction.

With the introduction of nested blocks, the Select mode keyboard mechanism became not that efficient. As such, there was no objection to remove it in favor of some new mechanism.

But, after #65204 there's no such new mechanism.

The only way to navigate through blocks in the canvas is to move the cursor through the blocks, which is a tedious and highly inefficient navigation experience especially with very long content. This is a huge regression for keyboard users.

A note on the process:
In #65204 and the related other previous PRs, I'm not seeing any consideration about keyboard accessibility. Select mode was a feature specifically designed for keyboard accessibility and now it's gone with no alternative feature. I'm not sure this is the best way to make the editor a better, inclusive, accessible software and I'm surprised that after years discussing accessibility in this project such changes happen so lightly.
I do understand the removal of Select mode is part of improvements aiming to introduce content-only mode and I have no objections about it. But, the total lack of any accessibility consideration for such basic things like keyboard operability is, honestly, frustrating after 7 years of life of this project.

The only comment that raised some accessibility concern I found is focused more on the removal of the 'Move To' feature rather than the removal of Select mode itself.

Honestly, I don't think such impactful UI changes should be merged ten days before Beta 1 when it's clear there hasn't been enough focus on accessibility and no user testing at all.

I can see two options to address this regression:

1. Quickly design and implement a new mechanism to navigate blocks in the canvas with the keyboard. This would require some research and focus from the accessibility team, designers, developers, and resources available. However, the time is short.
2. Revert Select Mode: Use the content-only behavior in select mode #65204. As mentioned above, I think such impactful changes should not be rushed. Instead, they should be merged very early at the beginning of a WordPress release cycle (not a Gutenberg release cycle). They need more time to be better implemented, to address accessibility and _be tested thoroughly.

Cc @joedolson @alexstine @WordPress/gutenberg-core

Step-by-step reproduction instructions

• Test on WordPress 6.6
• Make a post with long content, e.g. 20 blocks or more.
• Select a block.
• Press the Escape key.
• Observe the editor canvas switches to 'Select mode'.
• Observe the selected block shows a dark, small, toolbar, with the block type instead of the full block toolbar.
• Use tab or Shift+Tab to navigate through the blocks in this mode.
• When you are on the block you want to edit, press Enter to switch the editor canvas to 'Edit mode'.
• Repeat the steps above on latest trunk.
• Observe there's no 'Select mode' any longer.
• Observe you can't navigate the list of blocks in the canvas other than by moving the cursor through all the blocks and their content.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

[t-hamano]

such impactful UI changes should be merged ten days before Beta 1

#65024 should not ship in WP 6.7, see this comment.

[afercia]

#65024 should not ship in WP 6.7

Thank you, If that means the removal of 'Select mode' will not ship in WP 6.7 then I stand corrected.

Still this impactful change has been merged too lightly for my taste and it's underdesigned, with no accessibility considerations a tall.

[mtias]

Select mode was a feature specifically designed for keyboard accessibility and now it's gone with no alternative feature.

Pointing out this is not correct. It was designed as a broad interface mode, with an emphasis on keyboard navigation but not exclusive to it, at a time where we didn't have the list view, and as you point out the usefulness of it was called into question from an accessibility point of view.

In any case, there's more context on removing select mode proposal in #54703 with a point towards leaning on list view, that should have been referenced in the content-only PR. List view has had a lot more work done to navigate nested groups and is in much better shape. Perhaps we need to discuss shortcut ergonomics for jumping straight into list view panel for the currently selected block.

[afercia]

Pointing out this is not correct.

We may have different memories. To me it's correct that the Select mode was originally started as a mechanism to ease keyboard navigation at the point that at first we used to call it 'Navigation mode'. See #2031

Regardless, I'm not sure how calling my feedback 'incorrect' helps in any way solve this issue.

In any case, there's more context on removing select mode proposal in #54703 with a point towards leaning on list view, that should have been referenced in the content-only PR.

I mentioned clearly that there was no strong objection to remove Select mode but an alternative mechanism must be implemented to navigate blocks in the canvas. The List View as affordance to navigate blocks is welcomed and was mentioned also in the discussion with accessibility specialists that happened in the mentioned hallway hangout a few months ago (I can't find a link to it sorry). However, I think you are missing the point that the List View is a navigation mechanism that is outside of the canvas. There's nothing now to make keyboard navigation inside the canvas efficient as it used to be. Noting that the hallway hangout happened also to discuss live the points from #54703 so yes I'm aware of that discussion, thanks.

Before anything else, I would like to suggest everyone to actually test the keyboard experience now that Select mode has been removed.

• Create a post with many blocks.
• Use the keyboard to navigate the blocks in the canvas.
• Compare with the keyboard experience in WordPress 6.6.
• Make a honest judgment on whether the keyboard experience has improved or not.

[alexstine]

@afercia I think the list view is a perfectly fine compromise. It may not be a way to navigate inside the canvas but there are easy ways to select the block and also jump back to the list view sidebar. I agree removing this navigation/select mode feature is probably a little jarring. Should have probably replaced it with a notice for a little while to tell users the shortcuts to access the list view. We add tips around the editor often enough, the most recent example I can think of was for the styles tab, no reason we can't do the same for when keyboard navigation may not be as clear. I like this because now it frees up the keyboard to do other things such as advanced editing modes. For example, blocks such as the table block where it would be nice to use arrow keys to navigate the cells without actually editing. Enter/escape could be used to enter an editing mode for the block itself, list view could be used to move blocks. The list view is a much more accurate representation of nested blocks for users without sight. I'm a big believer in this but anyone is welcome to disagree or provide another point of view.

Keeping navigation/select mode around has been a huge blocker for other things in the editor and with a little education, I think this could be a positive change in the next release.

Noting that I'm not really an active contributor to WordPress any longer, I'll defer to others to keep this discussion going.

Thanks.

[afercia]

@alexstine thanks for your feedback. As I said more than once, I'm not opposed to remove Select mode. We also discussed this live during that hallway hangout a few months ago and agreed to consider its removal as long as an alternative mechanism is provided to navigate the blocks in the canvas.
Please consider that non-screen reader keyboard users can't use the built-in navigation mechanisms screen readers provide. For keyboard users navigating the list of blocks in the canvas is now a painful experience as the only way to do that is by moving the cursor along all the blocks and their content, which means in the case of paragraphs and other blocks with text that they have to move the cursor through dozens potentially hundreds of lines of text just to navigate to other blocks.

[alexstine]

@afercia I still don't see your point. Why can't sighted keyboard/non-screen reader users simply use the list view to navigate? How is this any different than the classic editor? That was equally painful to move through but at least everyone can make full use of the list view. Also, based on the way blocks are composed with React, screen reader virtual navigation is often times useless so I don't think screen readers get any advantage here. All users who use the keyboard would need to use the list view to navigate.

[draganescu]

I want to chime in with some clatification. I believe the root of this issue is that we had a "select mode" tool in the UI which was based on a "navigation mode" under the hood. The select tool allowed a different wrapper 1st selection, but it also triggered a navigation mode which was used for tab based navigation of blocks in the canvas. Issues and discussions about removing the select mode did not - afaik - specifically mentioned neither the dependency, nor the most important thing:

tab key navigation of blocks in the canvas (navigation mode) is a duplication of a featuire that is already handled better by list view (see @alexstine 's react composition mention above) so there is no reason to keep navigation mode, so both the select tool and the mode that supported it can go away

Between:

• press ESC
• press Tab to move around all the blocks in the canvas
• accidentally enter edit mode

and

• press Ctrl Option O to open or focus the List view
• use arrow keys to move around the tree of blocks
• only dive into the nestings that interest you
• no accidental edit mode

the second is better and due to the list view implementation apparently better supported by both standard technology - mouse and keyboard and also assistive technology interfaces.

So I think we should close this issue and just focus our efforts on #65459 to bring back a way to move blocks freely (including nesting and unnesting) using keyboard only.

[afercia]

@alexstine
First of all, the List View isn't always open and we can't assume all users will constantly keep it open to navigate.
To me, the List VIew is an additional affordance to select the blocks but it can't be the only one.
It's primarily a tool to select the blocks, not to navigate through them.
Classic editor is an entirely different matter as it is made of only one editable area with one toolbar. Instead, Gutenberg is made of blocks where some may be contenteditable and others are entirely different and have a form to fill. I would like to remind everyone that blocks based on contenteditable should have a role=textbox instead of role=document. This is a long pending issue that should be fixed hopefully soon. When such blocks will finally have role=textbox, fro a semantiv perspective and expected intereaction they will be mor elike textareas. Other blocks that don't use contenteditable are already more of a form with inputs and controls. As such, I'd expect to be able to navigate through these blocks like in a native form where the Tab key is the native tool to navigate.

the second is better

@draganescu I appreciate your feedback but I argue that's entirely based on assumptions. It may be better for your personal experience. It may be worse for other users.

To me, the removal of the ability to navigate through each block with the Tab key is a huge regressiona dn makes my experience as sighted keyboard user a terrible experience.

• Going through the blocks with only the cursor is extremely tedious and inefficient.
• Why in the world I should be forced to use the List view. That would be extremely inefficient e.g.;
  • Starting from the selected block
  • Shift+Tab moves focus to the block toolbar.
  • Pressing Shift+Tab again moves focus back to the List View.
  • Navigate the List View to select, potentially expand groups, navigate, potentially expand more nested groups, finally select the block I want to select.
  • Press Enter on the selected block in the List view moves focus to the selected block in the vancas. Alternatively Press Tab from the List view.

Would you say the process above is more efficient than simply tabbing through the blocks?

[draganescu]

Would you say the process above is more efficient than simply tabbing through the blocks?

Yes, because I believe it's just about the same thing, if done as intended:

• You don't have to shift tab twice, there is a shortcut Ctrl Option O, so one step away just like Esc for nav mode, same thing
• You have the ability to pass over nested groups, just like in nav mode tab selected same level wrapper and you had to use keys to navigate inside - it's the same thing really.
• A mode is now open for a better use case and don't lose any speed or comfort of operation in the process, less complexity, yay.

Am I missing something? Maybe a screen recording of what is extra would shine some light?

[alexstine]

@afercia

To me, the List VIew is an additional affordance to select the blocks but it can't be the only one.
It's primarily a tool to select the blocks, not to navigate through them.

Correct, just as navigation/edit mode used to do. Navigation mode never allowed you to navigate a blocks content, simply select another one.

As such, I'd expect to be able to navigate through these blocks like in a native form where the Tab key is the native tool to navigate.

I agree with you but getting others to realize that tab/shift+tab should not jump to the sidebar and should instead navigate block content will be difficult.

As far as the role goes, I think role="textbox" makes sense with contentEditable="true". I take the blame for changing it, I was trying to be more inclusive of all screen readers and made the problem much worse. When contentEditable="false" is set, which role would you expect the block to have? Are we going back to role="group"?

To your point about the sidebar staying open or not, I specifically created the shortcut to work for all users equally.

1. If the sidebar is closed, shortcut will open and place focus inside.
2. If the sidebar is open and shortcut is activated, sidebar will close.
3. If the sidebar is open but focus is not within the sidebar, focus will move to the sidebar.

I tried my best to create a shortcut that would closely mirror how navigation mode works.

If we're being super honest, navigation mode never actually allowed you to navigate blocks. What it did was automatically render a button that changed every tab/arrow key press. This has always been very problematic for screen reader users because of the dynamic text updating causing some screen readers to not read it. I can't remember if I fixed it or someone else did, can't track it down at the moment.

Thanks.

[talksina]

So, please consider this issue not just from a post writer's point of view but also from a (BLIND) creator's perspective.
@alexstine talks about the list view, I know it as well and have worked on it; but why on earth should I go in and out of the canvas every time I have to act in a group, columns block, list, quote and so on? Let alone when dealing with detail/accordion blocks, or in the future the possibility of tablists. I'm honestly scared about how lightly accessibility is considered lately.
If you have to create a complex page with groups and nested blocks, or simply put some FAQs with detail block or a spoiler, it literally takes a hour for an operation that in prior version could be made in 5 minutes by pressing Escape, then arrows, then some other keystrokes when needed.
I have no code skills to study a new mechanism for keyboard but I'd like something that, pressing Esc or whatever key to exit editing mode, allows to navigate blocks in a tree view mode, opening and closing them with right and left arrows, like the list view's experience but staying in the canvas. And you can even select, move, group, whatever you can do with blocks as they were files.
I currently do alt+shift+o to switch to list view, then after I finish selecting my block I must perform other at least 3 passages after switching list view off, to go back to canvas and edit mode. So, rationally I ask WHY creating all this frustration for people who have to work?
As it currently is, Gutenberg's experience is frustrating. I've spent months to promote Gutenberg's accessibility to wordcamps, podcasts, conferences and soon at the core days as well, then devs who don't test accessibility make me fool this way. In current stage Gutenberg is, all what I said everywhere looks like half fake, and not for my fault.
I do my best to report issues in time but I'd like more constance in accessibility testing and higher priority on it.

[alexstine]

Does simply pressing enter on a selected list view block not move focus back to the canvas for you? It is entirely possible this is broken in FSE. If that's the case, I see why this workflow is not okay. If so, having a hard time understanding how this is different. Alt+Shift+O to open list view, select your new block with Enter, focus should move back to the block.

The only thing that might be slightly different is a bit of increased verbosity as you are entering the canvas iFrame each time you select a new block. This wasn't an issue before due to how the virtual button was rendered. Essentially, if you pressed Escape, there would be a button/block selector inserted into the DOM that would change based on keyboard events such as Tab, Arrow keys, and of course, Enter to focus. This caused a lot of issues across different screen readers because we're dynamically updating a button in the DOM. That's why you always had the double announcement on Windows, we were forcing focus on it but screen reader wouldn't read without a live region.

Let me propose this. If Escape was made to focus the list view, would this improve your experience? I'm trying to understand the issue at play using the list view to replace something that probably should have never been done.

If we are to revisit the canvas navigation/edit modes, I recommend coming up with a solution that isn't so hacky this time. Maybe each block can be formed into a button and like a grid, the screen reader can navigate it vs. trying to rebuild the same button on every keydown event.

[afercia]

Am I missing something?

@draganescu I think @talksina answered you better than I could. For the future, I would kindly ask you to trust more the feedback from specialists and users.

@alexstine yes it is true that Pressing Enter on an item in the List View moves focus back to the selected block in the canvas. That is helpful but still not very discoverable as it's a non-standard, unexpected interaction. Regardless, I think this discussion is derailing a bit.

• There's no longer a way to navigate through blocks in the canvas other than the so called 'writing flow', that is, to explain it in the most simple way: arrowing through each line of text and other elements in the canvas. This is clearly highly inefficient.
• I'm glad users can still use the List View but that's not the point. The List View is not a replacement for a mechanism to navigate blocks (emphasis) in the canvas (end of emphasis).
• The removal of a mechanism to navigate blocks in the canvas without introducing an alternative mechanism is a regression.
• There was general agreement about removing navigation mode as we discussed it a year ago in the mentioned hallway hangout. A recap of that discussion and the videorecording is available here: https://make.wordpress.org/test/2023/09/14/hallway-hangout-lets-chat-about-improving-accessibility-in-the-site-editor/. Still, the removal of navigation mode should have been accompanied with the introduction of an alternative mechanism.

Can we please limit the conversation on this issue to elaborate a proposal for a new navigation mechanism in the canvas?

[afercia]

I'd like something that, pressing Esc or whatever key to exit editing mode, allows to navigate blocks in a tree view mode, opening and closing them with right and left arrows, like the list view's experience but staying in the canvas. And you can even select, move, group, whatever you can do with blocks as they were files.

That is interesting and close to the grid navigation model mentioned by Alex. It's close to the mechanism some ARIA patterns provide e.g. tabs, frid, tree, where there's only one tab stop and navigation is implemented by arrow keys. If there's agreement on such a mechanism we could certainly propose it. I see a few points to keep into consideration:

• The navigation mechanism must be discoverable and easy to use also for sighted keyboard users.
• It must work with all assistive technologies including voice control / speech recognition.
• It would conflict with writing flow so there should be a mode, a keys combination or whatever, that temporarily disables wirting flow and allows navigating blocks with arrows.
• Screen readers on Windows should enter 'focus mode' for this to work to stop intercepting arrow key presses. This leads us back to the discussion of an appropriate ARIA role to use for the canvas.

[talldan]

yes it is true that Pressing Enter on an item in the List View moves focus back to the selected block in the canvas. That is helpful but still not very discoverable as it's a non-standard, unexpected interaction.

What part about it is non-standard? Is there any way we can improve this?

Something I noticed testing it is that it doesn't announce paragraph content the same way navigation mode did, so this is perhaps one thing now lost. Every paragraph is announced as 'Paragraph'.

It's close to the mechanism some ARIA patterns provide e.g. tabs, frid, tree, where there's only one tab stop and navigation is implemented by arrow keys. If there's agreement on such a mechanism we could certainly propose it.

This still sounds to me exactly like List View, which already implements the roving tab index and uses arrow keys. The only difference is that the escape key would initiate it.

[afercia]

This still sounds to me exactly like List View, which already implements the roving tab index and uses arrow keys.

Yes, and we are discussing to add that mechanism in the canvas.

[talksina]

Hello, so, let's say that - as far as I know - Gutenberg is the very first example of accessible page builder I've had in hand; so I'm not able to give you any "best practice" solutions for any effective mechanism, or something similar, as most editors I have used do not use blocks. This is an innovative approach which needs the best attention to make it the most accessible one.

Previous mode

I actually found that this transforming blocks in buttons, like it was in former "select mode", was far from perfect because it didn't correctly manage complex structures built through nested blocks; if you had a group, containing a columns block which contained other kinds of nestings such as quotes or lists, or simply a group block nesting paragraphs and lists, I hardly got correct indications on where I was because screen reader's focus didn't always follow me or make me aware about which level in the nesting it was; I had the sensation of finding myself in a solution which was projected BEFORE nested blocks came in developers' mind and it worked as a miracle. And from the discussion I understand that my sensation was the right one.

Roles and practice

You talk about roles, well, I know that an ARIA role which manages interaction mode automatically is the role="application" - in that case screen reader behaves like it would do in a Windows app, to know what I mean take a look at the qcsalon.net web based games interface. Far from what we all want, but it's an accessible complex game set which has a chat too. Unfortunately I'm not a coder so I have no idea of how it is made and how something similar could be implemented in a structure like the one we have in Gutenberg.
I have even seen editors which do not have screen reader support at all - they have some keyboard combinations but Braille and voice do not even follow you when you write, Dropbox papers is a WORST practice.

Idea for the future?

Let me give you the basic idea of how I'd like it to behave, then you coders might find if something can be done, or come even close to it.

Writer's perspective:

What does a writer want? Being able to manage their content without moving their hands from keyboard, remaining focused on the "blank sheet".
As far as I have learnt, Gutenberg's interface is built in 3 parts:

• toolbar where you have formattings and options;
• canvas main part where you create;
• block settings which change according to content. Text, image, and so on.

In toolbar when you select an option, most times it returns to Canvas and this is the correct way to go. It also describes the keyboard shortcuts - despite there are some problems already discussed in other issues regarding descriptions when moving blocks.
Then, list view, you can open it by pressing its specific keystroke but then it rarely goes back to canvas when you select a block. Not sure if block-related keystrokes work then, such as ctrl+g to group, ctrl+alt+shift+t or y to move a block or multiple blocks upwards or downwards, etc.
And we finally have block settings.
You can't rapidly go to them, from the canvas! Yes Tab helps but if you have many plugins -such as SEO plugins- while editing, you get lost among controls before reaching what you need.

I completely agree on the fact to have keyboard features accessible even to sighted, and even to other assistive techs than screen readers; my idea for basic mechanism to manage blocks would be a toggle switching from navigation mode (list view?) and editing mode. Then both in navigation and editing mode you can do whatever you want from the blocks, from moving to grouping and so on.
Should it be a grid, a list, whatever, the grid mode would be like a chess board...
My old chess computer game had a grid and to move a piece you pressed space bar, then moved upwards or downwards or wherever it was permitted, and space bar again to place the piece where desired.
Then I am thinking of navigation/selection mode - like Excel cells, you press f2 and edit the current block...
Sorry, I am quite in brainstorming mode.
Just my half a cent.

[afercia]

role="application"

Just a quick note: yes, role="application" has been discussed at length. It comes with its drawbacks which may be pretty impactful.
Old post by Marco Zehe about role application: https://www.marcozehe.de/if-you-use-the-wai-aria-role-application-please-do-so-wisely/. Support has slightly improved since then but still it's a problematic role.

[alexstine]

I think we'd have to use role="application" if we were going to create something like @talksina describes above. The issue becomes, modern Windows screen readers really suffer with some other roles and if we want to totally ensure keyboard events go to JavaScript, that would be the best way at the time of my writing. The grid role might be an okay fit but I've heard it still lacks some support so need to research that further.

[talksina]

Yeah I have not too many use cases in hand, but the "application" role I'm certain works quite well with JAWS but about other platforms I'm not so sure. An issue I noticed with "role application driven" interfaces is that if you have much readable information out of focus's range, for example non-interactive texts, "application" role manages quite well the focus mode, and doesn't read the rest. So you'd be force to fill the editor with "toast messages" like the one "draft saved" / "article updated" which tells you your content's condition when you perform a "save" action. Maybe that "application" could be reliable for some components but not for a delicate interface like this one.

[alexstine]

I was thinking we conditionally render the role="application" around the navigation grid vs. having it always there. If we wanted it always there, best option would probably be to wrap it around the iFrame like classic editor does. In theory, this plus removing document role from every block should make the block focus experience far better. This work has been discussed elsewhere but no one has had time to iron out a solid POC.

[afercia]

The grid role might be an okay fit but I've heard it still lacks some support so need to research that further.

I'd recommend to test the grid role first. If support is good enough that would be preferable. Latest data on a11ysupport report that the part we're mainly interested in is well supported, see the section 'Expectation: switch to interaction mode'. It appears JAWS and NVDA have good support. Only Narrator with Edge is reported as having no support.

I was thinking we conditionally render the role="application"

I was thinking at that as well. It could be something worth testing but I'm not sure all screen readers would work well when setting and removing the role dynamically. In my experience, that rarely works well.

[alexstine]

@afercia Do we care about Narrator? If so, maybe we need to figure out another role to use? I don't think Narrator will ever be a serious screen reader but I also feel uncertain about saying that considering there are probably some people out there that use it.

[talldan]

Yes, and we are discussing to add that mechanism in the canvas.

@afercia (or anyone else) Would you be able to explain why having this mechanism in the canvas as well as List View is beneficial? Particularly, what does it offer that List View doesn't? I've read through the thread, but it seems to have moved into solutions quite quickly, and I'm still trying to understand the motivation.

There are a couple of things that I think happened before that would be good to avoid:

• The editor ends up with two similar systems, but with one being neglected, and a lack of consistency.
• Users still opting to use List View after implementing a new canvas based mechanism.

I also would say that if there are issues with List View that prevent it from being used, like block selection not transferring focus back to the canvas, these are things that should be investigated and fixed. Possibly the problem is when trying to select an already selected block in List View that focus isn't transferred? I can't see any existing issues related to this.

[alexstine]

@talldan That focus issue with a block already selected has been a problem for a long time. I thought I had logged something but GitHub search is terrible. If I did, I can't find it. If not, well, that answers that. I started investigating it and it seemed like the function used to focus only got called on block select or something like that... I remember at one point trying to fix it but couldn't ever figure out how to refire once the selected client ID was already set.

[talldan]

@alexstine I've made an issue for that problem - #66276