Locked block toolbar layout broken when 'Show button text labels' is enabled

[afercia]

Description

When the 'Show button text labels' preference is enabled, a locked block toolbar doesn't look right.

There's no separation between the block switcher button and the unlock button. Visually, it's pretty confusing. Also the paddign on the left is incorrect.

Step-by-step reproduction instructions

• Lock a paragraph block:
  • From the block toolbar > Options > Lock > Lock all > Apply
• The block toolbar now shows the 'unlock' button after the block switcher:

• Go to the editor Options > Preferences, and enable 'Show button text labels'.
• The block toolbar now shows text labels instead of icons.
• Observe there's no sepaaration between the first two buttons. Also, the left padding looks bigger than expected:

• It happens also with 'top toolbar' enabled:

For reference, here's how the block toolbar looks when the block is not locked:

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

[annezazu]

@tellthemachines curious if you could dive in here as I know you've done some fixes on the text label experience <3

[joedolson]

This is coming from this CSS:

.block-editor-block-lock-toolbar .components-button.has-icon { padding-left: 0 !important; }

It's removing the left padding on the lock button, which you can see has compressed spacing both when using icons and using text; but it makes a much bigger difference to comprehension when viewing as text.

Separately - is it necessary for that button to contain the block name? That context should already be apparent, since the neighboring button gives the context. Seems unnecessarily verbose.

[Mamaduka]

Created PR to resolve styling issues.

Separately - is it necessary for that button to contain the block name? That context should already be apparent, since the neighboring button gives the context. Seems unnecessarily verbose.

I like the idea and am happy to create PR if everyone agrees on the change.

[afercia]

Separately - is it necessary for that button to contain the block name? That context should already be apparent, since the neighboring button gives the context. Seems unnecessarily verbose.

I'd agree to try to remove the block name. However, I think that button needs a few more improvements so yes I'd recommend a separate PR.

Regardless whether it's icon or label, when a block is locked that button gets disabled with both a disabled attribute and aria-disabled="true".

That's not ideal because the button can't be navigated to with the keyboard. As such, there's no contextual information for screen reader users (although screen readers do provide alternative ways to get to that button).

In several places in the Editor we do use a different pattern to keep disabled controls discoverable. See Focusability of disabled controls in the ARIA practices.

To recap:

• The block toolbar is an ARIA toolbar.
• Expected keyboard interaction: navigation through the toolbar buttons is by arrow keys.
• However, the 'Paragraph' button is not focusable because of the disabled attribute: the button gets skipped when arrowing.
• Screen reader users will miss that context.
• To remediate:
• The button should only use aria-disabled="true" and be 'noop-ed`. We should make sure that arrow navigation works on this button.
• When the block is locked, the button should also look disabled. Currently, it doesn't.
• The icon button should still display its tooltip.
• The tooltip should not be displayed when 'Show button text labels' is enabled.

[Mamaduka]

I created a separate PR to make the button label less verbose - #51083.

@afercia, the block switcher button can be disabled for other reasons as well, so it's not tied to block locking. If you prefer, we can open a separate issue.

When the block is locked, the button should also look disabled. Currently, it doesn't.

The button also serves as a visual clue for the block type; this is probably why disabled styles aren't applied.

[afercia]

Thanks @Mamaduka! I will create a separate issue for the disabled state.