Drive the surface a screen reader sees, not the bag of pixels.

Anthropic publishes the formula in its vision docs: image_tokens = width * height / 750. A 1280x800 candidate-page screenshot is ~1365 image tokens, capped at 1568 on Claude Sonnet 4.6 once the image crosses ~1.18 megapixels, or up to 4784 tokens on Claude Opus 4.7 (long-edge cap 2576 px). The same candidate page rendered via Playwright's locator.ariaSnapshot() is a YAML subtree of a few hundred tokens for the relevant region. Per recruiter action that is a ratio of roughly 4 to 8 times. At a one-recruiter team running 200 to 300 stage transitions a week, the bill compounds visibly.

Two reasons. First, every major ATS publishes WCAG 2.1 AA or 2.2 AA conformance because federal procurement requires a VPAT under Section 508 and EU buyers require EN 301 549. That makes the tree dense, semantically labeled, and stable across releases. Second, the audit row a tree-driven action produces (role, accessible name, before-tree-hash, after-tree-hash) is the shape NYC Local Law 144, Illinois HB 3773, Colorado CAIA, and the EU AI Act high-risk hiring rules expect. A screenshot log gives a regulator a bag of pixels; a tree-hash log gives a regulator a replayable surface. Both arguments only hold this strongly inside the ATS category.

Three cases. First, surfaces with no published accessibility tree (rare on Greenhouse, Lever, Workday, Ashby, but common on internal admin tools or pre-VPAT startup ATSes). Second, genuinely visual decisions like cropping a candidate avatar or reading a hand-scanned PDF inside an attachment preview, which require pixel input the tree does not encode. Third, captcha and visual challenges intended to defeat automation, which the tree cannot help with by design. The pragmatic shape is tree-first with vision as a typed fallback flagged in the audit log.

The CSS selector targets an internal implementation detail. div.candidate-row .stage-btn--rev4 survives until the next refactor, and class hashes rotate on every release of every modern ATS. locator.getByRole('button', { name: 'Move stage' }) targets a published surface the vendor cannot quietly rotate without breaking screen readers and the VPAT. The role+name pair is in everything but name a public API the procurement contract guarantees. The CSS path has no such guarantee.

Better, in practice. The accessibility tree composes across iframe boundaries because assistive technology has to traverse them; Playwright's frameLocator drops in and getByRole works as normal. Closed shadow DOM is a problem for both DOM scrapers and a11y trees, but most ATS UIs avoid closed shadow roots because they would also break screen readers and fail the WCAG audit. Screenshots traverse iframes trivially because pixels do not care about boundaries, but they pay the token cost on every frame, and they cannot tell a regulator what the recruiter actually saw.

The integration breaks loudly on the next snapshot diff. A weekly health check captures the candidate flow against a fixture and diffs role+name pairs against the per-vendor dictionary. A rotated verb (Greenhouse 'Move' becoming 'Advance to stage') triggers a page to the on-call. Vendors do not announce these changes, so the diff is the only signal. The screenshot equivalent is harder: a vision model often silently keeps clicking the same place even when the rendered label has changed, which is worse than a loud break.

Yes. Anthropic's computer use tool exposes accessibility-snapshot mode in addition to screenshots; the input is the same role-and-name surface a Playwright getByRole call walks. OpenAI Operator's underlying model is multimodal and can be steered with a textual ARIA snapshot in the prompt instead of a raw screenshot, which trades a few hundred tokens of structured input for the per-image cost. The pattern is to feed the model the tree first and only attach a screenshot when the answer requires a visual decision the tree cannot encode.

page.locator('body').ariaSnapshot() returns a YAML representation of the accessible structure under the locator, with role, accessible name, and ARIA attributes like checked, expanded, level. The output is small enough to fit in a model context, stable enough to assert against in tests, and structured enough to feed into an action planner. The same surface drives the locator.getByRole API, so the snapshot you read and the selector you write target identical nodes.

Tool ats.move_stage, vendor ashby, target_role button, target_name 'Move stage', from_stage 'Phone screen', to_stage 'Onsite', before_tree_sha256, after_tree_sha256, actor_agent, approved_by, approval_latency_ms, queue_surface. A regulator can replay that row against the same surface a screen-reader user would have walked, because role and name are the contract. The screenshot equivalent is a folder of 1280x800 PNGs the compliance team has to reverse-engineer into actions; the diff is human, slow, and hard to attest.

Tree-first by default, vision typed as a fallback. Every named agent that drives an ATS UI uses role+name selectors against the published tree and falls back to the public API when the surface exists there. The fallback to vision is reserved for genuinely visual decisions and is flagged in the audit row so a regulator can see which actions were tree-driven and which were not. Every action sits in the recruiter approval queue as a draft with the tree snapshot attached. We do this because it is the only architecture we have found that survives an ATS UI redesign and produces an audit log a 2026 hiring-law regulator will accept.