5 Accessibility Mistakes We Find on Almost Every Audit

We've run WCAG 2.2 AA audits across accounting platforms, lead-capture tools, property listings, and marketing sites. Different industries, wildly different codebases, and yet the same handful of issues show up almost every time. None of them are exotic. All of them are fixable in an afternoon once you know to look for them.

1. Colour contrast that "looks fine" but fails the ratio

Light grey text on white backgrounds, pale brand colours used for body copy, placeholder text that's meant to look muted. All common, all frequently under the 4.5:1 contrast ratio WCAG requires for normal text. This one is sneaky because it passes the eyeball test for most sighted users on a good monitor in good lighting. It fails for anyone with low vision, anyone on a washed-out laptop screen outdoors, and anyone using a phone at low brightness. It's also the single easiest fix on this list, usually a one-line colour change once you know which elements fail.

2. Form fields with no programmatic label

A field that visually sits next to the word "Email" isn't necessarily labelled "Email" as far as a screen reader is concerned. If the <label> isn't explicitly linked to the input, or a placeholder is being used as a substitute for a real label, assistive tech announces the field as unlabelled. Placeholder-as-label is especially common because it looks correct in the browser and only breaks for the people who can't see it.

3. Focus states that are invisible or missing entirely

Plenty of sites strip the default browser focus outline for aesthetic reasons and never replace it with anything. The result: a keyboard user tabs through the page and has no idea where they are. This is one of the most common and most consequential failures we find, because it doesn't just affect one criterion, it affects every keyboard interaction on the site. If you've ever seen outline: none in a stylesheet with nothing after it, that's usually the culprit.

4. Images and icons with missing or meaningless alt text

Either there's no alt attribute at all, or it's something like alt="image1.jpg" or alt="icon". Technically present, functionally useless. The flip side also trips people up: purely decorative images (background flourishes, spacer graphics) that do get announced by a screen reader when they should have alt="" and be skipped entirely. Both directions create noise that makes the actual content harder to navigate.

5. Custom components that don't work with a keyboard at all

Dropdown menus built from <div>s instead of native elements, modals that trap focus incorrectly or don't trap it at all, custom date pickers, toggle switches, and accordions are frequently built to look right and behave correctly with a mouse, but silently drop keyboard and screen reader support because that requires deliberate ARIA roles and states, not just styling. This is the category where we most often see teams surprised. The component was tested visually and functionally by clicking, and keyboard or screen reader testing never happened.

The pattern behind all five

None of these are advanced accessibility problems. They're what happens when a site is tested by looking at it and clicking through it, but never tested by tabbing through it or listening to it. The fix isn't a redesign. It's catching these before launch, and having someone check for them who knows what to look for.

That's the gap an audit closes. Send us your URL and we'll send back a full WCAG 2.2 AA report with every finding mapped to a success criterion, a severity level, and a fix your developer can act on without booking a call.