Components: Add accessible Toolbar

[diegohaz]

Description

This PR is a simpler version of #17875. It adds an __experimentalAccessibilityLabel prop to the Toolbar component in @wordpress/components. If this prop is passed in, then it will render an accessible toolbar. Otherwise, it'll fallback to the current toolbar on master (which is not actually a toolbar) that has been renamed to ToolbarGroup.

This Toolbar only accepts ToolbarButton as toolbar items. ToolbarButton is currently an enhanced IconButton, but it should be improved in a follow-up PR.

With this, projects using @wordpress/components could start experimenting it for simple toolbars.

Story

1. This PR

2. Improve ToolbarButton so that it serves more use cases than just being an IconButton.

   At this point, the Gutenberg header toolbar (without the fixed block toolbar) could use it.

3. Refactor SlotFill so we won't need to force fills to re-render when fillProps change.

   At this point, block toolbars could start using it.

4. Convert the fixed toolbar buttons (block switcher, more tools etc.) to ToolbarButton.

   At this point, custom blocks could start using it, as long as they use ToolbarButton inside BlockControls or BlockFormatControls.

5. Convert core block toolbars.

   We could convert one per PR (for example, start with the Paragraph toolbar).

6. Let it be for a while.

7. If it proves to be useful and works out, deprecate the old usage and remove the __experimental prefix. Otherwise, revert it altogether, which would break the code for people using __experimentalAccessibilityLabel explicitly, but custom blocks would seamlessly rollback to the old usage.

Related: #15331 #3383 #16514 #17875

How has this been tested?

1. Run npm run storybook:dev
2. See the different Toolbar stories

Screenshots

Types of changes

New feature

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR. .

[gziolo]

I did a very quick pass through PR and left some feedback with minor notes. I hope to find some time early next week to retest the revised toolbar. As far as I can tell, this PR no longer changes the behavior of the block editor itself, it only enables a new toolbar behind the experimental flag. Awesome 👍

Travis reports some failing e2e tests but they are probably coming from master after new blocks were added.

[gziolo]

I need to retest it again after it was extracted to this PR and confirm that the bundle size change is still at 4 kB after GZip. Otherwise, I don't have any more code related comments.

[gziolo]

It works great in my testing. I tested with Chrome on macOS and Safari on iPadOS with the external keyboard. The very last step is to confirm the impact on the bundle size.

[gziolo]

Before:

./build/components/index.js     589 KiB      11  [emitted]  [big]  components

gutenberg % gzip -c build/components/index.js | wc -c
  165507

After:

./build/components/index.js     605 KiB      11  [emitted]  [big]  components

gutenberg % gzip -c build/components/index.js | wc -c
  170005

Result

~16 kB before gzip
~4.4 kB after simulated gzip

which is very close to what @diegohaz shared in #17875 (comment).

[gziolo]

Let's get this PR in, it doesn't change anything in the production code so I think it's safe to proceed. @diegohaz, can you open a parent issue to track all the remaining tasks?

There is one small item to consider there. How about we move packages/components/src/toolbar-context/index.js to be located inside packages/components/src/toolbar/context.js? Well, it might wait until we decide whether we need to expose it. My only concern is that it gives the impression that this is something that could use standalone since it is in the root folder.

There is also README.md missing for the newly introduced ToolbarGroup component. Given that JSDoc comments contain all required defaults, it should be quite straightforward to create a documentation file. A separate story is that it would be nice to be able to auto-generate such files based on JSDoc and Storybook stories :D

[gziolo]

@diegohaz thanks for opening #18619. Let's continue there 👍