Automated scanners catch the easy stuff. Here are the barriers that actually get organizations complaints — and why they hide from a scan.
Run any site through an automated scanner and you'll get a tidy report with a score. Feel good about it — then have someone actually navigate the site with a keyboard, or a screen reader, and watch how fast that score stops meaning anything.
Here's what shows up over and over in manual testing, roughly in order of how often it costs someone a complaint.
1. Keyboard traps
A modal, a date picker, or a custom dropdown opens — and once you tab into it, there's no way to tab back out. The focus is stuck. For a keyboard-only or switch-device user, this doesn't mean "annoying." It means the site is unusable past that point.
The fix: every interactive component needs a defined focus order in and a defined way out — Escape closes it, Tab cycles inside it, and focus returns to the trigger element on close.
2. Focus that's invisible
The keyboard works, technically — you can tab through the page. But there's no visible indicator of where you are. Sighted keyboard users (this is a bigger group than people assume — think RSI, tremor, motor impairments) are navigating blind.
The fix: a visible :focus-visible outline, on every interactive element, with enough contrast against the background to actually see it. Removing the default outline without replacing it is one of the single most common failures we see — usually introduced by someone chasing a "cleaner" look.
3. Colour contrast that looks fine to the designer
Light grey text on white. White text on a bright brand colour. It looks elegant in Figma at arm's length on a calibrated monitor. It fails WCAG's 4.5:1 (normal text) or 3:1 (large text/UI) minimum for a meaningful share of visitors — and it's one of the few failures a scanner can catch reliably, which is exactly why it still ships so often. Nobody runs the scanner until launch week.
The fix: check contrast at design time, not audit time. Every colour pairing that will hold text needs to be verified against its actual background — not assumed from the brand guide.
4. Form fields with no real label
A field that looks labelled — placeholder text, or a label positioned nearby but not programmatically connected — reads to a screen reader as "edit text, blank." No name, no purpose. Multiply that by a checkout form and you've made commerce impossible for a chunk of your customers.
The fix: every input needs a <label for> (or aria-label) tied to it in markup, not just visually adjacent to it.
5. Custom components with no semantics
A <div> styled to look like a button, with a click handler and nothing else, is invisible to a screen reader. It's not a button — it's an unlabelled shape. This is endemic in component libraries built for visual polish first.
The fix: use a real <button>, or add the ARIA role, name, and keyboard behaviour that make a custom component behave like the thing it's pretending to be.
6. Motion that won't stop
Autoplaying carousels, parallax, animated backgrounds — for a visitor with vestibular disorders, this isn't decoration, it's a physical trigger. prefers-reduced-motion exists precisely for this and is trivial to respect; it's just rarely wired up.
The fix: every animation gets a reduced-motion fallback. Not "animations are slightly less fun" — genuinely off.
The pattern
None of these are exotic. None require deep technical sophistication to fix. What they have in common is that an automated scan doesn't reliably catch most of them — they require a person tabbing through the interface and a person using a screen reader. That's the whole case for manual testing over a scan-and-report.
Curious what a real audit would find on your site? See Accessibility Audits & AODA Compliance for how we run one.
Next article
What "managed hosting" should actually include — a checklist for comparing providers