Keep the selected block in a selected state when switching the sidebar to Document

[afercia]

When a block is selected, it stays in the selected state also when operating on other parts of the user interface. It is possible to click on any part of the sidebar or top bar, and the block is still selected.

For example, it's possible to activate menus in the top bar, and the block is still selected:

This is actually a good thing: the interaction with the block is consistent and predictable. There are no assumption in the UI behavior and the block selected state is in the users full control.

There's one relevant case where this is no longer true: when clicking the sidebar "Document" tab, the selected block loses its selected state.

To better clarify, I've made a GIF:

For mouse users:
it's maybe a minor annoyance but worth considering they have to move their mouse to the block, click into it to make it "selected" again, and move their mouse back to the sidebar again to be able to operate in the "block inspector" settings.

For keyboard users (including screen reader users, switch control users, etc.):
it's a serious breakage of keyboard navigation. Just imagine this flow:

• a block is selected
• users jump to the sidebar, either by using the Ctrl + backtick shortcut or using the navigation tools their assistive technology provides
• users switch the Sidebar to "Document" to explore its content or for any other reason
• they then switch the Sidebar to "Block"
• at that point, the block is not selected any longer and the inspector is empty
• to be able to operate again on the block settings, users have to tab multiple times through the whole editor interface to go back to the block and select it, which is a challenging task especially when there are many blocks
• then, they can finally jump again to the sidebar

As reported by the accessibility team, keyboard navigation between the content area and the sidebar is one of the main barriers for users with accessibility needs. Gutenberg should strive to make navigation through content as easy as possible.

Personally, I'm not sure there's even a good reason why the block should not be selected when the sidebar switches to "Document". I'd tend to think the block selected state should be completely independent from the Sidebar state.

Ideally, the block selected state should always be in full control of the user. The UI behavior shouldn't assume users intent.

I'd like to propose to keep the block selected when switching the sidebar to "Document". I've tried to have a look at how it works, and turned out it's a bit complicated as the sidebar switching logic is actually based on the presence of a selected block. I'd greatly appreciate if anyone with better knowledge of this implementation could have a look at this, as it would be a pretty good accessibility improvement.

[youknowriad]

There has been a lot of back and forth here.

• The proposal here has been tried on the plugin phase and we had feedback that the inspector was not discoverable enough.

• We had an intermediary step where selecting the block, opens the inspector but selecting the document don't unselect the block. It was confusing for users.

I think if we need to change this, we should not be using tabs maybe? but anyway, this needs some design input.

[afercia]

To clarify: I haven't proposed to remove the switching mechanism. That should stay.

However, the block should always stay selected. Unselecting it creates a big accessibility barrier.

It was confusing for users.

I'm guessing the testers group didn't include users with accessibility needs. I'd like to see this community start considering design and accessibility not as two separate things but as two fundamental parts of the same process.

[afercia]

Alternatively:

would it be possible to store a reference to the "last-selected" block and, when clicking again on the Block tab, restore its selected state?

[youknowriad]

Thanks for the clarification :). Let's get some feedback and proceed with the PR.

[jasmussen]

The sidebar header area has been through a number of iterations as we explored and responded to feedback. Back in the day, the sidebar header used breadcrumbs: #1429

If you'll permit me to steal the screenshot from that thread:

The behavior of ☝was technically identical to what we have today, but it was just visually more descriptive of what was going on. Essentially the idea is that the sidebar is 100% contextual to what is selected. If nothing is selected, you inspect the document, if a block is selected, you inspect the block.

Having used the tabs for a long time now, it feels like there are some benefits to that older interface, especially in light of recent developments with child blocks, as well as developments that are likely to be explored during phase 2, notably:

• The breadcrumb interface can show the hierarchy of the post/page
• The breadcrumb trail could be made parent-block aware, helping address Enhance the tools for selecting child/parent blocks #9628. I.e. Post → Columns → Paragraph.
• In exploring enhancements to customization, the breadcrumb trail might even include the Site itself as a breadcrumb, so that the inspector can customize that

I understand the goal of this ticket, but because of the above, it seems like the most prudent first step would be a smaller step. The following sounds pragmatic, for example:

would it be possible to store a reference to the "last-selected" block and, when clicking again on the Block tab, restore its selected state?

[kjellr]

Just wanted to leave a note to say that the current behavior is also very confusing on mobile. In this use case, you can't see that the block has been deselected, so when you switch back to the Block tab, it appears that something's broken.

A solution like this one would be really helpful there too:

would it be possible to store a reference to the "last-selected" block and, when clicking again on the Block tab, restore its selected state?

[draganescu]

Commenting here just to second @kjellr, found this ticket as I was about to open another one especially because on mobile is appears like a big bug, not a logical feature for the full screen sidebar :)

[afercia]

is also very confusing on mobile

Yep, for many users with accessibility needs, navigating content is a linearized experience much like on mobile. In fact, it often happens that some designs fail for accessibility and mobile for the same reasons 🙂

[afercia]

especially because on mobile is appears like a big bug

Yep, testing on a real mobile device highlights how much the current behavior is annoying 🙂On mobile, the Sidebar is full screen so it's pretty common to explore its content and click on "Document". Then, when clicking back to "Block" the sidebar is just empty.

See the screenshot below and imagine the following user flow:

• user is editing an image details (screenshot on the left)
• clicks on "Document" then on "Block"
• the sidebar is now empty (screenshot on the right)
• to continue editing the image details, user now has to:
  • close the sidebar
  • select the block again
  • click on Block Settings again

@gziolo (pinging you as you've asked for some accessibility actionable items) would be great to help this issue move on, when you have a chance. Thanks!

[gziolo]

(pinging you as you've asked for some accessibility actionable items) would be great to help this issue move on, when you have a chance. Thanks!

Thanks, @afercia. I appreciate your ping. I added it my personal backlog to ensure I have it tracked. I might not have time to work in it in the upcoming 2-3 weeks, but I can assist everyone who volunteers to work on it :)

A solution like this one would be really helpful there too:

would it be possible to store a reference to the "last-selected" block and, when clicking again on the Block tab, restore its selected state?

Yes, it seems like a good proposal and shouldn't be that difficult to implement. The related logic was introduced in this PR #6936.

[gziolo]

We paired today with @draganescu to explore the proposed solution. There is one use case we wanted to confirm before we finalize the proposal. Should all types of selections be restored when switching from Document to Block settings? In particular:

• multiple blocks selected
• single block selected with text selection in RichText component

My feeling is that it would be great to cover all those use cases but I'm fine with whatever comes out from the discussion.

[kjellr]

Should all types of selections be restored when switching from Document to Block settings?

Yeah, I think all types of selections should be preserved if possible. That way the behavior is consistent all the time.

[draganescu]

This now has an open PR that fixes it, but I am not sure if all cases are covered. We'll see after it gets a review :)

[afercia]

@draganescu @gziolo thanks for working on this and for merging #15583 🙂It's a step in the right direction. I see two problems though.

1

• click on a block to select it
• the sidebar correctly switches to "Block"
• click the Block "tab" in the Sidebar header
• the Sidebar switches to "Document"
• expected: the Sidebar to stay on "Block"

2

• test using the keyboard
• navigate to a block to select it
• use the Ctrl + backtick or the alternative Control + Option + N shortcuts to navigate through the main regions and get to the Sidebar
• press the Tab key to focus the "Document" tab and press Enter
• the Sidebar correctly switches to "Document", focus stays on the "Document" tab
• press the Tab key to focus the "Block" tab and press Enter
• the Sidebar correctly switches to "Block"
• however, focus is moved to the previously selected block
• expected: focus should stay on the Sidebar "Block" tab

I do realize that probably the term "selected state" of the block can be source of confusion but the main point of this issue is that yes: the block should return to its original "selected state" but the focus should stay on the Sidebar tab.

The fact focus gets moved away would be completely unexpected, as users are operating on the Sidebar tabs and focus should stay there.

[afercia]

Minor: in the console, I see:
"Warning: React does not recognize the wipeSelectedBlock prop on a DOM element."

[gziolo]

I could reproduce all issues, thanks @afercia for raising them 😅
Let's try to fix them by Friday all revert PR otherwise.

[draganescu]

Hi @afercia great finds, I was laser focused on "restoring selection" and didn't account for the focus too. I will redo this PR with a different approach suggested by @aduth and also keep in mind your points here!

[draganescu]

@afercia #18621 removed the clearing of selection on siderbar switch. So instead of preserving selection, we simply don't clear it anymore. This I believe solves this issue, while also not introducing any more complexity.