Investigate keyboard operability testing

[rahimabdi]

From display: contents testing work, we've identified opportunities to expand testing coverage in accessibility interop to include keyboard testing.

Common keyboard web accessibility issues which may be WPT-testable include:

• lack of focusability (i.e., an element is neither tabbable nor programmatically focusable)
• keyboard traps (i.e., an element may receive focus but focus cannot subsequently be moved to the previous/next focusable element)
• general lack of expected keyboard operability (e.g., a button-like element is not operable with Enter/Return or Spacebar)
• focus management issues (e.g., dismissing <dialog> or alert() element should return focus to the triggering control)
• modal interfaces that don't hide hidden/inert controls outside the modal window
• missing visible keyboard focus indication (likely non-trivial but may be possible!)

Current WPT keyboard APIs/utilities and proposed stuff

In addition to our currently utilized test_driver.get_computed_label() and test_driver.get_computed_role() functions, testdriver.js includes APIs for actions such as keyboard operation (testdriver-actions.js Actions API).

testdriver-actions.js has a number of functions to simulate keyboard operation (such as .keyUp()) however, accessibility-focused utilities that address common a11y issues like the above are unavailable.

Some proposed new keyboard testing functions:

• isFocusable(): uses assert_equals() and JS .focus() to verify document.activeElement; alternatively, we could simulate a Tab key press and check that the element is focused
• isTabbable: uses test_driver.send_keys() to operate an element with the Tab key
• isFocused(): e.g., when a modal overlay is dismissed, checks that the appropriate element has focus
• isNotFocused(): uses assert_not_equals() to verify that the current element is not document.activeElement (or has been keyboard-navigated away from)
• isKeyboardOperable(someKeys): given a set of keys, ensure that pressing them dispatches appropriate event
• verifyFocusIsTrapped(): given a DOM node, walks all focusable descendants and ensures that only they are in the focus/tab order
• verifyFocusOutline(): check if an element draws a focus ring

These could be written as either a common WPT utility, or set of functions exposed by testdriver.js. I recognize that some of these tests may belong outside of accessibility interop, and likely tested outside of it too, but it could simplify/support external testing efforts as well to standardize WPT keyboard testing.

General examples of keyboard testing in other WPT areas

I've identified some notable existing keyboard-focused tests to see how such testing is handled:

• Keyboard access key only fires click event
• display: none element is not focusable
• invalid tabindex should be non-focusable
• focus events are trusted and should fire appropriately
• key events when an element is not focused
• autofocus tests
• tabindex tests
• popover is not focusable
• escape key doesn't result in user activation
• input type="radio" keyboard operability follows tree order

Generally, existing tests rely on test_driver.send_keys(), document.activeElement, JS .focus() and WPT assert...() functions for keyboard testing.

[rahimabdi]

Initial investigation PR for common keyboard accessibility utils:

• Create keyboard testing utilities (/common/keyboard-utils.js) wpt#44347

[rahimabdi]

Awaiting test_driver.send_keys() WebKit update as part of: https://bugs.webkit.org/show_bug.cgi?id=273843.

[rahimabdi]

Noting suggestion from @cookiecrook around adding a precondition that determines which key combo moves focus as expected, and then using a focusNext() or focusPrevious() method.

[rahimabdi]

I just discovered focus-utils.js here which has some keyboard simulation: https://github.com/web-platform-tests/wpt/blob/aaee91a6d56517e8517b2a3bc6bd055c912c79a5/html/semantics/forms/the-input-element/resources/focus-utils.js#L4