1
0 Comments

The 5 WCAG issues that eat 80% of an accessibility audit (and why scanners miss most of them)

Been doing manual accessibility audits on government and nonprofit sites for a few months now, mostly for AccessiScan (our WCAG audit tool). We run automated checks first, then do a manual pass before writing the report. After about 40 sites, a pattern is obvious.

Automated scanners catch somewhere between 30-40% of real WCAG violations on a typical site. That's about the ceiling for axe-core and its derivatives, and the numbers are consistent with published research from Deque. The rest requires a human looking at the page.

Here's where the other 60% hides:

Focus visibility. The most common single failure. A developer adds outline: none to get rid of the browser default ring, then adds a custom focus style that only works on the default background. Then someone changes the card hover state and the focus ring disappears entirely on hover because it was set in the :hover state and got overridden. Automated tools can detect missing outline: none, but they can't simulate the interaction chain that makes the ring invisible.

Form error association. You have an error message below an input. It even says "this field is required". But the aria-describedby on the input points to an element that doesn't exist in the DOM yet at page load (the error message renders conditionally via JS). A screen reader user submits the form and hears nothing about what went wrong. The scanner sees the label and marks it green.

Color contrast in interactive states. Tools check the default text on default background. They don't check the disabled button (often #aaa on #f5f5f5, which fails). They don't check selected items in a dropdown. They don't check the visited link color. None of these are hard to fix once you find them, but they're invisible to automated tools.

PDF documents. About 60% of the government sites we audit have untagged PDFs linked from the page. The page itself can be fully WCAG-compliant. The linked report from 2019 is completely inaccessible to screen reader users. Automated scanners never follow the PDF link. A scanner reporting "0 violations" on a site with 40 untagged PDFs is technically accurate and completely misleading.

Keyboard traps in modals. A lot of modern cookie consent banners and modals trap focus correctly when they open (good) but release it to document.body on close instead of the element that triggered the modal (bad). For a keyboard user, every time they dismiss a cookie banner they're now at the top of the page. Automated tools rarely simulate the full open-close cycle.

Worth noting: none of this makes automated scanning useless. The 30-40% it catches is real violations that would otherwise take a human hours to find. The point is that "our scanner passed" is a floor, not a ceiling.

We built AccessiScan (accessiscan.piposlab.com) to do the full pass, manual review included in the documented audit tier. Mostly sharing this because the gap between automated and manual keeps surprising people who assume one equals the other.

on June 30, 2026