ATS automation should drive the same surface a screen reader sees.

It means driving the ATS user interface through the browser's accessibility tree, the structured ARIA-labeled snapshot the browser already exposes for screen readers, instead of querying CSS selectors or interpreting pixel screenshots. An agent reads the tree, finds an interactive control by its role and accessible name (button 'Move to onsite', combobox 'Select stage', textbox 'Reject reason'), and acts on it. Greenhouse, Lever, Workday Recruiting and Ashby all publish WCAG 2.1 AA or 2.2 AA conformance, which means the tree is dense and stable enough to script. The selectors look like locator.getByRole('button', { name: 'Move to onsite' }) in Playwright, or the equivalent in any tool that reads the same accessibility surface.

Because the accessibility tree is a procurement contract. ATS vendors selling into federal agencies, public universities, and most Fortune 1000 employers must publish a VPAT declaring conformance to WCAG 2.1 AA, Section 508, and (for EU buyers) EN 301 549. Once a control is shipped with a published role and accessible name, changing those breaks the conformance claim and breaks every assistive technology that relies on the tree. Class names like .ats__StageDropdown_xX91 are an internal implementation detail and rotate with every redesign. Roles and names are a published API in everything but name.

Yes. Workday publishes a public accessibility statement declaring WCAG 2.2 Levels A and AA plus Section 508 and EN 301 549 conformance. Greenhouse, Lever, and Ashby publish VPATs on request and ship ARIA roles on every interactive surface in the recruiter UI. The exact accessible names vary across vendors (the move-to-stage button reads 'Move' on Greenhouse, 'Advance' on Lever, 'Change Stage' on Workday and 'Move stage' on Ashby), so the selector is per-vendor, but the integration shape is identical: snapshot the tree, find by role and name, fire the action, capture the resulting tree as the diff.

RPA tools (UiPath, Automation Anywhere, Blue Prism) historically targeted Windows desktop ATSes with image recognition and brittle XPath fallbacks; the cost was a fragile recorded macro that broke on every UI tweak. Computer-use agents (Anthropic computer use, OpenAI Operator) read pixels and infer affordances from screenshots; the cost is tokens (a 1024x768 screenshot is 1568 image tokens before any reasoning) and a slower loop. Accessibility-tree integration sits in between: cheaper than vision because the tree is text, more stable than RPA because role+name is a published contract, and faster than either because the snapshot is already structured.

Every action writes a row with actor (the agent identifier and the recruiter who approved), tool (ats.move_stage, ats.add_note, ats.send_message), target (a role+name pair plus the rendered text snapshot of the affected node), prior_state (the tree slice before the action), new_state (the tree slice after), and a content hash of both. Regulators auditing under NYC Local Law 144, Illinois HB 3773, Colorado CAIA, or the EU AI Act high-risk hiring rules can replay any decision because the audit row contains both the surface the agent saw and the surface it produced. CSS-selector logs and pixel logs do not give regulators that.

Every UI action the agent takes is a draft, not a fired action. The agent computes the role+name target, captures the before-tree, and writes a draft to the approval queue (Gmail label, Slack channel, web view, same shape across all three). The recruiter taps approve and the action fires against the live ATS through the accessibility tree; the after-tree is captured and written to the audit log next to the approval. The queue is the human-in-the-loop gate every 2026 AI hiring law expects, and the accessibility tree is what makes the diff cheap to compute and small enough to render in the queue.

Use the public API when it exists and covers the surface area you need. Greenhouse Harvest, Lever Data API, Workday Recruiting REST and Ashby Public API cover candidate read, candidate write, application stage transitions, and event webhooks. The accessibility tree is for the long tail the API does not cover (custom scorecard fields a customer added in the admin panel, vendor-specific dropdowns, multi-step approval modals, anything behind a feature flag the API has not caught up to). It is also the bridge while a customer is migrating between ATSes and the API surface is in flux. The two integrations coexist; an agent uses the API when the surface exists and falls through to the tree when it does not.

Iframes break naive DOM scrapers and most screen-recording RPA, but the accessibility tree composes across iframe boundaries because assistive technology has to traverse them. Playwright's frameLocator drops into the iframe and getByRole works as normal; computer-use accessibility-snapshot mode handles the same case at the OS level. Shadow DOM is similar: closed shadow roots are a problem for both DOM and a11y trees, but most ATS UIs use open shadow roots or no shadow DOM at all because closed roots also break screen readers and would fail the WCAG audit. Dynamic content (toasts, async loaders, optimistic state) is handled by waiting on a role transition, the same way a screen-reader user waits for the live region to announce.

Every named agent that drives an ATS UI uses role+name selectors first and falls back to the public API when the surface is exposed there. The Sourcing Agent reads candidate dossiers from a role+name walk of the candidate listing page; the Scheduling Agent drafts the panel emails by reading the role+name structure of the candidate timeline; the Match Rating agent writes the override audit row keyed to the same role+name target the recruiter saw. Every action surfaces in the approval queue as a draft with the tree snapshot attached. We do this because it is the only architecture that survives ATS UI redesigns and produces an audit log a regulator will accept.

Then the accessibility tree is sparse and the integration falls back to CSS selectors or vision for the missing controls, with a flag in the audit log noting that the action did not target a role+name pair. That happens, but rarely on the major ATSes; the procurement contracts force conformance because federal agencies and public universities cannot legally buy a non-conforming ATS. When it does happen, it is on a custom internal admin tool or on a startup ATS that has not shipped its first VPAT yet. The integration tracks per-vendor conformance and warns when a target falls back to a less stable selector.