Accessibility primitives: computedRole and computedLabel

[cookiecrook]

WebDriver should add primitives for computedRole and computedLabel (or some equivalent names)

The engine’s computed accessibility role is exposed to web developers through developer tools (WebKit Inspector, Google DevTools, F5, etc.) but is not available in standard JavaScript contexts. Even extension developers can’t get this information.

This serves a dual benefit of allowing web authors to perform better Accessibility testing on their sites, and web spec authors to test/compare browser implementations.

[cookiecrook]

For example <h1>, <div role=“heading”>, <span role=“bogusrole heading group” should all have a computed role of ‘heading’

[cookiecrook]

An example that cannot be determined in JavaScript:

<div role=“switch checkbox”>

Both roles are valid in ARIA 1.0 (checkbox) and ARIA 1.1 (switch) so there is no way from the content side to determine whether the engine supports the newer switch role, or whether it falls back to the 1.0 role.

[cookiecrook]

Currently it would be very challenging and possibly undesirable (implementation-wise) to expose these outside the testing context. There is a long-term roadmap in AOM for standardizing the Accessibility tree, but that is out of scope for the near future.

[cookiecrook]

@AutomatedTester Requested I fill in a bit more info about what these are.

Accessibility Label

Accessibility Label (sometimes also referred to as Accessible Name) is a short string that labels the function of the control (e.g. the string "Comment" or "Sign In" on a button). Each platform Accessibility API has a mapping for these. For example, iOS has accessibilityLabel on UIAccessibilityElement.

The W3C spec that defines how labels should be computed in web rendering engines is Accessible Name and Description (currently v1.1), which was split out from the ARIA spec a few years ago. The Name and Description computation section of that spec defines rules for what to do when HTML, ARIA, and other technologies combine. For example, the title attribution would be sufficient fallback label in some contexts, but a more explicit aria-label attractive would override most host language features in HTML, SVG, etc.

Currently the AccName spec is tested manually. Adding a computedLabel property to WebDriver would allow the AccName authors/maintainers to write WPT scripts that could validate the spec implementation in each browser. I expect this new capability would result in bug fixes to each engine, as well as updates/changes to the AccName spec.

[cookiecrook]

Accessibility Role

Role is a reserved token value (in ARIA, button, heading, etc.) that described the type of control or content in the element. To distinguish these from user-presented string values, platform Accessibility APIs usually have these prefixed: AXHeading on macOS, ATK_ROLE_HEADING on Linux. Note: the fact that ARIA roles happen to match up with user-presented strings sometimes ("button" == "button" in English l10n) does not mean that a web author can use any arbitrary string in the role attribute value.

For rendering engines, the two specs that best define how role should be computed are ARIA section 2.1 and the HTML Accessibility API Mappings. The interplay for example, means that <h1> gets an AXHeading role on macOS, even though there is no explicitly defined ARIA role="heading"...

[cookiecrook]

Dev tools, such as the WebKit Web Inspector screen shot below inspecting a GitHub editing toolbar button, already expose the computed role and label values to developers.

[cookiecrook]

Just seeing this... Will review now.