A node with an id in the a11y tree

Where the "node with an id" pattern comes from

Chrome builds an accessibility tree next to the DOM, the same one a screen reader consumes. The Chrome DevTools Protocol exposes it through the Accessibility domain: getFullAXTree and getPartialAXTree return AXNode objects, each carrying a nodeId, and getChildAXNodes walks the tree by that id. Every higher-level tool inherits this: Playwright, browser-use, and the various MCP accessibility bridges all hand a model a flattened snapshot where each interactive node has a short ref, then translate "act on ref e7" back into a real node.

The id is the contract. The part that decides what to do (a person, a test script, an LLM) names a node by its id. The part that does it re-finds that node in the live tree and clicks it. Neither side has to agree on where the node is on screen, only on which node it is. That decoupling is what made accessibility-tree automation more reliable than coordinate clicking, and it is the entire reason this question keeps coming up.

The browser's a11y tree stops at the edge of the tab

Here is the catch nobody mentions when they explain AXNodeId. The Chrome accessibility tree only contains the web page. The moment your workflow touches a native dialog, the file picker, a desktop app, or the OS chrome around the tab, the browser's tree ends and your node ids end with it. You are back to coordinates and screenshots for the part of the job that lives outside the page.

Windows and macOS publish accessibility trees too, for the exact same reason browsers do: screen readers need them. On Windows that tree is UI Automation (UIA); on macOS it is AX. Every native window, button, and field is already a node in it. The question is whether your automation engine surfaces those nodes with stable ids the way the browser does. Terminator does, with an API deliberately shaped like the browser one so the mental model carries over unchanged.

How Terminator computes a node's id

This is the part you cannot read anywhere else, so here is the actual mechanism rather than a hand-wave. On Windows the id comes from generate_element_id() in crates/terminator/src/platforms/windows/utils.rs (the function starts at line 23). It does not assign a random handle. It builds an id from the content of the node, so the same logical element produces the same id on the next run.

The ordering matters. Because AutomationId comes first, a node the app developer explicitly named gets an id dominated by that name, which is the most stable input available. A node with only a role and a label still gets a content id; an anonymous, unbounded node still gets something usable. The id never throws, it just degrades, and you can read the degradation level off how the node was hashed.

// stable inputs, in order
let mut to_hash = String::new();
if let Some(id) = automation_id { to_hash.push_str(&id); }
if let Some(role) = role        { to_hash.push_str(&role.to_string()); }
if let Some(n) = name           { to_hash.push_str(&n); }
if let Some(cn) = class_name    { to_hash.push_str(&cn); }

// fallbacks if no stable properties existed
if to_hash.is_empty() { /* hash the bounding rectangle */ }
if to_hash.is_empty() { /* last resort: object pointer  */ }

let hash = blake3::hash(to_hash.as_bytes());
Ok(hash.as_bytes()[0..8]
    .try_into()
    .map(u64::from_le_bytes)
    .unwrap() as usize)

The public id() method then runs object_id().to_string().chars().take(6).collect(), so what you see on a node is the leading 6 characters of that hashed number.

What the model actually sees: indexed nodes, by source

A 6-character hash is great for logging and for the id: selector, but it is a clumsy thing to ask a language model to type back to you. So when Terminator's MCP server hands a tree to an agent, it prints a much shorter handle next to each node: a sequential index. Nodes that have on-screen bounds (the ones you can actually click) get a clickable index; nodes without bounds get a dash. The agent says "click 4", and the server maps 4 back to the node and its bounds.

When a window mixes sources, the index gets a one-letter prefix so the handle stays unambiguous. From crates/terminator/src/tree_formatter.rs, the ElementSource enum defines exactly five prefixes:

So a single "node with an id" can come from the accessibility tree (u), from the page DOM inside a browser window (d), or from a vision pass when an app exposes nothing structural at all. The agent treats them the same way, as an indexed handle to act on. That is the bridge: the browser's DOM nodes and the OS's accessibility nodes end up in one unified, indexed list.

u1 [Window] "Save As"            (bounds: [220,140,640,480])
  u2 [ComboBox] "File name"      (bounds: [330,360,360,28])
  u3 [Button] "Save"            (bounds: [700,420,90,30])
  -  [Text] "Encoding:"          (no bounds, not clickable)
d4 [link] "terms"                (bounds: [380,300,52,18])
o5 [ocr] "Read only"             (bounds: [340,398,70,16])

Clickable nodes get a prefixed index; the un-bounded text node gets a dash. The agent acts on u3, not on a pixel.

Acting on a node by its id, in your own code

Outside the agent loop, you target nodes with selectors, and the id is one of the things you can select on. The API is Playwright-shaped, so if you have written browser automation the muscle memory transfers. You build a locator, the engine resolves it against the live accessibility tree, and you act.

// page accessibility tree only
const snapshot =
  await page.accessibility.snapshot();
// act on a node from the snapshot
await page.getByRole("button",
  { name: "Save" }).click();

When the browser's own a11y tree is still the right answer

If your entire workflow lives inside a single web page and never touches a native dialog, the browser's accessibility tree is already perfect for the job. Playwright's role locators and the Chrome DevTools AXNodeId give you stable node handles with zero extra dependencies, and you should use them. The honest tradeoff: Terminator adds value precisely when the workflow leaves the tab. Native file pickers, installer wizards, line-of-business desktop apps, the OS chrome around the browser, anything where the page's tree simply does not reach. That is the seam where a node id from the OS tree starts mattering and a browser ref runs out.

Worth saying plainly: the deep id mechanism described here is the Windows UIA path, which is where Terminator's native-id support is most complete. If you are deciding between approaches, that is the context to weigh it in.