Skip to content
131 changes: 131 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</a></td>
Comment thread
spectranaut marked this conversation as resolved.
Outdated
</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 accessible node</dfn>
<td>404
<td><code>no such accessible 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 @@ -1255,6 +1276,14 @@ <h3>Errors</h3>
<td>A new <a>session</a> could not be created.
</tr>

<tr>
<td><dfn>stale accessible node reference</dfn>
<td>404
<td><code>stale accessible node reference</code>
<td>A <a>command</a> failed because
the referenced <a>accessible node</a> is no available.
Comment thread
spectranaut marked this conversation as resolved.
Outdated
</tr>

<tr>
<td><dfn>stale element reference</dfn>
<td>404
Expand Down Expand Up @@ -6028,6 +6057,43 @@ <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</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>accessible node</a> that corrosponds to this element in the <a>accessibility tree</a>.
Comment thread
spectranaut marked this conversation as resolved.
Outdated

<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 +11182,70 @@ <h3><dfn>Take Element Screenshot</dfn></h3>
</section> <!-- /Take Element Screenshot -->
</section> <!-- /Screen capture -->

<section>
<h2>Accessibility</h2>

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

<p> An <dfn>accessibility node</dfn> is an node in the implementation defined <a>internal accessibility tree</a>. These nodes frequently but not always correlated to DOM elements.
Comment thread
spectranaut marked this conversation as resolved.
Outdated
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>accessiblity node</a>, as well as the following properties:

<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?

@spectranaut spectranaut Jul 1, 2026

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 DOM element.

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

<dt>"<code>parent</code>"
<dd>The <a>accessibility ID</a> of the parent of this <a>accessible node</a> in the <a>accessibility tree</a>, including <a>ignored accessible nodes</a>.

<dt>"<code>children</code>"
<dd>A list of <a>accessibility IDs</a> representing the child nodes of this <a>accessible node</a> in the implementation’s <a>internal accessibility tree</a>
</dl>

<p> <dfn>Ignored accessible nodes</dfn> are accessible nodes that represent <a>elements which are excluded from the accessibility tree</a>. The <a>accessibility properties</a> of these <a>accessible nodes</a> must only have the keys <va>accessibilityID</var>, <va>parent</var>, <va>children</var> and <va>role</var> set to <code>"none"</code>.
Comment thread
spectranaut marked this conversation as resolved.
Outdated

<p>To <dfn>get a known accessible node</dfn> given <var>session</var> and <var>reference</var>:

<ol class="algorithm">
<li><p>TO DO: Should we create a parallel to the specification of <a>get a known element</a>? Do we need to make a parallel structure to <a>browsing context group node map</a> and <a>node id map</a>?
Comment thread
spectranaut marked this conversation as resolved.
Outdated
</ol>

<section>
<h3><dfn>Get Accessibility Properties for Accessible 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>
Comment thread
spectranaut marked this conversation as resolved.
Outdated
</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 result
of <a>trying</a> to <a>get a known accessible node</a>
with <var>URL variables</var>["<code>accessibility id</code>"].

<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 Accessible Node -->
</section> <!-- /Accessibility -->

<section>
<h2>Print</h2>

Expand Down Expand Up @@ -11603,6 +11733,7 @@ <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/#fixme">Computed acccessible properties</a></dfn>
Comment thread
spectranaut marked this conversation as resolved.
Outdated
</ul>

<dd>
Expand Down
Loading