Browser Automation for Accessibility Auditing

` doesn't help if nobody checks whether it behaves like one. ## What the population of people affected actually looks like Start with the number, because it's bigger than most product teams assume: roughly one in four adults in the U.S. lives with some form of disability, according to CDC data. That's not a rounding error in a user research deck. That's a meaningful fraction of anyone's actual customer base, whether or not the design team ever thought about them. Disability also isn't a fixed box people sit in forever. Vision changes with age. A hand injury turns a mouse-only interface into a wall. Bright sun on a phone screen at a bus stop does, for about ninety seconds, what low vision does all day. Accessibility isn't a feature for a fixed subset of users; it's a sliding scale that everyone moves along depending on the day, the device, and the light. There's also a business argument sitting right next to the ethical one, and it's worth saying plainly: people with disabilities and their families represent enormous collective spending power. Locking them out of checkout isn't a compliance footnote, it's turning away paying customers at the door. And the asymmetry that makes this sting is that the failures aren't evenly distributed in their impact. Missing alt text is invisible to a sighted user scrolling past. For someone using a screen reader, that same gap is a wall. One user experiences a minor cosmetic absence; another experiences a dead end. Same bug, wildly different consequences. ## The legal and regulatory environment pushing organizations to act Here's where it gets less abstract for anyone holding a budget. Federal ADA web accessibility lawsuits have climbed sharply, and they now make up a large chunk of all federal ADA Title III filings, with e-commerce sites the single most targeted category by a wide margin. If you sell things online, you are, statistically, in the blast radius. What changed recently, and this is the detail that should get more attention than it does: a significant share of 2025 filings came from self-represented plaintiffs. Meaning you don't need a plaintiff's firm anymore to file. The barrier to bringing a claim dropped, and litigation volume doesn't need an organized legal apparatus behind it to keep climbing. Serial litigation is also a documented pattern; a lot of defendants had already been sued once before and hadn't fixed the underlying issue. That's the expensive kind of forgetting. The math here isn't subtle. Ongoing monitoring costs a sliver of what a single settlement runs. It's the difference between an oil change and a new engine, and yet plenty of companies wait for the engine to seize. One category worth calling out by name: accessibility overlay widgets, the little floating icons promising instant compliance. Regulators have taken action against companies making those claims, because bolting a JavaScript widget onto a broken site doesn't fix the site; it just adds a widget. Overseas, the European Accessibility Act came into full effect in mid-2025, and it pulls a large portion of the private sector into scope, not just public institutions. That's a meaningful expansion, and it lands right as U.S. teams are also digesting where the bar actually sits. U.S. rules formally point to WCAG 2.1 AA, but 2.2 is close to a superset of 2.1, so building to 2.2 satisfies the letter of current regulation and gets ahead of the next one. WCAG 3.0 is out there on the horizon with a new scoring model, but it's still in draft form; 2.2 is the target that actually matters right now. ## Where manual auditing hits a wall and where it remains irreplaceable A proper manual review of one page takes real time from someone who actually knows what they're looking at. Now multiply that by a site with eight hundred URLs. It doesn't scale, and pretending otherwise is how audits quietly stop happening. Automated tools catch a meaningful slice of WCAG issues, but nowhere near all of them, and the rest genuinely need a human judgment call. A UK government study built a test page loaded with known accessibility barriers on purpose, then ran a batch of popular automated tools against it. The best performer caught well under half the barriers. The worst caught only a small fraction. That's not a knock on the tools; it's a reminder of what they were built to do and, just as important, what they weren't. What automation can't do, and won't be able to do anytime soon: tell you whether alt text is actually descriptive versus just present, judge whether a reading order makes logical sense to a human brain, watch how a custom dropdown behaves when a real screen reader tabs through it, or assess whether a page is cognitively exhausting to parse. These require a person sitting there with JAWS or VoiceOver running, actually experiencing the page the way a real user would. That's the part manual testing owns outright: operating the actual assistive technology, applying judgment where WCAG criteria are deliberately written to require context, and catching the stuff that's technically compliant but still miserable to use. Automated and manual testing aren't competing for the same job. They're covering two different halves of the same problem, and a program that only does one is, at best, half-finished. ## What browser automation actually does that static scans cannot Here's the detail that trips people up: a lot of accessibility failures don't exist in the raw HTML at all. They only show up once the page renders and JavaScript runs. A static scanner reading source code will miss them entirely, because there's nothing to see until the browser does its job. Browser automation solves this by being, well, an actual browser. Tools like Playwright spin up a real Chromium, Firefox, or WebKit instance, execute the JavaScript, load the dynamic content, and interact with the page the way a person with a mouse and keyboard would. That's the whole trick. Think about what only exists after a click: a modal window opening, and whether focus actually lands inside it and stays trapped there until it closes. A dropdown menu, and whether you can operate it with the Tab key alone. A form validation error, and whether the error message is actually linked to the input field so a screen reader announces it instead of leaving the user guessing what went wrong. A single-page app route change, where the URL updates but nothing tells assistive technology that the page effectively changed underneath it. None of that exists in a static HTML file. It only exists once the browser executes. WCAG 2.2 leaned into this reality directly, adding criteria that are inherently about interaction: focus not getting hidden behind a sticky header, minimum tap target sizes, alternatives to drag gestures. You cannot check any of these against markup sitting on disk. You need something rendering the page and poking at it. And underneath all of this sits the real target: the accessibility tree, which is the structured representation that screen readers and other assistive tech actually read, distinct from the visual layout a sighted developer is staring at. Browser automation can query and assert against that tree directly, which is closer to testing what users actually experience than eyeballing a Figma file ever was. ## The tools doing most of the work in 2025 and 2026 and what each is suited for axe-core, built by Deque Systems, is the engine sitting under most of this industry whether people realize it or not. It's open-source, mapped to WCAG 2.0, 2.1, and 2.2 success criteria, and deliberately conservative about what it flags, meaning if axe-core says something's a violation, it usually is. Google Lighthouse runs on it. Microsoft Accessibility Insights runs on it. It ships as bindings for Playwright, Cypress, Jest, and most React testing setups, so plenty of teams are already running axe-core without ever having installed it by name. Pair axe-core with Playwright and you get the combination doing most of the heavy lifting in CI pipelines right now. Playwright drives the real browser and scripts the interactions; axe-core evaluates the resulting DOM and hands back violations tied to specific selectors, so a developer gets an actual element to fix, not just a vague score. Playwright's `locator.ariaSnapshot()`, added in version 1.49, captures the accessibility tree as readable YAML, which means you can snapshot it and catch regressions where the tree silently changes between builds even though the screen looks identical. Microsoft's Playwright MCP server, released in early 2025, lets AI agents navigate a page through the accessibility tree instead of screenshots, which is a strange and genuinely promising direction worth keeping an eye on. This combination fits teams that already run a test suite and a CI pipeline and want accessibility checks living right next to their unit tests. Google Lighthouse is the one most developers have already used, usually without meaning to, since it's built straight into Chrome DevTools. Zero setup, and it checks accessibility alongside performance and SEO in the same run, plus it's scriptable through Lighthouse CI for pipeline use. Its rule set is narrower than a dedicated tool, though, and the accessibility score it spits out is easy to over-read as a full compliance stamp when it's really a quick temperature check. Good for early development-stage looks and teams not yet running anything dedicated. WAVE, from WebAIM, runs as a browser extension for Chrome, Firefox, and Edge, evaluating the page as rendered right inside your own browser, which means it can reach password-protected pages and intranet tools that a crawler never could. It also draws a visual overlay right on the page showing where problems sit, which makes it genuinely useful for content and editorial teams, not just engineers staring at a terminal. Pa11y is the command-line option, built for CI integration with a dashboard for tracking results over time. Its real strength is repeatability: run it against the same templates release after release and watch the trend line. It asks more of non-technical users than WAVE does, so it tends to live with engineering rather than content teams. At the top end sit enterprise governance platforms like Siteimprove and BrowserStack's Website Scanner, built for organizations managing dozens or hundreds of properties who need scheduled domain-wide scans, trend reporting across teams, and an audit trail they can hand to legal or procurement. If you're running one site, this is overkill. If you're running forty, it's closer to essential. ## Which checks belong in automation, which need human escalation, and how to decide The sorting question is straightforward once you name it: is this check binary and independent of context, or does it require someone to judge meaning and intent? If a machine can answer it with a yes or no without understanding what the page is actually trying to say, automate it. Strong automation candidates: whether an image has an alt attribute at all, contrast ratios (this is pure math against a threshold, and automation gets it right close to every time), whether form inputs have an associated label, whether the page declares a language, whether the title tag exists and is unique across routes, whether ARIA roles used are valid and not deprecated. These are pattern-matching problems, and pattern matching is what software is for. Then there's the murkier middle: things automation flags but a human has to actually evaluate. An image might have alt text, but is it "image1234.jpg" or does it describe what's actually in the photo? A link might avoid the phrase "click here," but is the surrounding text actually unambiguous out of context? Headings might exist in the right order structurally, but does that order reflect how a person would actually organize the content? Automation gets you to the question. It doesn't answer it. And some things belong entirely to a human with assistive technology running: how a screen reader actually announces a custom widget, whether a page is cognitively exhausting to read, whether focus lands somewhere sensible after a modal closes, whether a drag-based interaction has a real keyboard equivalent or just a token gesture toward one. A workable triage model looks like this: automated checks run on every build and catch regressions immediately; anything requiring judgment gets routed to a reviewer with the specific element and page attached; assistive technology testing happens on a schedule tied to major releases, not whenever someone remembers to do it. ## Building automation into a continuous workflow rather than a one-time audit A one-time audit is a photograph. A continuous pipeline is closer to a heartbeat monitor. That distinction matters because a page that passed its accessibility audit in March can be quietly broken by June, thanks to a component update nobody thought to re-check. A workable pattern in practice: every pull request runs a targeted accessibility test against whatever components or routes it touches. Nightly or pre-release builds run the full site scan, wide enough to catch problems that build up gradually across many small changes. Violations should fail the build or block the merge, not just print a warning that everyone learns to scroll past; a check with no teeth changes nothing. Results should show up in the same CI dashboard as everything else, right next to test coverage and build time, so accessibility looks like a normal engineering metric instead of a special annual event. Accessibility tree snapshots, using that Playwright capability mentioned earlier, catch a specific and sneaky failure mode: a component refactor that changes what's exposed to assistive tech while the visual UI looks completely untouched. Nobody notices in a design review. A snapshot diff catches it in seconds. Not every page needs the same depth of coverage, and pretending otherwise wastes engineering time. Checkout flows, account forms, login screens: these deserve full scripted interaction testing, focus traps and all. Most ordinary content pages inherit coverage from their template; test the template once, thoroughly, and every page built on it benefits. New interactive components and edge cases should trigger their own targeted test the moment they land. And here's the quiet economic case for all this: once the pipeline exists, checking an already-covered page again costs almost nothing. Re-auditing that same page manually every quarter costs real hours, every single time. There's also a paper trail benefit that's easy to undervalue: dated records of violations found and fixed are useful in litigation, useful in procurement conversations, and useful for keeping your own team honest about what actually got fixed versus what got a Jira ticket and nothing else. ## Where the current tooling still leaves gaps and what fills them Even the best setup around right now, Playwright driving axe-core across a scripted interaction suite, only sees what shows up in the DOM and the accessibility tree. It has no concept of whether the experience is actually good, whether the cognitive load is reasonable, or how a real assistive technology user would actually feel navigating it. That's not a flaw in the tooling. That's just the edge of what code can measure. The ARIA problem deserves a second look here, because it's the whole piece's opening puzzle circling back. ARIA errors climbing right alongside ARIA adoption isn't a tooling failure; automation catches syntax problems just fine. It's a training failure. Developers reach for `aria-label` and custom roles because they solve an immediate visual problem, without necessarily understanding what those attributes tell a screen reader to actually do. No scanner fixes that. Only better developer education does, alongside design systems that bake accessible patterns in by default so nobody has to reinvent a combobox from scratch and get the ARIA wrong for the hundredth time. And then there's the false-confidence trap, which might be the most expensive gap of all: a clean Lighthouse score or a passing axe-core run feels like a finish line. It isn't one. It's a floor, not a ceiling, and treating it as proof of full compliance is exactly how teams end up blindsided by a lawsuit over an issue their dashboard never had the vocabulary to flag in the first place.