The report looks finished. The site is not.
A familiar meeting: someone shares a dashboard with a score, a trend line going the right way, and a count of errors fixed this quarter. Leadership hears “we are handling accessibility.” Then a student using a screen reader still cannot finish the financial aid form.
Both things are true at once. The scan is real, and the barrier is real. That gap is why an automated scan is a tool inside a remediation program, not the program itself.
What scanners are good at
Automated tools are fast and consistent. They catch problems a machine can detect from code: missing alt attributes, empty links, missing form labels, some contrast failures, duplicate IDs, and pages with no language set. Run across hundreds of sites, they show you where the worst templates are and whether things are getting better.
That is valuable. Keep the scan.
What scanners cannot see
Many WCAG 2.1 success criteria need human judgment. A scanner can tell you an image has alt text. It cannot tell you the alt text is wrong. It can see a heading tag. It cannot tell you the heading order makes no sense to someone listening to the page.
Common gaps we find in manual review:
- Keyboard traps in menus, modals, and carousels.
- Focus that disappears or jumps around the page.
- Link text like “read more” repeated ten times.
- Forms that announce errors only with color.
- PDFs that are images of text.
- Video without accurate captions.
The success criteria themselves are in the WCAG 2.1 specification from the W3C. Read a few and you will see how many depend on meaning, not markup.
What a remediation program adds
Manual testing on the pages that matter
Keyboard-only and screen reader testing on your highest-traffic and highest-stakes journeys: apply, pay, register, request, report.
Fixes at the template level
One fixed component can repair thousands of pages. This is where development time pays back fastest.
Editor training
Editors publish every day. If they do not know how to write link text, structure headings, or tag a table, the scan count climbs again next month.
A cadence
Monthly review, quarterly fix sprints, and a gate before new sites launch. The KWALL Accessibility & Compliance program is structured that way because content never stops changing.
Why this matters more under Title II
On April 20, 2026, the Department of Justice extended the Title II web and mobile app compliance dates. State and local government entities with a total population of 50,000 or more now have until April 26, 2027. Entities under 50,000, and every special district government, now have until April 26, 2028. The technical standard did not change: WCAG 2.1 Level AA. Source: the DOJ interim final rule extending the Title II compliance dates (91 FR 20902).
The rule names a standard. A score from a tool is not the same as meeting it. If your plan to April 2027 is “keep the score green,” it is a monitoring plan. You still need the remediation plan.
A hypothetical: the green dashboard and the failed form
Imagine a county whose scanner shows steady improvement for a year. Error counts fall on every site. Then a resident who uses a screen reader reports that the online permit form cannot be submitted. The form passes the scanner because every field has a label in the code. The problem is a custom date picker that traps keyboard focus, which no automated rule flagged.
Nobody was careless. The team trusted a tool to do a job it was never built to do.
How to tell if you have a scanning program or a remediation program
Ask these questions about the last six months:
- Did anyone test your top five tasks with only a keyboard?
- Did anyone test them with a screen reader?
- Were fixes made in shared components, or page by page?
- Did editors get training on headings, links, alt text, and documents?
- Is there a review step before new sites or features launch?
- Do barrier reports from the public go into the same backlog as scan results?
If most answers are no, you have monitoring. That is worth keeping. It is not the whole job.
Where to put effort first
- Top tasks. List the journeys people cannot avoid: apply, pay, register, request, report. Test them manually first.
- Shared components. Menus, forms, modals, accordions, and media players appear everywhere. Fix them once.
- Documents. Required forms and notices published as PDFs often need the most hands-on work.
- Everything else, guided by scan results and traffic.
Frequently asked questions
Should we stop paying for a scanner?
No. Scanning is the right way to watch a large estate over time. Pair it with manual testing and fixes.
Does an overlay widget fix accessibility issues?
Overlays do not fix the underlying code or content issues. Conformance comes from fixing the site itself: its components, content, and documents.
How often should manual testing happen?
At least on every major release and on your key journeys on a regular cycle. Many teams start monthly on top tasks and expand from there.
Is a VPAT the same as an audit?
No. A VPAT documents how a product conforms. It should be based on testing, but it is a report, not the testing itself.
What should manual testing include at minimum?
Keyboard-only navigation, a screen reader pass on key journeys, zoom and reflow checks, and a review of captions and documents on those journeys.
Who should do manual testing?
People trained in WCAG and assistive technology. Including people who use assistive technology every day adds findings that checklists miss.
Next step
If you have a scan and want to know what it is missing, tell us what you are working on.
