[policy, no patch] Require functional test coverage for keyboard accessibility

Problem/Motivation

So far, we have very little functional test coverage for keyboard operations, distinct from pointer operations.

Prior to using WebDriver this was awkward anyway, because Goutte keyboard driving was flaky.

In the last couple of years we have started to add some keyboard test coverage:

• #2711907: [regression] Some ajax-enabled buttons are not keyboard operable → - a simple test scenario, which illustrates the awkwardness of doing it with Goutte. Keyboard events were unreliable, so this test did it by evaluating some inline JS. We don't need that workaround now we use WebDriver.
• #2725259: [regression] Table Drag handles no longer respond to up/down arrow keys → - the keyboard tests here involve a more complex sequence of keyboard operations.

We now have some significant experience of writing functional tests for keyboard operations. So let's start expanding our keyboard accessiblility test coverage...

Proposed resolution

• Add test coverage for existing keyboard operation wherever feasible.
• Start requiring keyboard test coverage for:
  • new UI features
  • patches that fix a keyboard bug
  • stuff which otherwise involves JS keyboard, focus, or blur events.
• Update the core testing and/or accessibility gates to reflect this.
• We could do this with WebDriverTestBase or Nightwatch.

Things we can write keyboard behaviour tests for

Here's an initial survey to find testable keyboard behaviours.

1. "Mobile menu" behaviour at small breakpoints, e.g. in Bartik and Umami themes. Is the menu operable with a keyboard?
   • Assert: the menu button opens and closes using either the enter or spacebar keys.
   • Assert: the nested menu items are NOT in the keyboard tabbing order when the menu is closed. If they are, that's a failure of WCAG "Focus visible".
2. When a dialog, opens, focus moves inside it.
3. Dialogs can be dismissed by pressing ESC.
4. When a dialog is dismissed, focus returns to the button that opened it. May need separate tests for each place that dialogs are used.
5. Assert that the colllapse.js details works with spacebar and enter.
6. Assert that keyboard focus does not move to operable controls which are concealed inside containers which are in a closed state. For example only controls in the active vertical tab can be tabbed to, not controls in the other tabs.
7. The CKEditor toolbar configuration UI. Lots of interesting scenarios there.

You can tag issues with "needs accessibility review" to get help with devising keyboard scenarios and/or clarify expected behaviour.

Remaining tasks

1. Catalogue existing keyboard operations we can add test scenarios for. In progress, forming a list under a separate heading above.
2. There is a manual test plan somewhere. Are there any keyboard related things there?
3. Find the existing issue about converting the manual test plan to Nightwatch.