Make manual keyboard testing required for any change to the editor UI

[afercia]

Splitting this out from #58615

I see a recurring trend in the Gutenberg project where many contributors and reviewers don't test changes to the user interface with the keyboard. In some cases, it appears many contributors don't know what and how to test with keyboard.

As an example, in #57608 the NavigableMenu component was replaced with a MenuGroup, which broke the arrow key navigation and semantics.

The breakage of the expected keyboard interaction is very evident and it would have taken only a few seconds of testing to be caught. It appears that amongst the several contributors who participated and reviewed that change, no one tested with keyboard. Or maybe they did, but they didn't know what to test.

• Better documenting the components expected keyboard behavior could help. I'm not sure that would solve the problem though.
• Education and training could certainly help, but I'm not sure that would entirely prevent breakages like the example above where contributors feel they can replace a component with another one only for visual purposes ignoring functionality and semantics.
• Enforcing via code that some components do have required parent and children components may help. I guess such a refactoring to make components and required sub-components (like for example the Tabs component) would take a hige effort and at the end won't 100% safeguard from other breakages.
• Add the accessibility checks powered by aXe that are currently only in the StoryBook also for all PRs. However, those are only static checks for required ARIA roles, attributes etc. That could help though.
• Make keyboard testing required for any change that touches the user interface. This would be the simplest approach and also the one with the highes educational value. Testing with keyboard takes only a few seconds. It's certainly worth it spending a couple minutes more on a pull request by testing with keyboard rather than discovering a breakage weeks or months later, investigating where the breakage occurred, creating an issue, submitting a PR to fix etc. That's certainly a much more time consuming process.

The intent of this discussion is to find a constructive, effective, way to prevent breakages and regressions like the one in the example above. Any code improvement that prevents components misuse would be very welcome.

However, contributors education and responsibility is key. I do think making keyboard testing a requirement for any UI change is fundamental to provide the code quality we all aim for WordPress.

Cc @ciampo @mirka @youknowriad @joedolson @alexstine @andrewhayward et all.

[andrewhayward]

As a first pass, it's probably worth updating the keyboard testing section of the pull request template to be a little more explicit. It's currently quite vague, and doesn't offer any sort of direction to contributors who don't know what to look for.

### Testing Instructions for Keyboard
<!--
How can you test the changes by using the keyboard only?
Please note, this is required for PRs that change the user interface (UI).
This ensures the PR can be tested for any possible accessibility regressions.
-->

I also wonder whether we should direct contributors to add the Needs Accessibility Feedback label or ping (currently non-existent) @WordPress/accessibility if they're unsure. Could get noisy, and would need commitment from a11y folks to respond, but would at least help move things in the right direction.

Longer term, we might investigate adding a workflow similar to the components CHANGELOG validator or the props bot, which could check the PR description and flag any missing testing blocks. We're unlikely to be able to totally validate they're correct, but we could at least address their absence.

For example...

On a related note, it's unfortunate that there's no section in the core handbook for accessibility. The coding standards are fine for the how, but really the why should be a central part of expectations.

[joedolson]

Perhaps we should have guideline describing keyboard testing expectations. I'd be happy to write up short document (probably publish at Make > Accessibility > Handbook > Testing > [new doc] Keyboard Testing.

I think it's too verbose to put that in a PR template, but we can reference it.

It would need to cover a summary of standard keyboard behavior expectations, focus management and consistency, and address how keyboard handling is different with a screen reader running.

Regarding the Needs Accessibility Feedback, we need to practice better habits with that label. I'm not sure what the best practice would be, but the biggest problem I find is identifying issues that currently need accessibility feedback. We need a plan for resolving the needs feedback label, but I'm not sure it should just be "somebody has provided feedback."

Re: Core Handbook. Agreed. It should probably be a document under Best Practices, following a similar pattern to Spelling/Internationalization, etc. I'm also willing to work on that.