Websites resistant to agent automation: every guide debates the same three Playwright stealth flavors. There is a fourth path nobody is writing about.

If you opened the first six results for this topic, every one of them ran the same playbook: list the anti-bot vendors (Cloudflare, DataDome, PerimeterX, Akamai, Imperva, Kasada), enumerate the leaks (navigator.webdriver, JA3, CDP side effects, behavioral models), recommend a stealth fork (undetected-chromedriver, Puppeteer Stealth, Camoufox, SeleniumBase UC, Nodriver), recommend residential proxies, recommend a CAPTCHA solver service. One of them was honest enough to conclude that stealth Playwright is already losing the arms race and to propose a custom Chromium fork as the answer. None mentioned the path that is sitting in plain sight, and that screen readers have been using since the 1990s.

The thing every guide is fingerprinting

The reason stealth Playwright keeps losing is not that the patches are bad. The patches are excellent. The reason is that the surface they patch is the wrong surface. Every leak below is a property of the automation socket, not the human:

You can fix navigator.webdriver. The next release of the anti-bot script reads a different CDP-only side effect. You can spoof the TLS stack with curl_cffi. The vendor builds a model on the JA3 plus the IP plus the click cadence. You can simulate human mouse curves with Bezier paths. They notice that the curves are too consistent across sessions. The arms race is real and they have more engineers on it than you do.

The honest read on what is happening: the anti-bot industry has accepted that they cannot tell humans from bots from the network alone, so they make the browser itself the witness. The browser leaks its own automation status because the W3C WebDriver spec said it should. CDP leaks because Chrome DevTools needs to. Stealth tools patch what the page can read, but the page can read more next month.

The surface they cannot see

A JavaScript bundle running in a Chrome tab can read what is exposed to it: window properties, navigator, the DOM, network timing, GPU fingerprints, the Permissions API. It cannot read what the operating system is doing above the browser. It cannot tell whether the click that just landed on a button came from a mouse, from a Voice Control command, from a Magnifier accessibility action, or from a UIA synthesized event. They are the same input stream by the time they reach the page.

The first four messages are what Playwright (or any CDP-based driver) looks like from inside the page. The page sees a navigator.webdriver flag and a known CDP-attached state. The last four are what an accessibility-driven click looks like. The page sees the click event and nothing else. The OS-side injection is invisible to the JS runtime because there is no API exposing it.

The 188-line proof: Cloudflare in one accessibility selector

Anything in this argument that cannot be reduced to a code path is handwaving, so here is the code path. The anchor is examples/recaptcha-resolver/resolver.ts in the Terminator repo. 188 lines of TypeScript, importing one thing from terminator.js. The whole flow:

const desktop = new Desktop();
const chrome_app = desktop.application("chrome").window()!;
chrome_app.focus();

const browser_webview = chrome_app.locator(
  "classname:BrowserRootView >> nativeid:RootWebArea"
);
await browser_webview.wait(5000);

// Cloudflare path: one accessibility click.
const cloudflareCheckbox = await browser_webview
  .locator("role:checkbox|name:Verify you are human")
  .first();
cloudflareCheckbox.click();

The Cloudflare branch is at line 160 of the file. It runs when no reCAPTCHA anchor is present on the page. The selector is the same shape an accessibility tester would use: a role and a name. The click is dispatched through Windows UI Automation's Invoke pattern (or, on macOS, through AXUIElementPerformAction with kAXPressAction), the same pattern Voice Control uses to fire buttons.

The reCAPTCHA branch is the same shape, with two extra moves. It captures the image-grid challenge as a screenshot through the accessibility tree (recaptcha_webview.capture()), sends the screenshot plus the cell HTML to Gemini 2.5 Flash with a prompt asking which cell IDs match the target object, parses the ID array, and dispatches clicks back through the same accessibility locator. The image solver needs an LLM because the challenge is visual; the click dispatch path is identical to the Cloudflare case.

What is not in the file: a stealth plugin import, a webdriver flag patch, a TLS rewrite, a residential proxy config, a CAPTCHA solver API key (other than the Gemini key for the image grid), a custom Chromium build. The Chrome window the script controls is the user's regular Chrome, with the user's extensions and the user's cookies, focused with chrome_app.focus() and then talked to through the same accessibility tree a screen reader would walk.

What is and is not visible from the page

Below is the same detection stack from the first section, run against a Terminator-driven Chrome session. Six items the anti-bot script could read on a Playwright session, and what each of them returns when the driver is not in the browser.

Where the OS layer wins, where it does not

The honest comparison. The OS accessibility approach is not universally better than CDP automation, and the cases where it loses are worth knowing before you commit to it.

The CDP path is faster on cooperative pages, supports headless mode out of the box, and is what the entire web testing ecosystem is built around. Use it for the 95% of pages that do not push back. The OS path costs you a real display, costs you a few hundred MB per session, and runs at human-perceptible click latency. In exchange you get a click that anti-bot scripts cannot tell apart from a Voice Control user, and a code surface that does not need a stealth fork maintained against the next anti-bot release. The most reliable production setup is to run both: CDP first, fall back to OS accessibility on pages that detect you.

The one objection that holds up

The OS accessibility layer is not a magical bypass for everything. The anti-bot industry will eventually start fingerprinting accessibility automation directly: AT-SPI hooks on Linux, UIA provider attachment on Windows, AXObserver on macOS. These are weaker signals than the CDP attach because real users with accessibility software running look the same way. But they are not zero. If you are scraping a high-value endpoint where the site has dedicated detection engineers, expect a future round of the arms race to land here too.

The two things that will keep working past that round: behavioral fidelity (replaying recorded human timing instead of synthesizing clicks), and TLS / IP fidelity (using the user's real Chrome on the user's real network, not a datacenter proxy). The OS layer makes both of those cheap to combine because the browser really is the user's Chrome. A stealth Playwright running on a Hetzner box is fighting a different fight.

The other objection that comes up: this is heavier than HTTP scraping. Yes. If the site is happy to serve you JSON without a challenge, do not use a browser at all. The OS accessibility approach is for the case where the site has explicitly decided it does not want automated traffic, and where you have a legitimate reason to be there anyway (your own account, your customer's account, an accessibility audit, a regulatory disclosure, an internal tool that drives a vendor portal that has no API).