Automated accessibility testing is a rules engine over the rendered DOM. It is fast, cheap, repeatable and limited by construction: it can only decide criteria that have a machine-checkable answer. Treating its output as the whole picture is how sites with clean scans end up in demand letters. This page is what it decides, where to run it, and how to size the part it cannot see. On the worked example the manual half is 11 hours of testing across 19 sampled pages.
What it decides
Presence and value facts: alt attributes, form labels and accessible names, contrast ratios, document language, duplicate ids, heading order, ARIA attribute validity. These are real failures and they are the ones a plaintiff's scan will find too, which is why clearing them first is both cheap and urgent.
What it cannot decide
Whether alt text describes the image, whether the reading order matches the visual order, whether a custom widget announces its state, whether error recovery is possible, whether focus is managed across a route change. No amount of tuning changes this: the questions are about meaning and behaviour.
Where automation belongs
In the build, on the templates, failing the pipeline on new violations. That keeps a remediated site remediated, which is the failure mode of every programme that stops at the report. Run it against the audit's sample too, so the manual pass starts from a page whose cheap failures are gone.
Questions people ask about automated accessibility testing
What share of issues is automatable?
Commonly cited figures vary and none of them are load-bearing here: run both passes and count your own. On the worked example the manual pass is 11 of the audit's 23 hours.
Can we fail the build on any violation?
Start with new violations on changed templates. Failing on the whole backlog on day one gets the check switched off.
Is accessibility testing automation a substitute for an audit?
No, and no vendor of it claims so in writing.