Inserter: After inserting a list block, options no longer read

[alexstine]

Description

After inserting a list block, it appears that the DOM is modified leaving only one button. This makes all other block insert options unreadable to screen reader users and possibly not available for all. I would expect the blocks to still be available no matter what is inserted.

Step-by-step reproduction instructions

1. Open a post or page.
2. Select Toggle block inserter in the top bar.
3. Insert a paragraph block.
4. Verify you can still move around in the inserter with left and right arrows.
5. Navigate to and insert a list block.
6. Notice how focus is lost, this PR is fixing that: Fix focus loss due to filtering blocks #61558. Ignore this for now.
7. Place focus back on the inserter and notice how pressing left and right arrows no longer works to move through your available block selections.

Screenshots, screen recording, code snippet

No response

Environment info

Gutenberg: trunk
WordPress: Latest development
Browser: Firefox on Windows, latest

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

[alexstine]

@jeryj Not sure if this bug has been here all along or if the latest rounds of changes introduced this bug. Could you please look in to it? This is a really bad user experience. The only fix I found was to save the post/page and refresh.

[Rcreators]

@alexstine I can confirm that this issue is happening. Adding a List item loses focus. Yet it somehow made an active widget as a list, so in the inserter, you can only see one block which is a list item. So cause there is only one block in the list, you cannot move around with the arrow key.

There are a few issues now that I found in terms of editing experience.

1. I can only add list items to the list but at the same time, I cannot add text to the list items at all without using the mouse.
2. I cannot go to add the next/new block now without using mouse.
3. With Back Tabbing if I close the inserter and open it back, it still has a list as an active widget and I don't get all the other block options without using the mouse.

[jeryj]

This makes all other block insert options unreadable to screen reader users and possibly not available for all. I would expect the blocks to still be available no matter what is inserted.

The list of blocks available for inserting is filtered based on the selected block, so if a list block is selected, only a list item can be selected. I agree this is a bad experience for everyone. I think a better behavior would be to always allow any blocks to be inserted and not filter the list. Unfortunately, filtering blocks based on the selected block is baked into the code on a deep level, so building a new system will be a bigger project :/

@Rcreators

I cannot go to add the next/new block now without using mouse.
You should be able to tab to it. Tabbing to the editor canvas should place focus on the inserted block.

With Back Tabbing if I close the inserter and open it back, it still has a list as an active widget and I don't get all the other block options without using the mouse.

Unfortunately, that is the expected behavior based on the code since the list block is selected. You'll have to select an empty block/placeholder block to get all the available blocks again. I believe you can do this by tabbing to the editor canvas and pressing Enter to create a new block outside of the list block. You may need to use the arrow keys as well. I agree this is a bad experience and all blocks should be available. This is how the code

[alexstine]

@jeryj If you focus the list block and press Enter, wouldn't that simply insert a new list item?

The UX here is terrible, not sure how we ever ended up close to an experience this bad. Especially with no way from the inserter panel itself to view the full list of blocks again or communicate to users the change. This confused me and I'm an experienced engineer. I feel really bad for users that encounter stuff like this. What is the point of keeping the inserter open if there is no way to insert blocks?

Let's pull some leadership in here, these types of bad UX affects everyone in a bad way but especially blind users since it isn't clearly apparent what is going on.

CC: @annezazu @youknowriad @WordPress/gutenberg-design

Thanks.

[youknowriad]

The list of blocks available for inserting is filtered based on the selected block, so if a list block is selected, only a list item can be selected. I agree this is a bad experience for everyone. I think a better behavior would be to always allow any blocks to be inserted and not filter the list. Unfortunately, filtering blocks based on the selected block is baked into the code on a deep level, so building a new system will be a bigger project :/

the inserter has always worked this way. If you insert a block it will be inserted within the selected container. So it's understandable that the list becomes empty if the list block is selected because within a list block you can only insert a list item.

The other option to always insert top level is also not a great experience in some cases, for instance, it becomes very hard to know how to insert blocks in specific positions.

We can obviously rethink these behaviors, but it's not clear to me what the solution is.

[alexstine]

@youknowriad I think a good first step is simply communicating to non-sighted users that the inserter blocks have been filtered to the list block. Then we can figure out how to improve the bigger issue later.

[youknowriad]

I think a good first step is simply communicating to non-sighted users that the inserter blocks have been filtered to the list block. Then we can figure out how to improve the bigger issue later.

Yes, makes sense to be honest, it can be useful for all users to know. It's not specific to non-sighted users.

[jasmussen]

This is definitely an aspect of the insterter that is in a poor state. #60991 is another example, and could likely benefit from the same solution that is suggested applied here. Could use a dev!