Block toolbar should always display all buttons

[folletto]

When switching a block to and from lists the typing focus is lost so it's not possible to immediately start typing. The toolbar also seems getting stuck in a sort of intermediate state.

1. Create an empty paragraph block
2. Switch to block list

Two problems:

1. Once switched it should allow me to start typing immediately, instead the focus is stuck in the switcher control.
2. The toolbar is stuck in an odd "empty state" so it's not even possible to switch immediately from bullet to ordered list.

[mcsf]

This seems generalisable to switches across most block types, not just List.

[folletto]

Yeh possibily! I could verify clearly there but I haven't extensively checked all of them :)

[priyankabehera]

Hi @folletto

This issue is generating in switching between list to quotes block but currently in WordPress 5.0.3 not generating with the list to paragraph block switching.

[afercia]

Re: the focus part, there's already a more general issue, see #6336. Inconsistent behavior of focus depending on which toolbar buttons are clicked:

When clicking or pressing Enter on some buttons, for example the alignment buttons, focus stays on that button. Instead, when activating other buttons, for example bold/italic/strikethrough, focus is moved back to the editing area.

The "toolbar empty state" was discussed previously but I don't think there's a specific issue to track it down. It's something that happens with all the blocks and particularly evident when using the keyboard.

Basically, besides the switcher and ellipsis that are always displayed:

• when the block container is focused, the toolbar initially displays only some buttons (these actually vary depending on the block type)
• when the block editable area is focused, the toolbar displays all the buttons

GIF to clarify:

I guess this behavior kicks in also when changing block type.

This was an intentional design decision. Can't find right now what the argumentation in favor of this behavior was, maybe @mtias or @jasmussen know.

However, there was no consensus and the current behavior is problematic for accessibility, as the additional buttons are revealed only when users have already tabbed away from the toolbar.

Also, it happens only the first time. When tabbing again through the blocks, all the buttons are displayed.

I don't see a great value in the current behavior, really not sure what the advantage is. It is potentially confusing for users. There are also unexpected consequences when switching blocks, as this issue reported. Overall, I'd recommend to reconsider the current behavior and keep things simple: just display all the buttons by default.

[afercia]

@folletto any objections to changing this issue title to address only the second problem? For the first one, there's #6336.

[folletto]

I think it's sensible to change yes — as long as #6336 has "focus back to the editing area" as proposed solution. :)

[jasmussen]

This bug has been annoying for a while, good ticket. Look forward to have this fixed.

[ellatrix]

This is because the rich text buttons are only displayed when the rich text element is selected. RichText shouldn't be dependent on the selection state of the block? Not sure how to fix.

[jasmussen]

This is because the rich text buttons are only displayed when the rich text element is selected. RichText shouldn't be dependent on the selection state of the block? Not sure how to fix

Can we show them as "grayed" until you set focus in the rich text?

[ellatrix]

@jasmussen It's a harder issue :) Imagine you have multiple rich text fields in one block. Only one can be selected at a time, so only one toolbar appears. The selected rich text field's toolbar. If we were to display it whenever the block is selected, you'd see multiple rich text toolbars.

To be honest with you, I would rather move the rich text toolbar inline to be displayed when the user selects text. Of course, short cuts still work for unselected text, but the rich text buttons cannot do anything anyway when there is no text selected. When there's just a caret, they should be greyed out as well. Moving them inline would also make the UI less heavy, and it would solve some scaling issues for rich text UI. At the moment I cannot add a more button to the rich text toolbar because there's already one for the block right next to it. :(

I would really consider again to move the rich text toolbar inline.

[afercia]

the rich text buttons cannot do anything anyway when there is no text selected. When there's just a caret, they should be greyed out as well

I'm afraid this is one of the features that miss parity with the Classic editor. For example, in Classic it's possible to bold a word even just putting the caret within the word.

move the rich text toolbar inline to be displayed when the user selects text

That would create challenges for keyboard interaction and accessibility, we've already seen inline toolbars are not so great in that regard.

If we were to display it whenever the block is selected, you'd see multiple rich text toolbars.

Pretty sure I'm missing something, but to my understanding the Quote block has two RichText and just one toolbar. How does that work?

[ellatrix]

I'm afraid this is one of the features that miss parity with the Classic editor. For example, in Classic it's possible to bold a word even just putting the caret within the word.

This is inconsistent across editors. See #9183 (comment).

That would create challenges for keyboard interaction and accessibility, we've already seen inline toolbars are not so great in that regard.

How does it differ from the current experience? You'd access the toolbar the same way you do now.

Pretty sure I'm missing something, but to my understanding the Quote block has two RichText and just one toolbar. How does that work?

Doesn't it suffer from the same issue?

[afercia]

Let's clarify "inline toolbar" do you mean when there's a selection, both the block toolbar and an inline toolbar are visible? Something like in the screenshot below, where the grey area would be the inline toolbar:

Besides visual challenges, e.g. the inline toolbar can overlay the block toolbar if the selection is on the first line, how keyboard interaction would work? How users can move to the inline toolbar?

Alt + F10 / Escape would be the only way. Instead, right now users can also shift+tab to go to the formatting controls.

Also, what if there's a selection but I actually want to go to the Block toolbar? Alt + F10 / Escape would move focus to the inline one, preventing me access to the block one. Then. each time I should first deselect any selection, then use Alt + F10 / Escape and remember each time Alt + F10 / Escape has a different behavior depending on if there's a selection or not. That would be complicated even for sighted users 🙂 and terribly complicated for assistive technologies users.

Doesn't it suffer from the same issue?

Yes, but the Quote block has just one toolbar. Not clear to me how it would differ for other blocks, unless by "rich text toolbars" you meant only the formatting part of the block toolbar?

[ellatrix]

Besides visual challenges, e.g. the inline toolbar can overlay the block toolbar if the selection is on the first line, how keyboard interaction would work? How users can move to the inline toolbar?

The toolbar would appear under the selection, just as we place the link toolbar.

How does keyboard interaction work right now? With tab? I'd propose to have it work the same way.

Also, what if there's a selection but I actually want to go to the Block toolbar? Alt + F10 / Escape would move focus to the inline one, preventing me access to the block one. Then. each time I should first deselect any selection, then use Alt + F10 / Escape and remember each time Alt + F10 / Escape has a different behavior depending on if there's a selection or not. That would be complicated even for sighted users 🙂 and terribly complicated for assistive technologies users.

Ah, here I have the answer. It's Alt + F10? In that case, tabbing would go through both the block toolbar and the inline toolbar, just as it works now?

[afercia]

Hm not sure. I'd tend to think this needs a bit more pondering.

There are already issues with multiple toolbars displayed at the same time, see for example #5840 / #10699. Also, focus behavior is inconsistent, see #6336. Also, the continuous appearing / disappearing of the toolbars is one of the main accessibility concerns in the blocks, the new interaction would add more appearing / disappearing behaviors.

tabbing would go through both the block toolbar and the inline toolbar

First thing that comes into my mind: when a block has long content, and selection is at the bottom of the block, tabbing through the two toolbars would make the page scroll. Also, visual order and DOM order would not match.

[folletto]

This is because the rich text buttons are only displayed when the rich text element is selected. RichText shouldn't be dependent on the selection state of the block? Not sure how to fix.

Sorry if I rewind a bit the conversation to this.

If the above is the case, then just making sure the selection goes back to the text area should avoid the toolbar to end up in that middle-state for most of the editing scenarios, no? Have I missed something?

[afercia]

We've missed the initial focus issue on the block. Aside: initial focus is something that needs a better pattern as the blocks have different content and beheavior. Regardless:

• on a default block like a paragraph: tabbing goes first to the wrapper (formatting buttons hidden) then lands to the RichText and the formatting buttons suddenly appear. Weird and problematic for a11y, because users may not have a clue something that previously wasn't there is now available...
• custom blocks may have different content: for example a block that has a button or a select first and then a RichText: in this case making the formatting buttons appear immediately would be weird as they pertain to the RichText, not to the first focusable things within the block

So there are conflicting needs here. At the moment I have no great ideas.

[folletto]

not to the first focusable things within the block

This could be the thing... one principle in accessibility is always knowing where the caret is, and (this is a bit of wild architecture ideas I'm borrowing but might not be feasible in the current Gutenberg architecture) if we could create a correlation where the first item to be tabbed is also the one having focus and is also the one that shows the toolbar by default, we could achieve all the focusing goals, the right toolbar, and the right tabbing at once.

That said I'm not sure how feasible it is in this architecture, but maybe it can give others a better idea... ;)

[paaljoachim]

Testing with WordPress 5.7 beta 3 and Gutenberg plugin 10.
Twenty Twenty One.

Switching between paragraph <-> list one can now immediately begin typing.

I will go ahead and close this issue. Please reopen if I am mistaken.