Computing the Accessible Backing Node, or a similar test-only interface · Issue #197 · WICG/aom (original) (raw)

Historical context:

2023 Developments

In the context of the Interop 2023 Accessibility Investigation, we're making progress on cross-browser accessibility testing using TestDriver/WebDriver based interfaces computedrole and computedlabel.

In order to perform more cross-browser accessibility tests, we'll need interfaces beyond role and label. Some of those current testability shortcomings are outlined in web-platform-tests/interop-accessibility#6 and web-platform-tests/interop-accessibility#21

Rather than hanging a growing list of accessibility properties (computedchecked, computedrequired, etc.) off of element, most AOM stakeholders would prefer this be a new test-only interface that can contain the additional properties, probably something akin to the original intention of AOM's proposed AccessibleNode, but with some key differences. In particular, being a read-only interface used for testing, rather than a read/write interface as a general DOM API.

Initial Investigation

Nothing is being formally proposed yet, but I think what this incubation may entail is the following:

  1. A new AccessibleNode interface (peer of Node, not Element) that could be specified in either the HTML spec, or perhaps a new deliverable in the ARIA Working Group.
  2. Likely as part of that interface, a list of the property values returned along with the new AccessibleNode.
  3. A new WebDriver edit defining how to get a known AccessibleNode (similar to get a known element).
  4. A new WebDriver interface on element to Get Computed Accessible Node for document and any given DOM Node.
    • Would likely need to return null except in cases of DOMElement or TextNode where there was a backing AccessibleNode...
    • This differs between implementations, but in general, there is no backing accessibility node for hidden elements, comment nodes, or some other rendered DOM Nodes that are just irrelevant in the associated accessibility tree.
    • Likewise, there are some accessibility nodes that have no representation in the DOM. CSS generated pseudo-elements like ::before and ::after are one of several examples.
  5. WPT TestDriver wrappers around that new WebDriver interface, so that computedaccessiblenode can be "got" in a WPT interoperability test...

Clarifications

  1. I believe everyone who has discussed this (in AOM, ARIA, WPT, and BTT) is in agreement that this should remain a test-only, read-only interface for the currently foreseeable future. Unlike a prior AOM experimental implementation, this is not intended as a web authoring API.
  2. The primary client for these changes will be Web Platform Tests (WPT), but some larger JavaScript frameworks or other Accessibility Testing Tools may also benefit (in their testing contexts) from the proposed changes.
  3. The intended interface to AccessibleNode would only be a browser's representation of the accessible node... This does not expose platform accessibility API differences, and in fact, never leaves the rendering engine implementation.
  4. Initially, it is understood that there will be some implementation differences between the browsers. In particular, a dump of an accessibility tree walker will be highly unlikely to return the exact same tree between the three major implementations. This is expected. Any implementation differences discovered will be used to further discussion of each issue on a case-by-case basis.
  5. Because of the known implementation differences, it is NOT a goal of the WICG AOM group to get to an identical accessibility tree as part of this investigation. If it happens, that's fine, but it does not need to happen in order for this interface to be useful. If we can agree on the estimated 80–90% of places where the implementations align, that's 80–90% more interop testing than we could achieve before.