Split Settings: No ability to tab or use keyboard shortcuts to get to different sections

[annezazu]

Description

This was found as part of the nineteenth call for testing for the FSE Outreach Program:

While it’s nice aesthetically to have “Styling” and “Settings” separate in the Block settings sidebar, it’s hard to navigate on the Keyboard to the “Settings” of the Block section and there appears to be no keyboard shortcuts on the editor itself.

Essentially, there's no way right now to get to the different tabs either with shortcuts or tabbing. cc @aaron

Step-by-step reproduction instructions

1. Open the Site Editor.
2. Select the navigation block.
3. Open the block settings sidebar.
4. Try tabbing to open up the different settings sections. Notice it skips right over it and there's no keyboard shortcut.

Screenshots, screen recording, code snippet

keyboard.tabbing.and.no.shortcuts.mov

Environment info

• WP 6.1.1
• GB 14.8.4
• TT3

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

[ntsekouras]

You can though by using the arrow keys there, no?

[annezazu]

Yes! Apologies. In my mind, one would be able to tab based on being able to tab between Template and Block. I am no expert here but wanted to be sure this feedback was passed along. @joedolson curious for your thoughts here around the current experience.

[aaronrobertshaw]

one would be able to tab based on being able to tab between Template and Block

FWIW, the difference in behaviour here arises from the styles/settings tabs being true tabs in a TabPanel whereas the Template and Block buttons at the top of the block inspector are implemented as a ul with buttons.

To make the behaviour consistent, I'd guess we'll need to refactor one of these areas. I'd suggest a11y feedback would drive which one is chosen.

[joedolson]

I was thinking about this topic recently in general. One of the problems with tabpanels is communicating to the user that when they've entered it, they're now in a context that support arrow navigation, rather than tab navigation. For screen reader users, the type of control is announced on entry; but for sighted users on a keyboard, there's no feedback to inform usage.

So there are two questions here: one is whether these two interactions should be the same control. In my opinion, other than the difference between text vs icon controls, they otherwise operate the same way, and it makes sense for them to be the same type of control. For keyboard navigation, it's more efficient for them to both be tabpanels, as that becomes only a single tab stop.

The second question is "how can we communicate to sighted users that these controls are operated via arrow keys". I have a couple of suggestions:

1. Add a focus characteristic around the entire tabpanel group when any element is focused, to convey the sense that you've entered a navigable region.
2. Add a visual cue, such as arrows, that is only visible when focusing within that group, to offer a cue about usage. This doesn't need to be conveyed to screen readers, who are already informed that they are in a tabpanel.

Visual affordances to convey anytime you're in a collection of controls that are grouped with arrow navigation would be very helpful to the usability of the editor.

[annezazu]

If you have time, this would be another great issue to review and chime in on @alexstine especially with the tabs being stabilized #47045

[alexstine]

The tab panel is fine from an screen reader standpoint, but the suggestions @joedolson made are valid ones. Likely needs a follow-up issue or at least a PR to edit the TabPanel component.

I did leave feedback in earlier PRs about different blocks having different default selected tabs. I think this is a majorly bad UX issue. However, if this is no longer the case and every block defaults to the same tab, I am happy with it.

Thanks.

[annezazu]

Thanks so much, Alex! @aaronrobertshaw if you have a chance, would you mind iterating here to edit the TabPanel component as suggested above?

[aaronrobertshaw]

It appears we already have an issue for replacing the Post/Block tabs with a TabPanel: #43414.

We might need some design feedback on the potential visual affordances proposed for the TabPanel component itself.

I should be able to devote a little time to switching the Post/Block tabs to the TabPanel early next week.

[annezazu]

@aaronrobertshaw were you able to dig into the switching the Post/Block tabs to the TabPanel? Trying to see what, if anything, could get into 6.2.

[aaronrobertshaw]

@annezazu unfortunately, #43414 has been blocked by #46704 and in turn #48086.

There should be some further movement on this today with new tests being added to verify the current TabPanel component's behaviour and protect against regressions when we allow it as a controlled component. Once that is done, there'll likely be some extra work in updating #46704 before we can finally switch the Post/Block tabs to real tabs.

[annezazu]

Got it! Thank you for the update. Nick moved this to punted and it sounds like that should stick. Perhaps something we can get into a point release.

[aaronrobertshaw]

Given it should help improve a11y, getting it into a point release sounds like a plan to me. 👍

[aaronrobertshaw]

Update: The PR enhancing tests for the current TabPanel has been merged and work is continuing to offer a controlled TabPanel. That is the last blocker to replace the Post/Block tab switcher with a proper TabPanel.

[annezazu]

Closing this out as #43414 was later merged! You can tab to settings then arrow over to styles.