Regression: the new Block Inserter doesn't constrain tabbing

[afercia]

Describe the bug
The new Block Inserter doesn't constrain tabbing with the Tab key.

In the old one, tabbing was constrained. Although we're not treating the Block Inserter as a modal, I think the previous behavior was beneficial. Not sure about the reasoning behind the removal of the tabbing constraining. I'd appreciate anyone pointing me to the discussion where this behavior removal was considered.

To reproduce

• test on default WordPress 5.4 block editor first
• open the main block inserter:

• focus is moved within the inserter
• use the Tab key to navigate the inserter content
• see that tabbing is constrained within the inserter: once you reach the last focusable element, focus is moved to the beginning and vice-versa
• activate the Gutenberg plugin, right now it's version 8.2.1
• open the main block inserter: you get the new one:

• use the Tab key to navigate the inserter content
• by default the inserter displays 70 blocks so you will need to press Tab 70 times
• I'll refrain from expressing usability concerns about the removal of the expandable block groups: having to tab dozens of times, or scroll through a long list of blocks, doesn't seem a great improvement to me
• once you reach the last focusable element, tabbing is not constrained within the inserter any longer (and vice-versa)
• keeping tabbing exits the inserter and moves focus to the rest of the UI, which isn't ideal

Expected behavior
Tabbing to be constrained.

Editor version (please complete the following information):

• WordPress version: 5.4
• Gutenberg plugin 8.2.1

[afercia]

I consider this an accessibility regression and I'd like to kindly ask to not release the new block inserter in this state in WordPress 5.5. The constraining behavior should be restored first.

[afercia]

Noting that this applies to the "Patterns" tabs as well.

[mapk]

@afercia I'm hoping to understand this one further. In the previous Inserter, it acted like a popover and constraining the tabbing worked well. In the current release, the Inserter is now a panel in which case would operate like other panels in the UI (ie. the Settings sidebar). The Settings Inspector does not constrain tabbing.

Do panels require tab constraining to meet accessibility guidelines?

[afercia]

Related core ticket just reported on the core Trac. Reporting here to highlight the fact if the new behavior can be confusing for mouses users, just imagine how much can be confusing for keyboard users and assistive technology users:

Browse All Blocks sidebar missing close feature
https://core.trac.wordpress.org/ticket/50725

[afercia]

The accessibility team considers this issue a regression in the accessibility level of the block editor compared to WordPress 5.4.

The team discussed this issue during last week's accessibility meeting on Slack and, making an effort for a reasonable proposal given where WordPress is in the release cycle, at the very least we recommend to implement a modal behavior.

This wouldn't solve all the keyboard accessibility issues but it would be a good start. Then, this new implementation should be iterated later to refine and make it as accessible as possible.

[afercia]

It is still unclear to me whether a solution for WordPress 5.5 has been identified.

In absence of a solution, if WordPress 5.5 is released with the current implementation of the main inserter, I'm afraid the accessibility team won't have other options other than considering this an obvious regression in the accessibility level compared to WordPress 5.4.

[youknowriad]

I'm not sure how constrain tabbing is a solution here because if we do that, folks will be able to tab from the outside to inside the panel but once they reach the panel, they'll be trapped there. It seems like it's better for usability to avoid constraining tabbing there to avoid tab traps.

[afercia]

@youknowriad we (accessibility team) are asking for a modal behavior to be reasonable in our request. Should we ask for a complete revert instead? 🙂

What is the solution proposed by the Editor team? I'm afraid "do nothing" wouldn't be an acceptable answer.

[youknowriad]

I think it's more a usability issue instead of an accessibility one. That said, when you design UIs it's always about tradeoffs.

Having a modal is good sometimes but you're giving away usability in some cases as well there for instance:

• If you want to fill the content of the page quickly with several blocks in a row, you will have to open the inserter, insert a block, open the inserter, insert a block. You can see how many tab stops or clicks are needed for that.
• You also give away the possibility to offer drag and drop from the inserter to the canvas which is a very good addition for sighted users.

Having a tab, you're adding some extra tab stops when navigating through the UI.

So no solution is perfect IMO and it's a tradeoff in all cases. So my question would be, what's the best to design UIs that can be hidden/shown and these UIs are not popovers/modals, they are just part of the UI of the page? We already have this kind of UIs in the editor (the document settings) and we added the inserter now. I don't think these UIs are inaccessible by essence but I'd love to learn to improve their usability as much as we can.

[afercia]

I think it's more a usability issue instead of an accessibility one. That said, when you design UIs it's always about tradeoffs.

Nope. The fact that some elements that are in the tab sequence are "skipped" when exiting the inserter is an accessibility
(and usability) issue, not to mention visual/reading order and DOM order don't match.

Regarding your question, we (accessibility team) objected to the mismatch between the orders since the very first "popover" implementation and always outlined that's an accessibility anti-pattern. For accessibility, any UI that "appears" in the page, whether it's an expandable panel or sidebar, needs to come directly after the control that opened it. Otherwise, it needs to be treated differently, implementing a modal behavior. This has always been oru recommendation.

[afercia]

Related issues that highlight some confusion from users for this new UI:

• Inserter: Its not obvious how to close the inserter #22871
• https://core.trac.wordpress.org/ticket/50725

[afercia]

Thanks for #24429 🎉

I'll create a new issue to evaluate other potential accessibility problems of the new inserter implementation. As mentioned above in #22858 (comment) the lack of constrained tabbing was only one of the issues. There seem to be other accessibility concerns that would need to be better evaluated and tested by the team.

... at the very least we recommend to implement a modal behavior.
This wouldn't solve all the keyboard accessibility issues but it would be a good start. Then, this new implementation should be iterated later to refine and make it as accessible as possible.