Experiment with the toolbar pattern

[oandregal]

Closes #15331.

This a proof of concept to reduce the number of tab stops to navigate through the app with the keyboard.

It proposes to adopt the WAI ARIA's toolbar pattern (see example) to move through the block toolbar (could be extended to other parts of the app):

The GIF doesn't really does justice, but the fundamental idea is that:

• TAB and TAB+SHIFT move focus in and out the toolbar.
• Arrow keys are used to navigate within the toolbar.

Please, understand that this a Proof Of Concept: it's buggy and by no means is ready code-wise. Wanted to share early to gather feedback on the direction: is this something we'd want?

[jasmussen]

This seems like a solid approach to reduce tabstops, and it doesn't preclude additional explorations.

I appreciate the adherence to WAI best practices.

There's one aspect to this which becomes slighlty more pronounced somehow:

Notice how inline styles aren't present until the text has received focus first. I believe this is a known issue that @ellatrix has suggested is difficult or even impossible to fix. But it feels somewhat extra interruptive here — are there any "creative" solutions we can think of which mitigate this? Could we make them visibly present even if they aren't active until they receive focus?

[gziolo]

Are you trying to address #15331? It's related to the Editor Top Bar but basically applies to all areas which behave like toolbars.

Keyboard-only users who enter the Editor Top Bar must Tab from button to
button. Although this is manageable when there's a small number of
buttons, the group of buttons is given the role of toolbar, whose
purpose (besides grouping related controls) is to lessen the number of
Tab stops keyboard users must make to navigate past widgets.

Screen reader users may be told they are entering a toolbar and expect
to be able to Tab past everything in it. Their experience does not match
the promise of the role.

[gziolo]

Notice how inline styles aren't present until the text has received focus first. I believe this is a known issue that @ellatrix has suggested is difficult or even impossible to fix. But it feels somewhat extra interruptive here — are there any "creative" solutions we can think of which mitigate this? Could we make them visibly present even if they aren't active until they receive focus?

@jasmussen, are you referring to buttons which are rendered to operate on RichText?

[gziolo]

It looks like role="toolbar" is already there without this patch. Behind the scenes, there is NavigableToolbar component used which adds the role and arrow key interactions.

[jasmussen]

are you referring to buttons which are rendered to operate on RichText?

Here's a more specific GIF:

Note how if I click inside text, the inline toolbar is immediately present. Whereas if I tab to a text block, it isn't until focus is set in the text that the inline toolbar becomes present. And to be clear, this is the case already in master, it just feels a little bit more pronounced in this branch.

Like I said, I recall this as being one of those things maybe we cannot fix — perhaps it's something about the rich text component not being initialized until text actually has focus.

[gziolo]

Note how if I click inside text, the inline toolbar is immediately present. Whereas if I tab to a text block, it isn't until focus is set in the text that the inline toolbar becomes present. And to be clear, this is the case already in master, it just feels a little bit more pronounced in this branch.

Yes, it's all correct and very expected as this RichText toolbar is only present when it's focused. There are several reasons why this needs to work this way. One of them is that when you have more complex blocks you can tab to the element which isn't RichText at first so it shouldn't show this toolbar. The other reason is that those buttons won't work until RichText has text selection. Honestly, I'm not sure this is something that can be easily solved with the current UI. Well, the solution would be to never show the block toolbar until you start editing block's content :D

[jasmussen]

One of them is that when you have more complex blocks you can tab to the element which isn't RichText at first so it shouldn't show this toolbar.

Thank you for the technical explanation, it makes total sense.

One of the reasons I think it's a UI worth talking about, is that once the inline toolbar is loaded, it stays there until you deselect. This makes it feel buggy and summons questions like "why isn't it present now? oh there it is, how did it arrive?".

For the Classic Block we did something interesting — we basically initialized TinyMCE only when the block was first focused. Until then, the toolbar simply says "Classic".

When Facebook first loads, there is a "skeleton loading" feature that shows gray blobs until the content replaces it and fills it in.

Inspired by those ideas, could we do the following? For blocks that have the inline toolbar when selected, could we always have that inline toolbar present, but grayed until initialized? We could even make it so focusing that part of the toolbar would instantiate it.

[gziolo]

Inspired by those ideas, could we do the following? For blocks that have the inline toolbar when selected, could we always have that inline toolbar present, but grayed until initialized? We could even make it so focusing that part of the toolbar would instantiate it.

What if the block contains other form controls which gets focus but don't use toolbar controls and RichText is the very last component in the block's hierarchy? What if there are 2 RichText controls with a different set of controls? It's all very difficult to handle knowing that you can't predict how 3rd party blocks will be composed.

[gziolo]

I did some further investigation and I think we would have to wrap the toolbar with the NavigableContainer to allow arrow keys navigation. At the same time, I think it doesn't prevent you from tabbing which seems to be wrong in general. So this might require some 2 PRs to make it work.

We can also see how it's implemented in https://reakit.io/docs/toolbar/ where it is much more flexible in terms of what items can be added as a toolbar item.

[oandregal]

Closing in favor of #17875