Get Accessibility Properties by spectranaut · Pull Request #1960 · w3c/webdriver

spectranaut · 2026-05-12T00:44:08Z

See WICG/aom#203

Added/update sections:

Things to maybe revisit:

Discussion on errors in explainer - should we/can we have more specific errors?
Discussion on IDs in the explainer - should the accessibility ID be more defined?

This change is

Preview | Diff

spectranaut

First pass at fixes to your comments, @cookiecrook, but I still need to work on definitions and where they belong!

jcsteh

Thanks for all of your work on this.

Co-authored-by: James Teh <jamie@jantrid.net>

spectranaut · 2026-06-03T23:50:25Z

I can't actually add people as reviewers, but, this is ready for re-review after all the feedback from the meetings the last few days, and the review comments from James and Jamie.

@jcsteh @cookiecrook @jugglinmike @lolaodelola , if you could all take a look :)

jcsteh

Thanks. Looks good to me.

Co-authored-by: James Teh <jamie@jantrid.net>

…ccessibilityPropertiesForAccessibilityNode commands https://bugs.webkit.org/show_bug.cgi?id=299508 rdar://161303091 Reviewed by NOBODY (OOPS!). This patch implements two new WebDriver automation commands used to support more robust WPT accessibility testing: - GetAccessibilityPropertiesForElement - GetAccessibilityPropertiesForAccessibilityNode For this initial implementation, test_driver.get_accessibility_properties...() will return an accessibility property bag containing the following computed properties: - accessibilityId - role - label - checked - pressed - children (array of serialized AXIDs) - parent (serialized AXID) As these new WebDriver commands are test-only interfaces, there's been in-depth discussion around how to treat computed AX properties when a property is missing & supported, or present & unsupported; see WICG/aom#203. Some additional resources: - WebDriver PR for the new commands: w3c/webdriver#1960 - ARIA PR for the initial set of computed accessibility properties, and treatment of undefined/missing/unsupported values: w3c/aria#2800. At a high level, the WebDriver client (i.e., Web Platform Tests' testdriver.js) initiates these new commands which is then dispatched to the UI Process (WebAutomationSession). The WebAutomationSession then parses the payload and extracts the protocol-specific element or accessibility node, after which it identifies the target (WebPageProxy) which invokes an asynchronous IPC message to the corresponding Web Process. Note that GetAccessibilityPropertiesForElement uses the same DOM node/frame-based approach as many other WebDriver commands however, GetAccessibilityPropertiesForAXNode does not require frame-based process routing (it retrieves computed accessibility properties using the page's axObjectCache, rather than a specific frame tied to a DOM node); thus, GetAccessibilityPropertiesForAccessibilityNode has a different message signature. Note that to fully support these new WebDriver commands, corresponding WebDriver HTTP endpoints must be implemented in Webdriver for Safari (safaridriver): - session/{session_id}/element/{elId}/accessibilityproperties: Returns accessibility properties for DOM element {elId} - session/{session_id}/accessibility/properties/{accessibilityId}: Returns accessibility properties for accessibility node {accessibilityId} Due to the existence of two AccessibilityProperties protocol object definitions, documentation for each has been updated: - Source/WebKit/UIProcess/Automation/Automation.json — specification conformance and interoperability testing - Source/JavaScriptCore/inspector/protocol/DOM.json — uWeb Inspector DOM element inspection As an unrelated small fix, the return type for GetComputedLabel (WebAutomationSessionProxy IPC message) incorrectly names the first string parameter as "role" instead of "label" so this patch also corrects the tuple to return (label, errorType). * LayoutTests/resources/testdriver-vendor.js: (window.test_driver_internal.get_accessibility_properties_for_element): (window.test_driver_internal.get_accessibility_properties_for_accessibility_node): * Source/JavaScriptCore/inspector/protocol/DOM.json * Source/WebKit/UIProcess/Automation/Automation.json: * Source/WebKit/UIProcess/Automation/WebAutomationSession.cpp: (Ref<JSON::ArrayOf<String>> buildArrayForAXChildren) (WebKit::WebAutomationSession::getAccessibilityPropertiesForElement): (WebKit::WebAutomationSession::getAccessibilityPropertiesForAccessibilityNode): * Source/WebKit/UIProcess/Automation/WebAutomationSession.h: * Source/WebKit/UIProcess/WebPageProxy.cpp: * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.cpp: (WebKit::WebAutomationSessionProxy::getAccessibilityPropertiesForElement): (WebKit::WebAutomationSessionProxy::getAccessibilityPropertiesForAccessibilityNode): (WebKit::WebAutomationSessionProxy::getAccessibilityObjectForAXNode) (WebAutomationSessionProxy::ComputedAXProperties getComputedAccessibilityProperties) * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.h: * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.messages.in:

…ccessibilityPropertiesForAccessibilityNode commands https://bugs.webkit.org/show_bug.cgi?id=299508 rdar://161303091 Reviewed by NOBODY (OOPS!). This patch implements two new WebDriver automation commands used to support more robust WPT accessibility testing: - GetAccessibilityPropertiesForElement - GetAccessibilityPropertiesForAccessibilityNode For this initial implementation, test_driver.get_accessibility_properties...() will return an accessibility property bag containing the following computed properties: - accessibilityId - role - label - checked - pressed - children (array of serialized AXIDs) - parent (serialized AXID) As these new WebDriver commands are test-only interfaces, there's been in-depth discussion around how to treat computed AX properties when a property is missing and supported, or present & unsupported; see WICG/aom#203. Some additional resources: - WebDriver PR for the new commands: w3c/webdriver#1960 - ARIA PR for the initial set of computed accessibility properties, and treatment of undefined/missing/unsupported values: w3c/aria#2800. At a high level, the WebDriver client (i.e., Web Platform Tests' testdriver.js) initiates these new commands which is then dispatched to the UI Process (WebAutomationSession). The WebAutomationSession then parses the payload and extracts the protocol-specific element or accessibility node, after which it identifies the target (WebPageProxy) which invokes an asynchronous IPC message to the corresponding Web Process. Note that GetAccessibilityPropertiesForElement uses the same DOM node/frame-based approach as many other WebDriver commands however, GetAccessibilityPropertiesForAXNode does not require frame-based process routing (it retrieves computed accessibility properties using the page's axObjectCache, rather than a specific frame tied to a DOM node); thus, GetAccessibilityPropertiesForAccessibilityNode has a different message signature. Note that to fully support these new WebDriver commands, corresponding WebDriver HTTP endpoints must be implemented in Webdriver for Safari (safaridriver): - session/{session_id}/element/{elId}/accessibilityproperties: Returns accessibility properties for DOM element {elId} - session/{session_id}/accessibility/properties/{accessibilityId}: Returns accessibility properties for accessibility node {accessibilityId} Due to the existence of two AccessibilityProperties protocol object definitions, documentation for each has been updated: - Source/WebKit/UIProcess/Automation/Automation.json — specification conformance and interoperability testing - Source/JavaScriptCore/inspector/protocol/DOM.json — Web Inspector DOM element inspection As an unrelated small fix, the return type for GetComputedLabel (WebAutomationSessionProxy IPC message) incorrectly names the first string parameter as "role" instead of "label" so this patch also corrects the tuple to return (label, errorType). * LayoutTests/resources/testdriver-vendor.js: (window.test_driver_internal.get_accessibility_properties_for_element): (window.test_driver_internal.get_accessibility_properties_for_accessibility_node): * Source/JavaScriptCore/inspector/protocol/DOM.json * Source/WebKit/UIProcess/Automation/Automation.json: * Source/WebKit/UIProcess/Automation/WebAutomationSession.cpp: (Ref<JSON::ArrayOf<String>> buildArrayForAXChildren) (WebKit::WebAutomationSession::getAccessibilityPropertiesForElement): (WebKit::WebAutomationSession::getAccessibilityPropertiesForAccessibilityNode): * Source/WebKit/UIProcess/Automation/WebAutomationSession.h: * Source/WebKit/UIProcess/WebPageProxy.cpp: * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.cpp: (WebKit::WebAutomationSessionProxy::getAccessibilityPropertiesForElement): (WebKit::WebAutomationSessionProxy::getAccessibilityPropertiesForAccessibilityNode): (WebKit::WebAutomationSessionProxy::getAccessibilityObjectForAXNode) (WebAutomationSessionProxy::ComputedAXProperties getComputedAccessibilityProperties) * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.h: * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.messages.in:

…ccessibilityPropertiesForAccessibilityNode commands https://bugs.webkit.org/show_bug.cgi?id=299508 rdar://161303091 Reviewed by NOBODY (OOPS!). This patch implements two new WebDriver automation commands used to support more robust WPT accessibility testing: - GetAccessibilityPropertiesForElement - GetAccessibilityPropertiesForAccessibilityNode For this initial implementation, test_driver.get_accessibility_properties...() will return an accessibility property bag containing the following computed properties: - accessibilityNodeId - role - label - checked - pressed - children (array of serialized AXIDs) - parent (serialized AXID) As these new WebDriver commands are test-only interfaces, there's been in-depth discussion around how to treat computed AX properties when a property is missing and supported, or present & unsupported; see WICG/aom#203. Some additional resources: - WebDriver PR for the new commands: w3c/webdriver#1960 - ARIA PR for the initial set of computed accessibility properties, and treatment of undefined/missing/unsupported values: w3c/aria#2800. At a high level, the WebDriver client (i.e., Web Platform Tests' testdriver.js) initiates these new commands which is then dispatched to the UI Process (WebAutomationSession). The WebAutomationSession then parses the payload and extracts the protocol-specific element or accessibility node, after which it identifies the target (WebPageProxy) which invokes an asynchronous IPC message to the corresponding Web Process. Note that GetAccessibilityPropertiesForElement uses the same DOM node/frame-based approach as many other WebDriver commands however, GetAccessibilityPropertiesForAXNode does not require frame-based process routing (it retrieves computed accessibility properties using the page's axObjectCache, rather than a specific frame tied to a DOM node); thus, GetAccessibilityPropertiesForAccessibilityNode has a different message signature. Note that to fully support these new WebDriver commands, corresponding WebDriver HTTP endpoints must be implemented in Webdriver for Safari (safaridriver): - session/{session_id}/element/{elId}/accessibilityproperties: Returns accessibility properties for DOM element {elId} - session/{session_id}/accessibility/properties/{accessibilityId}: Returns accessibility properties for accessibility node {accessibilityId} Due to the existence of two AccessibilityProperties protocol object definitions, documentation for each has been updated: - Source/WebKit/UIProcess/Automation/Automation.json — specification conformance and interoperability testing - Source/JavaScriptCore/inspector/protocol/DOM.json — Web Inspector DOM element inspection As an unrelated small fix, the return type for GetComputedLabel (WebAutomationSessionProxy IPC message) incorrectly names the first string parameter as "role" instead of "label" so this patch also corrects the tuple to return (label, errorType). * LayoutTests/resources/testdriver-vendor.js: (window.test_driver_internal.get_accessibility_properties_for_element): (window.test_driver_internal.get_accessibility_properties_for_accessibility_node): * Source/JavaScriptCore/inspector/protocol/DOM.json * Source/WebKit/UIProcess/Automation/Automation.json: * Source/WebKit/UIProcess/Automation/WebAutomationSession.cpp: (Ref<JSON::ArrayOf<String>> buildArrayForAXChildren) (WebKit::WebAutomationSession::getAccessibilityPropertiesForElement): (WebKit::WebAutomationSession::getAccessibilityPropertiesForAccessibilityNode): * Source/WebKit/UIProcess/Automation/WebAutomationSession.h: * Source/WebKit/UIProcess/WebPageProxy.cpp: * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.cpp: (WebKit::WebAutomationSessionProxy::getAccessibilityPropertiesForElement): (WebKit::WebAutomationSessionProxy::getAccessibilityPropertiesForAccessibilityNode): (WebKit::WebAutomationSessionProxy::getAccessibilityObjectForAXNode) (WebAutomationSessionProxy::ComputedAXProperties getComputedAccessibilityProperties) * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.h: * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.messages.in:

lolaodelola

This looks good to me

jugglinmike · 2026-06-12T23:07:02Z

+
+<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.
+
+<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:


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?

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 :)

spectranaut

Thanks @jugglinmike and @OrKoN ! I've some fixes, answers and questions.

spectranaut · 2026-06-18T16:32:27Z

+
+<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.
+
+<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:


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 :)

spectranaut · 2026-06-18T16:35:40Z

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


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.

spectranaut · 2026-06-18T16:47:27Z

+
+    <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>.


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).

OrKoN · 2026-06-18T17:09:24Z

+
+<tr>
+  <td>GET</td>
+  <td>/session/{<var>session id</var>}/element/{<var>element id</var>}/accessibilityproperties</td>


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?

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

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.

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.

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.

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

OrKoN · 2026-06-18T17:12:59Z

+<p> <dfn>Accessibility properties</dfn> is a JSON <a>Object</a> that contains the <a>computed accessibility properties</a> of an <a>accessibility node</a>, as well as the following properties:
+
+  <dl>
+   <dt>"<code>accessibilityId</code>"


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?

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.

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.

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)

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

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

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.

OrKoN · 2026-06-18T17:15:31Z

+   <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>An <a>Array</a> of <a>accessibility node IDs</a> representing the child nodes of this <a>accessibility node</a> in the <a>accessibility tree</a>.


Is there something to link to that defines what child nodes are? should this extend into iframes or is it expected to work with https://www.w3.org/TR/webdriver2/#switch-to-frame?

It's a good question. The cross-frame and cross-process hop makes it tricky, and I'd defer to a security analysis of whether its wise to allow that here. @gsnedders, @twilco, @minorninth, @jcsteh, do you have any thoughts?

I don't think it's a security concern, because my understanding is that a WebDriver client has full access to the whole browser - all tabs, all frames. So exposing the whole composed accessibility tree makes sense.

It might be trickier for browsers to implement globally-unique node IDs across all frames. But we definitely need to pick a direction to go here.

Ideas:
(1) browsers could handle all of the details transparently, either coordinating between frames to make globally unique ids, or making ids that are the composition of a frame id and node id
(2) we could expose both a frame id and node id for each node, mirroring the internal structure that (some) browsers actually use
(3) we could scope this API to a single frame and ensure there's a way to identify an iframe element and continue the search from there
...

spectranaut

Thanks again @OrKoN ! I'm out for a week, but wanted to reply to a few things. There is an WPT accessibility interop meeting July 1, I'll bring up some points there.

spectranaut · 2026-06-22T11:48:12Z

+
+    <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>.


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

spectranaut · 2026-06-22T11:56:47Z

+
+<tr>
+  <td>GET</td>
+  <td>/session/{<var>session id</var>}/element/{<var>element id</var>}/accessibilityproperties</td>


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.

spectranaut · 2026-06-22T12:16:08Z

+<p> <dfn>Accessibility properties</dfn> is a JSON <a>Object</a> that contains the <a>computed accessibility properties</a> of an <a>accessibility node</a>, as well as the following properties:
+
+  <dl>
+   <dt>"<code>accessibilityId</code>"


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.

…ccessibilityPropertiesForAccessibilityNode commands https://bugs.webkit.org/show_bug.cgi?id=299508 rdar://161303091 Reviewed by NOBODY (OOPS!). This patch implements two new WebDriver automation commands used to support more robust WPT accessibility testing: - GetAccessibilityPropertiesForElement - GetAccessibilityPropertiesForAccessibilityNode For this initial implementation, test_driver.get_accessibility_properties...() will return an accessibility property bag containing the following computed properties: - accessibilityNodeId - role - label - checked - pressed - children (array of serialized AXIDs) - parent (serialized AXID) As these new WebDriver commands are test-only interfaces, there's been in-depth discussion around how to treat computed AX properties when a property is missing and supported, or present & unsupported; see WICG/aom#203. Some additional resources: - WebDriver PR for the new commands: w3c/webdriver#1960 - ARIA PR for the initial set of computed accessibility properties, and treatment of undefined/missing/unsupported values: w3c/aria#2800. At a high level, the WebDriver client (i.e., Web Platform Tests' testdriver.js) initiates these new commands which is then dispatched to the UI Process (WebAutomationSession). The WebAutomationSession then parses the payload and extracts the protocol-specific element or accessibility node, after which it identifies the target (WebPageProxy) which invokes an asynchronous IPC message to the corresponding Web Process. Note that GetAccessibilityPropertiesForElement uses the same DOM node/frame-based approach as many other WebDriver commands however, GetAccessibilityPropertiesForAXNode does not require frame-based process routing (it retrieves computed accessibility properties using the page's axObjectCache, rather than a specific frame tied to a DOM node); thus, GetAccessibilityPropertiesForAccessibilityNode has a different message signature. Note that to fully support these new WebDriver commands, corresponding WebDriver HTTP endpoints must be implemented in Webdriver for Safari (safaridriver): - session/{session_id}/element/{elId}/accessibilityproperties: Returns accessibility properties for DOM element {elId} - session/{session_id}/accessibility/properties/{accessibilityId}: Returns accessibility properties for accessibility node {accessibilityId} Due to the existence of two AccessibilityProperties protocol object definitions, documentation for each has been updated: - Source/WebKit/UIProcess/Automation/Automation.json — specification conformance and interoperability testing - Source/JavaScriptCore/inspector/protocol/DOM.json — Web Inspector DOM element inspection As an unrelated small fix, the return type for GetComputedLabel (WebAutomationSessionProxy IPC message) incorrectly names the first string parameter as "role" instead of "label" so this patch also corrects the tuple to return (label, errorType). * LayoutTests/resources/testdriver-vendor.js: (window.test_driver_internal.get_accessibility_properties_for_element): (window.test_driver_internal.get_accessibility_properties_for_accessibility_node): * Source/JavaScriptCore/inspector/protocol/DOM.json * Source/WebKit/UIProcess/Automation/Automation.json: * Source/WebKit/UIProcess/Automation/WebAutomationSession.cpp: (Ref<JSON::ArrayOf<String>> buildArrayForAXChildren) (WebKit::WebAutomationSession::getAccessibilityPropertiesForElement): (WebKit::WebAutomationSession::getAccessibilityPropertiesForAccessibilityNode): * Source/WebKit/UIProcess/Automation/WebAutomationSession.h: * Source/WebKit/UIProcess/WebPageProxy.cpp: * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.cpp: (WebKit::WebAutomationSessionProxy::getAccessibilityPropertiesForElement): (WebKit::WebAutomationSessionProxy::getAccessibilityPropertiesForAccessibilityNode): (WebKit::WebAutomationSessionProxy::getAccessibilityObjectForAXNode) (WebAutomationSessionProxy::ComputedAXProperties getComputedAccessibilityProperties) * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.h: * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.messages.in:

…ccessibilityPropertiesForAccessibilityNode commands https://bugs.webkit.org/show_bug.cgi?id=299508 rdar://161303091 Reviewed by NOBODY (OOPS!). This patch implements two new WebDriver automation commands used to support more robust WPT accessibility testing: - GetAccessibilityPropertiesForElement - GetAccessibilityPropertiesForAccessibilityNode For this initial implementation, test_driver.get_accessibility_properties...() will return an accessibility property bag containing the following computed properties: - accessibilityNodeId - role - label - checked - pressed - children (array of serialized AXIDs) - parent (serialized AXID) As these new WebDriver commands are test-only interfaces, there's been in-depth discussion around how to treat computed AX properties when a property is missing and supported, or present & unsupported; see WICG/aom#203. Some additional resources: - WebDriver PR for the new commands: w3c/webdriver#1960 - ARIA PR for the initial set of computed accessibility properties, and treatment of undefined/missing/unsupported values: w3c/aria#2800. At a high level, the WebDriver client (i.e., Web Platform Tests' testdriver.js) initiates these new commands which is then dispatched to the UI Process (WebAutomationSession). The WebAutomationSession then parses the payload and extracts the protocol-specific element or accessibility node, after which it identifies the target (WebPageProxy) which invokes an asynchronous IPC message to the corresponding Web Process. Note that GetAccessibilityPropertiesForElement uses the same DOM node/frame-based approach as many other WebDriver commands however, GetAccessibilityPropertiesForAXNode does not require frame-based process routing (it retrieves computed accessibility properties using the page's axObjectCache, rather than a specific frame tied to a DOM node); thus, GetAccessibilityPropertiesForAccessibilityNode has a different message signature. Note that to fully support these new WebDriver commands, corresponding WebDriver HTTP endpoints must be implemented in Webdriver for Safari (safaridriver): - session/{session_id}/element/{elId}/accessibilityproperties: Returns accessibility properties for DOM element {elId} - session/{session_id}/accessibility/<accessibility node id>/properties/{accessibility node id}: Returns accessibility properties for accessibility node {accessibility node id} Due to the existence of two AccessibilityProperties protocol object definitions, documentation for each has been updated: - Source/WebKit/UIProcess/Automation/Automation.json — specification conformance and interoperability testing - Source/JavaScriptCore/inspector/protocol/DOM.json — Web Inspector DOM element inspection As an unrelated small fix, the return type for GetComputedLabel (WebAutomationSessionProxy IPC message) incorrectly names the first string parameter as "role" instead of "label" so this patch also corrects the tuple to return (label, errorType). * LayoutTests/resources/testdriver-vendor.js: (window.test_driver_internal.get_accessibility_properties_for_element): (window.test_driver_internal.get_accessibility_properties_for_accessibility_node): * Source/JavaScriptCore/inspector/protocol/DOM.json * Source/WebKit/UIProcess/Automation/Automation.json: * Source/WebKit/UIProcess/Automation/WebAutomationSession.cpp: (Ref<JSON::ArrayOf<String>> buildArrayForAXChildren) (WebKit::WebAutomationSession::getAccessibilityPropertiesForElement): (WebKit::WebAutomationSession::getAccessibilityPropertiesForAccessibilityNode): * Source/WebKit/UIProcess/Automation/WebAutomationSession.h: * Source/WebKit/UIProcess/WebPageProxy.h * Source/WebKit/UIProcess/WebPageProxy.cpp: * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.cpp: (WebKit::WebAutomationSessionProxy::getAccessibilityPropertiesForElement): (WebKit::WebAutomationSessionProxy::getAccessibilityPropertiesForAccessibilityNode): (WebKit::WebAutomationSessionProxy::getAccessibilityObjectForAXNode) (WebAutomationSessionProxy::ComputedAXProperties getComputedAccessibilityProperties) * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.h: * Source/WebKit/WebProcess/Automation/WebAutomationSessionProxy.messages.in: * Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in * Source/WebKit/Scripts/webkit/messages.py * Source/WebCore/accessibility/AXObjectCache.h

…tions

lolaodelola · 2026-08-18T17:20:49Z

The build is failing because it can't find accessibility properties or accessibility node ID in the CORE-AAM spec which makes sense because those changes haven't landed yet. There is a recommendation to use lint-ignore for those dfns but I think we should just wait until the changes in CORE have landed before merging this (unless someone is going to remember to remove the lint-ignores once CORE-AAM changes have landed).

The problem could be something completely different, have I missed something?

spectranaut · 2026-08-18T17:43:00Z

The build is failing because it can't find accessibility properties or accessibility node ID in the CORE-AAM spec which makes sense because those changes haven't landed yet. There is a recommendation to use lint-ignore for those dfns but I think we should just wait until the changes in CORE have landed before merging this (unless someone is going to remember to remove the lint-ignores once CORE-AAM changes have landed).

The problem could be something completely different, have I missed something?

Thanks for these changes Lola! I agree that we should land the Core-AAM change first.

Get Accessibility Properties

82d7844

cookiecrook reviewed May 21, 2026

View reviewed changes

cookiecrook mentioned this pull request May 22, 2026

WebDriver: Add support for GetAccessibilityPropertiesForElement, GetAccessibilityPropertiesForAccessibilityNode commands WebKit/WebKit#65058

Open

Accessible object to accessibility node and other fixes

71d6ead

spectranaut commented May 26, 2026

View reviewed changes

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

cookiecrook mentioned this pull request May 29, 2026

Redundancy with the accessibility tree webmachinelearning/webmcp#91

Closed

jcsteh reviewed Jun 3, 2026

View reviewed changes

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

Comment thread index.html Outdated

spectranaut and others added 2 commits June 3, 2026 14:49

Apply suggestions from code review

1c104df

Co-authored-by: James Teh <jamie@jantrid.net>

Update based on convos

f02fdbd

spectranaut marked this pull request as ready for review June 3, 2026 23:48

spectranaut requested review from cookiecrook and jcsteh June 3, 2026 23:48

jcsteh approved these changes Jun 4, 2026

View reviewed changes

Comment thread index.html Outdated

Comment thread index.html Outdated

spectranaut and others added 2 commits June 4, 2026 08:34

Apply suggestion from @jcsteh

174fccf

Co-authored-by: James Teh <jamie@jantrid.net>

Update route name

55e15b3

lolaodelola approved these changes Jun 8, 2026

View reviewed changes

cookiecrook mentioned this pull request Jun 9, 2026

Interop 2026 Accessibility Investigation web-platform-tests/interop-accessibility#202

Open

cookiecrook approved these changes Jun 9, 2026

View reviewed changes

Comment thread index.html Outdated

Comment thread index.html

cookiecrook mentioned this pull request Jun 9, 2026

ARIA spec should distinguish the browser accessibility tree from the platform accessibility tree w3c/aria#2817

Open

Use accessibility node id

24d7021

jugglinmike suggested changes Jun 12, 2026

View reviewed changes

OrKoN reviewed Jun 18, 2026

View reviewed changes

Comment thread index.html

spectranaut added 2 commits June 18, 2026 18:25

Fix typos reported by Mike

4472187

Remove relevant

eef1ef4

spectranaut commented Jun 18, 2026

View reviewed changes

OrKoN reviewed Jun 18, 2026

View reviewed changes

Comment thread index.html Outdated

OrKoN reviewed Jun 18, 2026

View reviewed changes

spectranaut mentioned this pull request Jun 22, 2026

Meeting: July 1, 2026, @ 9 AM PST web-platform-tests/interop-accessibility#236

Closed

spectranaut commented Jun 22, 2026

View reviewed changes

OrKoN requested review from jgraham and whimboo June 22, 2026 13:52

spectranaut mentioned this pull request Jul 21, 2026

Core-AAM: Add Computed Accessibility Properties section w3c/aria#2800

Open

lolaodelola added 2 commits August 18, 2026 13:03

rm accessibility properties definitions, add core-aam links to defini…

1a04a3c

…tions

add acknowledgments

97a068d


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

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


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

Uh oh!

Conversation

spectranaut commented May 12, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

spectranaut left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jcsteh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

spectranaut commented Jun 3, 2026

Uh oh!

jcsteh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

lolaodelola left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

spectranaut left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spectranaut commented May 12, 2026 •

edited by pr-preview Bot

Loading

cookiecrook Jun 30, 2026 •

edited

Loading

cookiecrook Jul 1, 2026 •

edited

Loading

spectranaut Jul 1, 2026 •

edited

Loading