Create keyboard testing utilities (/common/keyboard-utils.js)

[rahimabdi]

Initial PR to address keyboard accessibility utils for accessibility-focused WPT tests: web-platform-tests/interop-accessibility#101

[annevk]

Is it normal for utilities to actually be test function wrappers? That seems a bit weird to me.

I would expect that to more clearly show up in the name of the functions you call.

E.g., test_elements_are_focusable instead of verifyElementsAreFocusable.

[jugglinmike]

This resembles some utilities that have recently been introduced for testing accessibility primitives. Since we're currently combatting some technical debt in that initial design, it may be wise to address those concerns here in this introductory patch before tests begin to rely on it.

[rahimabdi]

Is it normal for utilities to actually be test function wrappers? That seems a bit weird to me.

I would expect that to more clearly show up in the name of the functions you call.

E.g., test_elements_are_focusable instead of verifyElementsAreFocusable.

I sought to align with aria-utils.js to make test creation easier. @cookiecrook Thoughts?

[rahimabdi]

This resembles some utilities that have recently been introduced for testing accessibility primitives. Since we're currently combatting some technical debt in that initial design, it may be wise to address those concerns here in this introductory patch before tests begin to rely on it.

Thanks for bringing attention to this, @jugglinmike! There's an additional argument for both verifyRole..() and verifyLabels...()that was introduced in aria-utils.js as part of the display: contents test. The new verifyRolesAndLabelsBySelector() method specifies a test prefix, and calls the role/label function, to ensure unique test names for what is really a single test function that tests both role/label together.

It sounds like the subtest count PR might be blocking for this one, right? Tagging @cookiecrook for input and thoughts on direction.