Improve the toolbars roving tabindex

[afercia]

Describe the bug

One of the most remarkable accessibility features in the block editor shipped with WordPress 5.5 is the ARIA toolbar pattern, accompanied with the "roving tabindex" implementation. See #3383 and the various related PRs https://github.com/WordPress/gutenberg/pulls?q=is%3Apr+roving+tabindex+is%3Aclosed

I'd like to propose to further improve the "roving tabindex" behavior to make it persist after a toolbar disappears and then reappears. Typically this applies to the block toolbars, which appear and disappear based on various conditions. It may apply to other implementations as well where the behavior should be considered on a case by case basis.

What happens now:
The "roving tabindex" does not persist after a block toolbar disappears and then reappears (potentially happens on other implementations as well).

Why it matters
I'd tend to think there are two different cases of "disappearing / reappearing" behavior of the block toolbars:

1. the "disappearing" is triggered by an explicit user action meant to stop editing: for example the user press Escape to switch to "navigation mode"
2. the "disappearing" is triggered by a behavior of the block itself, not a user action meant to dismiss the toolbar, for example: the user starts typing into the block content

I'd tend to think that at least in the second case the "roving tabindex" should persist.

To reproduce

To reproduce a typical scenario:

• edit a paragraph block
• using the keyboard, move the caret at some point in the middle of the content or make a selection
• press Shift + Tab to jump back to the block toolbar
• press the Right arrow key a few times to focus the "Bold" button
• press Tab to jump to the content
• type something: as soon as you type, the toolbar disappears
• press Shift + Tab: the toolbar reappears
• however, focus is on the block switcher button: the roving tabindex didn't persist
• as a user, I'd expect focus to be on the "Bold" button, that is: where it was when I left the toolbar

Animated GIF to clarify the current behavior:

Worth noting in the ARIA authoring practices the roving tabindex example on the toolbar at https://www.w3.org/TR/wai-aria-practices-1.1/examples/toolbar/toolbar.html assumes the toolbar is always visible. I don't think there's a specific recommended behavior for the case when a toolbar disappears and then reappears.

However, to me it make sense to make the roving tabindex work also in these scenarios where the user didn't explicitly dismissed the toolbar, as it seems the most expected behavior.

/Cc @diegohaz

[diegohaz]

Just to add some technical context here: the currently active item state lives in the Toolbar component and it's lost when the component gets unmounted. My initial idea is to keep track of active items in block toolbars in a context up in the tree and hydrate the toolbar state when it gets mounted again.

[afercia]

I have an alternative proposal. Considering that the continuous appearing / disappearing of parts of the UI is a huge accessibility problem (as reported several times by the accessibility team) what about to just not continuously mount and unmount the toolbar when the block is selected? 😆 Ideally, for accessibility, the toolbar should always stay visible. I know, I know...

[diegohaz]

@afercia Yeah! That's also a good option. I'll see if it can affect other parts of the app.

Edit: I mean, avoiding unmounting the toolbar would also fix the issue as the state wouldn't be lost. As for the visibility state, for screen readers, we could potentially make it visually hidden only? I guess we could do this without needing a design change? Is there any issue discussing this design already?

[afercia]

Agreed avoiding unmount/remount would be interesting to explore.

Regarding the visibility part, I was a bit provocative in my previous comment 🙂 However, it is true the accessibility team pointed out several times that the continuous appearing and disappearing of some user interface parts is a huge problem for some users. I do realize other users may e perfectly comfortable with that. I tend to think this is one more case where, as work on Gutenberg progresses, we get more and more aware that one specific user interface behavior may not suit the needs of all users. We already introduced some user settings to provide alternative behaviors, see for example the option to disable WritingFlow ("Contain text cursor inside active block" in the Options modal). The WordPress philosophy "decisions not options" should maybe be taken with a grain of salt and where an option does add value for users I don't see why it shouldn't be considered. In the past, the accessibility team asked a few times to have an option to make the block toolbars always visible when the block is selected. There's no specific issue for this though. I do think that giving users the ability to choose the toolbar behavior would solve lots of problems.

[diegohaz]

I see. Thanks for the clarification!

Making the toolbar only visually hidden, but still accessible to screen readers, would not only fix this issue, but also allow screen reader users to quickly navigate to toolbar options using the rotor or similar tool when the top toolbar setting isn't activated.

I still don't know how challenging this is from the technical perspective. It's surely not as easy as my first suggestion, so depending on the urgency we might be better tackling it that way first. But, if it makes sense from the accessibility perspective, I think we can explore this idea without having to enter in a bigger design discussion.

[afercia]

Making the toolbar only visually hidden,

I meant a user setting to make it really visible 🙂 Having the toolbar always visible may benefit many users, not just screen reader users. But yeah, I'd agree it should be explored separately.