Skip to content
Open
Changes from 7 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
123 changes: 123 additions & 0 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -1040,6 +1040,19 @@ <h3>Endpoints</h3>
<td>/session/{<var>session id</var>}/print</td>
<td><a>Print Page</a></td>
</tr>

<tr>
Comment thread
OrKoN marked this conversation as resolved.
<td>GET</td>
<td>/session/{<var>session id</var>}/element/{<var>element id</var>}/accessibilityproperties</td>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would these endpoints allow getting the entire a11y tree? what is the expected workflow? getting accessibilityproperties for the root element and then using accessibility/properties/<accessibility id> to traverse?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it also seems like it would require many roundtrips to get properties for all elements.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we will have some "subtree" tests which walk the accessibility tree by accessibility ID, for example: https://github.com/web-platform-tests/wpt/blob/master/wai-aria/subtree/tablist.tentative.html

(this test runs on firefox because of the marionette endpoint: https://wpt.fyi/results/wai-aria/subtree?label=experimental&label=master&aligned)

In general, though, the subtrees are not testable, because they are pretty different between browsers, and we don't think we will ever have full alignment. The main issue is how much "generic" nodes there are (things that represent something meaningless in the a11y tree, like a div for styling purposes). We expect only to test specific scenarios. We discussed having an endpoint for the whole subtree, but we think it's more comment to just test a node or a few children/parents, thus the current design.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that makes sense but I wonder once this is published if other WebDriver clients might start building out features based on the subtree iteration mechanisms available (thus starting to rely on the non-specified behavior) and require many roundtrips to implement the subtree retrieval.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I expect that will be the case, and don't see harm in testing the subtree of smaller features, like a known list or table with a known style sheet... However, it won't be a reliable cross-UA WPT test yet to include something like dumpAccessiblityTree() at the root node for a complex web site. Perhaps someday if and when we are able to standardize the rest.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense to add a note about this to the spec text here?

<td><a>Get Accessibility Properties For Element</a></td>
</tr>

<tr>
<td>GET</td>
<td>/session/{<var>session id</var>}/accessibility/properties/{<var>accessibility id</var>}</td>
<td><a>Get Accessibility Properties For Accessibility Node</a></td>
</tr>

</table>
</section> <!-- /Endpoints -->

Expand Down Expand Up @@ -1193,6 +1206,14 @@ <h3>Errors</h3>
and cannot be brought into that viewport.
</tr>

<tr>
<td><dfn>no such accessibility node</dfn>
<td>404
<td><code>no such accessibility node</code>
<td>An <a>accessibility node</a> could not be located on the page
using the given search parameters.
</tr>

<tr>
<td><dfn>no such alert</dfn>
<td>404
Expand Down Expand Up @@ -6028,6 +6049,42 @@ <h4><dfn>Get Computed Label</dfn></h4>
<li><p>Return <a>success</a> with data <var>label</var>.
</ol>
</section> <!-- /Get Element Computed Label -->

<section>
<h4><dfn>Get Accessibility Properties For Element</dfn></h4>

<table class="simple jsoncommand">
<tr>
<th>HTTP Method</th>
<th>URI Template</th>
</tr>
<tr>
<td>GET</td>
<td>/session/{<var>session id</var>}/element/{<var>element id</var>}/accessibilityproperties</td>
</tr>
</table>

<p>The <a>remote end steps</a>, given <var>session</var>, <var>URL
variables</var> and <var>parameters</var> are:

<ol>
<li><p>If <var>session</var>&apos;s <a>current browsing context</a> is <a>no longer open</a>,
return <a>error</a> with <a>error code</a> <a>no such window</a>.

<li><p><a>Try</a> to <a>handle any user prompts</a>
with <var>session</var>.

<li><p>Let <var>element</var> be the result
of <a>trying</a> to <a>get a known element</a>
with <var>URL variables</var>["<code>element id</code>"].

<li><p>Let <var>accessible</var> be the <a>accessibility node</a> that corresponds to this element. If no <a>accessibility node</a> exists, return <a>error</a> with <a>error code</a> <a>no such accessibility node</a>.

<li><p>Let <var>properties</var> be the result of computing the <a>accessibility properties</a> of <var>accessible</var>.

<li><p>Return <a>success</a> with data <var>properties</var>.
</ol>
</section> <!-- /Get Element Accessibility Properties -->
</section> <!-- /State -->

<section>
Expand Down Expand Up @@ -11116,6 +11173,60 @@ <h3><dfn>Take Element Screenshot</dfn></h3>
</section> <!-- /Take Element Screenshot -->
</section> <!-- /Screen capture -->

<section>
<h2>Accessibility</h2>

<p> An <dfn>accessibility node ID</dfn> is a string value representing a handle to an <a>accessibility node</a> in a specific WebDriver session.

<p> An <dfn>accessibility node</dfn> is a platform-independent, implementation-defined node in the platform-independent, implementation-defined accessibility tree. The platform-independent, implementation defined accessibility tree is built from the DOM tree for the purposes of interacting with the web page via an <a>accessibility API</a>. Accessibility nodes might exist in this tree for which there is no DOM element back it (for example, one might be created to represent a CSS pseudo element). Additionally, an accessibility node might not be created for every DOM node (for example, if something is intentionally hidden from accessibility APIs using <a>aria-hidden</a>). See the ARIA definition of the <a>accessibility tree</a> for more information.
Comment thread
spectranaut marked this conversation as resolved.
Outdated

<p> <dfn>Accessibility properties</dfn> is a JSON <a>Object</a> that contains the relevant <a>computed accessibility properties</a> of an <a>accessibility node</a>, as well as the following properties:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An unadorned "relevant" seems a little dubious for conformance-seekers. I imagine that the properties are implementation-defined (though I can't find "computed accessibility properties" in CORE-AAM 1.2 or its issue tracker); if that's part of the definition, is "relevant" necessary here?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, there is a PR for "computed accessibility properties": w3c/aria#2800

To see the spec text: https://deploy-preview-2800--wai-aria.netlify.app/core-aam/#computed_accessibility_properties

The spec text does explain exactly which properties should appear for a given accessibility node. So maybe you are right, the relevant is superfluous, the "computer accessibility properties" is a defined set, I'll remove it :)


<dl>
<dt>"<code>accessibilityId</code>"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as far as I see the a11y properties do not link back to DOM element IDs? it seems like it might limit usefulness of the a11y properties?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They don't link back, it's true. Can you explain why it might limit the usefulness? Oh maybe you mean, if you have an accessibility node, and you want to click it, you don't know where to send that click?

That is a problem, I'm not sure right now how to get around, I'll bring it up.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, this would be a use case we have in Puppeteer or in Chrome DevTools (a11y tree view), for example, but also if the a11y tree is traversed using the methods in PR, there seems to be no mechanism to do something with the backing DOM node or even know what DOM contributed this a11y node (if any). I understand that the proposed extension is probably useful for the WPT use cases but I also wonder how it would work for other WebDriver clients.

@cookiecrook cookiecrook Jun 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be an optional DOM Node ID reference from the Accessibility Node, if relevant... The reason it's optional is that not all Accessibility Nodes have a relevant DOM Node, and vice versa, not all DOM Elements have a backing Accessibility Node...

An example of the latter is any hidden DOM node; not mapped in the AX Tree. An example of the former (AX Nodes without a DOM Element) is any CSS generated content, or sometimes (depending on implementation details, dynamic nodes like table columns or other in-betweener AX nodes)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not see an optional DOM Node ID reference in the spec. Could you please point me to the definition?

@cookiecrook cookiecrook Jul 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could be defined here, but would more likely come from the TBD property bag definition in Core-AAM. @spectranaut?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the case of webdriver, it would be the webdriver element ID. Maybe we will make some kind of abstraction in order to define this in Core-AAM -- because other testing frameworks (like marionette driver) will have a different kind of ID references to get back to the original DOME element.

<dd>The <a>accessibility node ID</a> of this <a>accessibility node</a>.

<dt>"<code>parent</code>"
<dd>The <a>accessibility node ID</a> of the parent of this <a>accessibility node</a> in the <a>accessibility tree</a>.

<dt>"<code>children</code>"
<dd>A list of <a>accessibility node IDs</a> representing the child nodes of this <a>accessibility node</a> in the <a>accessibility tree</a>.
Comment thread
spectranaut marked this conversation as resolved.
Outdated
</dl>

<section>
<h3><dfn>Get Accessibility Properties for Accessibility Node</dfn></h3>

<table class="simple jsoncommand">
<tr>
<th>HTTP Method</th>
<th>URI Template</th>
</tr>
<tr>
<td>GET</td>
<td>/session/{<var>session id</var>}/accessibiltiy/properties/{<var>accessibility id</var>}/</td>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple typos: "accessibility", and we can nix the trailing forward-slash.

Taking a step back, though, I wonder if we should design this resource more like the element commands. That is, given that we have:

/session/{session ID}/element/{element ID}/rect

A resource like:

/session/{session ID}/accessibility/node/{accessibility node ID}/properties

Looks a little more familiar (and hopefully more predictable) than

/session/{session ID}/accessibility/properties/{accessibility node ID}

I'd personally be in favor of such an alteration purely on the basis of parity, but it would help if there was a credible expectation for further accessible-node-based commands in the future. Do you know any? Maybe /element to get the backing DOM element (where available)?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the ideas here, I wonder what the other reviews would think, and we should discuss this at the next accessibility interop meeting.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We agreed to make this switch!

</tr>
</table>

<p>The <a>remote end steps</a>, given <var>session</var>, <var>URL
variables</var> and <var>parameters</var> are:

<ol>
<li><p>If <var>session</var>&apos;s <a>current browsing context</a> is <a>no longer open</a>,
return <a>error</a> with <a>error code</a> <a>no such window</a>.

<li><p><a>Try</a> to <a>handle any user prompts</a>
with <var>session</var>.

<li><p>Let <var>node</var> be the <a>accessibility node</a> with <a>accessibility node ID</a> matching the <var>URL variables</var>["<code>accessibility id</code>"]. If no such <a>accessibility node</a> exists, return <a>error</a> with <a>error code</a> <a>no such accessibility node</a>.

<li><p>Let <var>properties</var> be the result of computing the <a>accessibility properties</a> of <var>node</var>.

@OrKoN OrKoN Jun 18, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, actually, this will be backed by the devtools node -- the webdriver command goes through the devtools protocol to get this information. The difference is that to start it will be a subset of the properties -- just the ones all three browsers agree to expose, and the agreement is being worked out in the other PR (w3c/aria#2800).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are you also working on the implementation in Chromium?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I sent it to you, but just in case here is is again: https://chromium-review.googlesource.com/c/chromium/src/+/7922212


<li><p>Return <a>success</a> with data <var>properties</var>.
</ol>

</section> <!-- /Get Accessibility Properties for Accessibility Node -->
</section> <!-- /Accessibility -->

<section>
<h2>Print</h2>

Expand Down Expand Up @@ -11603,6 +11714,10 @@ <h2>Index</h2>
in the Accessible Rich Internet Applications (WAI-ARIA) 1.2 specification: [[wai-aria-1.2]]
<ul>
<li><dfn><a href="https://w3c.github.io/aria/#introroles">WAI-ARIA role</a></dfn>
<li><dfn><a href="https://w3c.github.io/aria/#accessibility_tree">Accessibility tree</a></dfn>
Comment thread
spectranaut marked this conversation as resolved.
<li><dfn><a href="https://w3c.github.io/aria/#dfn-accessibility-api">Accessibility API</a></dfn>
<li><dfn><a href="https://w3c.github.io/aria/#aria-hidden">aria-hidden</a></dfn>

</ul>

<dd>
Expand All @@ -11614,6 +11729,14 @@ <h2>Index</h2>
Name and Description Computation</a></dfn>
</ul>

<dd>
<p>The following terms are defined
in the Core Accessibility API Mappings (Core-AAM) 1.2 specification: [[core-aam-1.2]]
<ul>
<li><dfn><a href="https://w3c.github.io/core-aam/#computed_accessibility_properties">Computed accessibility properties</a></dfn>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this link does not seem to work for me? is the content for this in a PR?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So sorry -- I should have made that more clear. This is also currently being specified and there is a PR: w3c/aria#2800

To see the spec text: https://deploy-preview-2800--wai-aria.netlify.app/core-aam/#computed_accessibility_properties

We need to get agreement between all the browsers on this, and we are working on that actively, it seems like it's close to landing.

</ul>


<dt>Web App Security
<dd><p>The following terms are defined
in the Content Security Policy Level 3 specification: [[CSP3]]
Expand Down
Loading