Peradeo Blog · WCAG · Published 2026-09-06 · 12 min read

What Automated Accessibility Scans Miss: Real WCAG Failures That Still Need Manual Testing

By Vatsal Shah — Founder & CEO, IAAP WAS-Certified Accessibility Professional

Automated accessibility scanners — axe, WAVE, Lighthouse, Accessibility Insights, and the checkers built into overlay widgets — are useful. They are also incomplete. A green score is not WCAG conformance, and it is not a defence under the ADA, AODA, the European Accessibility Act, or any other law that points at WCAG.

Industry testing has been consistent for years: automated tools typically catch about 25–40% of WCAG failures. The rest are issues of meaning, keyboard behaviour, and how assistive technologies announce the page — things a static DOM check cannot judge. That is why a scanner-only audit leaves you exposed, and why every Peradeo engagement pairs automation with manual testing.

This article walks through several failures we still find on live sites after the scanner has passed — starting with missing focus outlines and duplicate alt/title announcements, then mouse-only widgets, generic “Read more” links, and silent form errors. It is a sample, not a catalogue: WCAG has dozens more success criteria that automation cannot judge. If you need the rest found on your site, contact us for a manual audit.

Scanners check presence. People experience meaning.

A scanner is good at asking “does this attribute exist?” It is bad at asking “does this actually work for a keyboard or screen-reader user?”

It can usually tell you:

• an <img> has no alt;
• a form control has no accessible name;
• a contrast ratio on a flat background colour is too low;
• a page is missing an h1.

It generally cannot tell you:

• whether the alt text is useful, or whether it is announced twice;
• whether keyboard focus is actually visible when you Tab;
• whether a custom dropdown, date picker, or carousel can be used without a mouse;
• whether an error message is perceived when it appears;
• whether a visible label matches the name a voice-control user will speak.

If your compliance programme stops at the scan, you have documented the easy third of the problem and shipped the rest.

Missing focus outline (WCAG 2.4.7 Focus Visible)

What the scanner does today: it usually does not fail the page when a visible keyboard focus indicator is missing. Teams run WAVE or Lighthouse, see no “focus” error, and assume keyboard users are fine.

What WCAG requires: WCAG 2.4.7 Focus Visible (Level AA) requires that any keyboard-operable user interface has a mode of operation where the keyboard focus indicator is visible. WCAG 2.2 also adds 2.4.13 Focus Appearance, which sets a minimum size and contrast for that indicator. Removing the ring without an equivalent replacement is a failure — even if mouse users never notice.

Why scanners miss it:

• CSS resets, design-system defaults, and utilities such as outline: none, outline: 0, or Tailwind’s outline-none strip the browser’s default ring. The replacement — a :focus-visible outline, ring, or high-contrast box-shadow — is never added, or it is added only for :hover.
• Scanners inspect a mostly unfocused document. Until someone actually Tabs, the computed style may still look like “an outline exists,” so the tool moves on.
• Custom widgets (tabs, menus, cards, sliders) move a visual “selected” class while the real :focus / :focus-visible style is empty. A mouse user sees a highlight; a keyboard user sees nothing.
• outline-color: transparent, zero-width outlines, and focus styles that match the background colour all defeat naive CSS checks.

What it looks like in code:

button:focus,
a:focus,
input:focus {
  outline: none;
}

Or a component with class="outline-none" and no focus-visible:ring (or equivalent) to replace it. The scan stays green. Keyboard users disappear into the page.

What a keyboard user experiences: Tab through the header, the cards, the form, the footer — and the caret or ring vanishes. They cannot tell which control will activate. This is one of the most common blockers we find on marketing sites and e-commerce themes, and one of the easiest to ship by accident when a design system “cleans up” focus rings for mouse users.

How to catch it (manual): unplug the mouse. Starting at the address bar, Tab through every interactive control on the page, including Skip to content, menus, carousels, dialogs, and the footer. If you ever lose the indicator, you have a 2.4.7 failure. Automated scans will not reliably save you.

How to fix it: never remove outline without an equivalent :focus-visible style that meets contrast (at least 3:1 against the adjacent background). Mouse users can keep a quieter hover; keyboard users still get a visible ring.

Duplicate announcements and bad alt text (WCAG 1.1.1 & 2.4.4)

What the scanner does today: it fails missing alt. If alt is present — even if it is a filename, the word “thumbnail”, or a near-duplicate of title — the scan typically passes.

What WCAG requires:

• 1.1.1 Non-text Content (Level A): the text alternative must serve the equivalent purpose of the image, not merely exist as an attribute.
• 2.4.4 Link Purpose (In Context) (Level A): the purpose of a link must be determined from the link text (or the accessible name of the link). For a linked image, that name is usually the alt.

We see this pattern constantly on CMS-built pages (WordPress, WPBakery, and similar builders). The image has alt text, so the scanner is satisfied. Assistive technology is not:

<a href="/how-to-install-garmin-quickfit-straps/">
  <img
    src="/thumbnails/how-to-install-garmin-quickfit-straps.jpg"
    width="400"
    height="400"
    alt="How to Install Garmin QuickFit Straps Thumbnail"
    title="How To Install Garmin QuickFit Straps Thumbnail"
  >
</a>

Two separate problems remain after the scan has passed:

1. Duplicate announcements. alt and title say the same thing — minor capitalisation differences do not count as different text. JAWS, NVDA (depending on settings), and VoiceOver often expose title as additional description. The screen reader announces the phrase twice: once as the image/link name, once as the title tooltip. That is noise, not an equivalent alternative. It is a violation of Duplicate Announcements & Bad Alt Text (WCAG 1.1.1 and WCAG 2.4.4).
2. The alt is not equivalent. “Thumbnail” describes a media-library field, not the destination. A linked image’s alt should name the article or action — for example, “How to install Garmin QuickFit straps” — not leftover CMS metadata. Filename-style alts, “image of…”, “graphic”, and “photo of…” fail the same way: the attribute exists, the purpose does not.

What a screen reader often announces: “Link, image, How to Install Garmin QuickFit Straps Thumbnail, How To Install Garmin QuickFit Straps Thumbnail.”

The person using AT hears the same sentence twice, plus a word that does not help them decide whether to follow the link. A scanner that only checks “is alt non-empty?” will never flag this.

How to fix it:

• Remove title when it repeats alt. The title attribute is not a substitute for a good accessible name, and native tooltips are unreliable on touch and keyboard.
• Write alt for the purpose of the image in this context. Linked images describe the destination. Decorative images get alt="" so they are skipped.
• Do not stuff “image of”, “graphic”, “photo”, or “thumbnail” into alt.
• If adjacent visible text already names the link, give the image empty alt so the name is not announced twice — the opposite duplicate of the example above.

Overlays do not close this gap. They often inject styling attributes onto the same markup without changing what AT announces. If the DOM still has matching alt and title, the double reading remains.

Mouse-only custom dropdowns (WCAG 2.1.1 & 4.1.2)

What the scanner does today: it sees a <div> or <span> with a click handler and usually passes. There is no native <select> to inspect, no missing alt, and often no missing name — so axe and WAVE have nothing obvious to flag.

What WCAG requires:

• 2.1.1 Keyboard (Level A): all functionality must be available from the keyboard.
• 4.1.2 Name, Role, Value (Level A): a custom control must expose a role (combobox, listbox, menu), a name, and its expanded/selected state to assistive technology.

Design-system “pretty selects,” mega-menus, and date pickers are the usual source. The visual widget works with a mouse. Tab skips it, or focus lands on it and Enter/Space/arrows do nothing:

<div class="dropdown" onclick="toggleMenu()">
  Sort by: Popular
</div>
<div class="dropdown-list" hidden>
  <div onclick="select('newest')">Newest</div>
  <div onclick="select('price')">Price: low to high</div>
</div>

A keyboard user cannot change sort order, open the account menu, or pick a delivery date. A screen-reader user may not even know a control is there. The scan still reports a clean page.

How to catch it (manual): Tab to every control that looks clickable. Open it with Enter or Space, move with arrows, close with Escape, and confirm NVDA/JAWS/VoiceOver announces the name, role, and selected option.

How to fix it: prefer a native <select>, <button>, or <details> when you can. If you must custom-build, implement the ARIA combobox or menu pattern, make it fully operable from the keyboard, and test it with a screen reader — a scanner will not do that work for you.

Generic “Read more” and “Learn more” links (WCAG 2.4.4)

What the scanner does today: the link has visible text, so most tools pass. A few flag “click here”; far fewer flag a card grid of identical “Learn more” links when the unique title sits in a nearby heading the link does not include.

What WCAG requires: 2.4.4 Link Purpose (In Context) — the purpose of each link can be determined from the link text alone, or from the link text plus programmatically determined context. A screen-reader user who pulls up a list of links on the page should not hear “Read more, Read more, Read more.”

<h3>How to install Garmin QuickFit straps</h3>
<p>A two-minute guide for swapping bands without tools.</p>
<a href="/how-to-install-garmin-quickfit-straps/">Read more</a>

<h3>Sizing chart for NATO straps</h3>
<p>Measure once, order the right length.</p>
<a href="/nato-strap-sizing/">Read more</a>

What a screen-reader link list often announces: “Read more. Read more.” — with no way to tell the articles apart until you open each one.

How to catch it (manual): in NVDA or JAWS, open the elements list / links list. If two or more links have the same name and different destinations, you have a 2.4.4 problem even though the scan was green.

How to fix it: put the unique destination in the link text (“Read more: How to install Garmin QuickFit straps”), or wrap the heading in the same <a> so the accessible name becomes the heading. Do not rely on nearby paragraph text that is not programmatically tied to the link.

Silent or colour-only form errors (WCAG 1.4.1, 3.3.1 & 4.1.3)

What the scanner does today: if the input has a label (or an aria-label), the form often passes. Tools do not submit the form, wait for validation, or listen for a status message. A red border, a toast that vanishes, or an error that is not tied to the field will not show up.

What WCAG requires:

• 1.4.1 Use of Colour: colour cannot be the only way to show an error.
• 3.3.1 Error Identification: if an error is detected, the item in error is identified and the error is described in text.
• 4.1.3 Status Messages: when an error or success message appears without a change of context, assistive technology must be notified (typically via an aria-live region or by moving focus to the message).

<label for="email">Email</label>
<input id="email" type="email" class="invalid">
<!-- Red border only; no text, not wired to the field -->

<div class="toast">Please fix the highlighted fields.</div>
<!-- Disappears after 3 seconds; never announced -->

A sighted mouse user might notice the red outline. A keyboard user, a screen-reader user, and anyone who missed the toast cannot tell what went wrong or which field to fix. Checkout and contact forms fail this way constantly — and they are exactly the journeys ADA and AODA complaints cite.

How to catch it (manual): submit empty, submit an invalid email, and recover. Confirm each error is text, next to (or programmatically associated with) the field, still there when you need it, and announced by NVDA/VoiceOver when it appears.

How to fix it: describe the error in text, use aria-describedby or aria-errormessage on the invalid field, set aria-invalid="true", and announce new errors with a polite live region or by moving focus. Do not rely on colour or a disappearing banner.

Other failures scanners routinely pass

The five examples above are still only a sample. These show up on the same scans, with the same green score:

None of these require exotic tooling. They require someone to use the site the way a person with a disability uses it.

This list is not exhaustive — contact us to find the rest

A blog post cannot walk through every WCAG failure an automated scan will miss. Heading structure that is present but meaningless, skip-link targets that do not work, motion that cannot be paused, language of parts, session timeouts, inaccessible PDFs, and the way a specific WordPress plugin or Vue/React widget behaves in NVDA versus VoiceOver all sit outside what a scanner (or a single article) can certify.

If you need the issues on your site identified — not just the examples on this page — contact Peradeo for a free accessibility check. Our IAAP-certified specialists run the scan, then test with a keyboard and real assistive technologies (NVDA, JAWS, VoiceOver, TalkBack) so you get the failures automation never reports. You can also read how a WCAG audit and remediation engagement works.

A practical manual-testing pass

You do not need a lab to find most of what scanners miss. On every release, before you call the page compliant:

1. Keyboard only. Tab through the full header, main, forms, dialogs, and footer. Confirm a visible focus indicator on every stop, a sensible order, and no trap.
2. Screen reader on the key journeys. Browse, search, product/article, cart or form submit, and errors — with NVDA or JAWS on Windows, VoiceOver on Apple, TalkBack on Android. Listen for duplicate names, mystery links, and silent status messages.
3. Forms as a first-time user. Submit empty, submit invalid, and recover. Errors must be text, associated with the field, and still there when you need them.
4. Zoom and reflow. 200% in the browser, then 400% or a 320px viewport. Nothing essential should clip or require two-dimensional scrolling for a single column of text.
5. Diff the scan against what you found. If the scanner was green and you still found a 2.4.7 or 1.1.1 failure, that is the point of this article: keep the scanner, stop trusting it as the audit.

Treat this as a release gate, not a one-off project. New CMS blocks, hero images, custom widgets, and “quick” CSS resets reintroduce the same failures every month.

Stay compliant by testing like your users

Laws that reference WCAG — the ADA, Section 508, AODA, Manitoba’s AMA, the Accessible Canada Act, the EAA — expect conformance, not a Lighthouse score. If you only run an automated scan, you will miss missing focus outlines, duplicate announcements, mouse-only widgets, mystery links, silent errors, and the rest of the table above.

Use scanners to catch the mechanical issues fast. Use a keyboard and a screen reader to catch the issues that actually block people. That combination is what “manual testing” means in a WCAG audit — and it is the only way to stay compliant. To find the issues this article does not list, contact us.

How Peradeo can help

Peradeo is a web accessibility company based in Regina, Saskatchewan, Canada. Our IAAP-certified specialists audit websites and web applications against WCAG 2.0, 2.1, and 2.2 AA using real assistive technologies (NVDA, JAWS, VoiceOver), remediate the issues hands-on as developers, and prepare the compliance documentation — including VPAT® / Accessibility Conformance Reports and accessibility statements — that regulators and procurement teams ask for.

• Learn more about our web accessibility audit & remediation services
• Request a free accessibility check of your website

This article is provided for general information only and is not legal advice. Requirements change over time — consult a qualified lawyer for advice about your specific obligations.