Block list appender no longer reachable with the keyboard from the settings panel

[afercia]

Description

Reported by @alexstine on Slack.

It appears an important keyboard interaction affordance changed from WordPress 6.5 to Gutenberg latest trunk 18.3.0-rc.1, I'm assuming the change is not intentional thus marking this issue as regression.

Previously, on WordPress 6.5, with the post editor in 'Select' mode (also known as 'navigation mode'), pressing Shift + Tab from the Settings panel brought users to the 'block list appender' at the bottom of the blocks list, which provided the ability to reach:

• the 'Add block' plus icon button
• the 'Add default block'

This used to be one of the easiest ways for keyboard users and screen reader users to reach the bottom of the post content and add blocks there.

On latest Gutenberg trunk this doesn't work any longer. Pressing Shift + Tab from the Settings panel brings users directly to the last block, skipping entirely the 'Add block' and 'Add default block'.

These kind of changes that impact keyboard interaction are extremely impactful for keyboard users. Suddenly, a known affordance and user flow to add block disappears, making adding blocks a way longer and tedious process.

When fixed, it would be nice to add e2e tests to prevent such unexpected changes in the future.

When developing, manually testing the editor with the keyboard would be gretly appreciated to prevent such keyboard usability regressions.

See attached GIFs to better illustrate.

Expected keyboard interaction on WordPress 6.5:

Changed interaction on Gutenberg trunk:

Step-by-step reproduction instructions

• Test on WordPress 6.5.
• Edit a post that contains at least one block.
• Switch the editor to 'Select mode' from the top toolbar > Tools dropdown menu.
• Press Tab as much as necessary to reach the Settings panel (open it if necessary).
• From the Settings Panel, press Shift + Tab to navigate backwards.
• Observe it is possible to reach the block list appender at the bottom of the post, so that focus goes to the 'Add block' plus icon button and then to the 'Add default block'.
• Test on latest Gutenberg trunk.
• Repeat the steps above.
• Observe the 'Add block' plus icon button and the 'Add default block' are not reachable. Observe they're not even rendered when using this keyboard flow.

Screenshots, screen recording, code snippet

No response

Environment info

No response

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

[t-hamano]

After some research, it looks like this change was made intentionally in #60697.

[afercia]

Thanks @t-hamano

Looking at https://github.com/WordPress/gutenberg/pull/60697 I have to note:

• The PR is not associated to any issue to allow for broader discussion, as requested by the contributing guidelines of this project and as reasonable in a collaborative open source project.
• The PR doesn't have any accessibility* label, although it touches an important flow for keyboard users.
• I don't see any consideration about accessibility in the PR description and comments.
• I don't see any mention to keyboard testing in the PR description and comments.

The new implementation from https://github.com/WordPress/gutenberg/pull/60697 only uses a paddingAppender area that, when clicked, provides the Add block and default block. It works only with mouse or touch. There is no feature parity for keyboard users and/or other devices users, so that's inherently not accessible besides being a regression that removes an established affordance for keyboard users.

Honestly, I'm not sure all of this is ideal to provide users with a better, more usable, more accessible user interface. Also, I'm not sure it's ideal to encourage collaboration and contribution.

Cc @joedolson @alexstine @youknowriad

[alexstine]

Yeah, @youknowriad or @annezazu, please see this. This continues to be a problem in this side of the house and it needs to be wrangled. I've said it over and over, I cannot possibly watch every PR in this repository. If you are going to take out something for keyboard users and add a visual only interaction, people need to be held accountable. Stuff like this puts WordPress itself at reputational risk especially the way we're marketing to agencies/governments.

I could likely never argue in favor of WordPress being an accessible platform because of these PRs like this. Mistakes happen and this isn't so much about individuals as much as it is a wider culture problem in Gutenberg. Until we embrace accessibility first, there is little point in me playing fire fighter because there are too many PRs, same mistakes keep happening, and there's simply not a big enough Accessibility Team to keep up with the regressions, let alone, the constant feature development.

I leave it with you now to figure out how to move forward on yet another regression, an intentional one at that.

[afercia]

it is a wider culture problem

I would say it is also a process problem. While everyone can contribute to WordPress and propose changes, not everything has to be merged, especially when it is clearly largely untested and not very well considered.

[t-hamano]

I think we need to fix this issue for the WP6.6 release, so I'll add it to the project board.

[richtabor]

an intentional one at that.

To be clear, this is an unintentional result of https://github.com/WordPress/gutenberg/pull/60697.

This continues to be a problem in this side of the house and it needs to be wrangled. I've said it over and over, I cannot possibly watch every PR in this repository. If you are going to take out something for keyboard users and add a visual only interaction, people need to be held accountable. Stuff like this puts WordPress itself at reputational risk especially the way we're marketing to agencies/governments.

I could likely never argue in favor of WordPress being an accessible platform because of these PRs like this. Mistakes happen and this isn't so much about individuals as much as it is a wider culture problem in Gutenberg. Until we embrace accessibility first, there is little point in me playing fire fighter because there are too many PRs, same mistakes keep happening, and there's simply not a big enough Accessibility Team to keep up with the regressions, let alone, the constant feature development.

To be fair, you could replace "accessibility" with "design" — or any other team. Each of our roles in our primary disciplines is not to be aggressors, but rather promoters. The accessibility team pushing forward accessibility is just as paramount as the design team pushing design and experience, or developers pushing forward code quality.

Let's propose solutions.

[richtabor]

I do agree we need to work a solution here. Perhaps on focus the inserter can render, much like "Open publish panel" does.

[alexstine]

@richtabor On focus of what?

To be clear, this is an unintentional result of #60697.

The intent was pretty clear, the inserter was removed and no one thought to check accessibility.

To be fair, you could replace "accessibility" with "design" — or any other team.

That's a bold statement and one not based in fact. As you can see from the PR, there were designers but no accessibility consultants. Now we see the end result. I am good to work with others but that becomes really difficult when no one ever asks. I do admit, I get a little swamped at times and waiting just goes against fast moving development.

I also agree with @afercia. Process is a problem. I wish our team was big enough to review every issue and PR for both Gutenberg and Core but we're not. The even worse part about all this, I found this regression while trying to solve another accessibility regression. It is upsetting knowing we've got no real testing process to ensure we don't remove features for users that might be a large difference between ease of use and going to another platform.

I won't post any further of my personal opinions here, it is likely better for a discussion. Sorry for allowing my frustration to overflow here.

I think the solution for now is to revert this PR and pretend like it never happened. We can revisit the ideas of this PR later but only after we all talk about it before it just happens.

Thanks.

[annezazu]

Following up on this thread after some time to catch up on what's happened. Thanks for tagging me and for reporting this. Let's please keep chatting about solutions and tracking down what's next. I'm not sure if this is possible, but if there could be a list of common patterns folks from Accessibility see in code changes (not properly labeling items for example) that would be helpful to document and make folks more aware of as common mistakes. Mistakes will keep happening though across the board and I hope we can all keep working to both prevent as much as we can and act quickly to resolve when they do happen. Ultimately, we are all in this and it behooves all of us to work as well as we can together with clarity about the problem, kindness in finding solutions, and urgency when major functionality breaks.

@ellatrix some feedback for you on here around ensuring there's a related issue tied to the PR in question whenever possible. It helps track back the work more, especially in cases like this when we're untangling a situation <3

[afercia]

Each of our roles in our primary disciplines is not to be aggressors, but rather promoters. The accessibility team pushing forward accessibility is just as paramount as the design team pushing design and experience, or developers pushing forward code quality.

To be fair, I think in a project that aims to be as accessible and inclusive as possible, the distinction between design and accessibility shouldn't exist in the first place. Design should be accessible to start with. Many accessibility specialists in this project have been advocating for this for long time but what I've been observing in 7 years is that there is often reluctance, or even dismissive feedback from design to follow accessibility recommendation. This is a fact, not a personal opinion. I could point to countless examples of design not prioritizing accessibility. I would love to see a mindset switch, which would require from many in this project to think deeply to what the design role in this project is, what is the desired goal and how to achieve it. Priorities and process are an essential part of this. It is cleaer that #60697 hasn't been considered thoroughly and should never have been merged. I do realize the regression is 'unintentional' but that's true for any regression. The point is the current process doesn't prevent this kind of regressions to happen.

[ellatrix]

Worth noting that the behaviour seems to have been caused by an inconsistency: you can only reach the appender when in navigation/select mode (not in edit mode), because navigating away from the cavas keeps the block selected in edit mode, while it removes block selection in navigation mode. It was unclear the updated logic affected any of this.

Also note that the appender was not even there when tabbing away from the canvas, further suggesting that showing it upon return to the canvas was an inconsistency. To use the appender, you had to tab into the sidebar first, and then tab back into the canvas.

That all said, I generally agree that the inserter should be more easily accessible, so it's easier to insert a block after the selected block. I created #63298 for this.