( Product Design )
Accessibility mistakes product teams make
The failures that sink product accessibility aren't technical — they're process mistakes. The seven patterns we see most, and what working teams do instead.
Product accessibility rarely fails on technical difficulty — alt text and focus states aren’t hard. It fails on process: audits instead of habits, heroics instead of ownership, fixes at the page level instead of the component level. These are the seven mistakes we see most, roughly in the order teams make them.
1. Auditing once and calling it done
The classic. An audit lands, a remediation sprint follows, the report gets filed — and six months of shipping quietly rebuilds the backlog. Accessibility conformance describes a moment in time; your product changes every sprint.
Instead: put detection in the pipeline. Automated scanning on key flows, checks in CI, and the common failures caught the week they’re introduced instead of the year after.
2. Starting at QA instead of design
If the first accessibility conversation happens when a tester runs a screen reader over the release candidate, every finding is already expensive. Contrast, focus order, touch-target size and label placement were all decided months earlier in design files.
Instead: accessibility annotations in design review — contrast checked in the palette, focus order sketched for complex screens, error states designed rather than improvised by engineers under deadline.
3. Fixing pages instead of components
Teams remediate screen by screen while every screen assembles the same broken components. The unlabelled icon button gets fixed in eleven places and stays broken in the component library that generates the twelfth.
Instead: fix the design system first. One accessible button, modal, form field and dropdown fixes every current and future page that uses them. Component-level fixes are the highest-leverage accessibility work that exists.
4. Making one person “the accessibility person”
Appointing a champion feels like progress, but routing every question through one person creates a bottleneck, and their departure erases the capability. Worse, everyone else learns that accessibility is someone else’s job.
Instead: shared ownership with clear lanes — designers own contrast and states, engineers own semantics and keyboard support, QA owns the keyboard/zoom pass — plus a specialist (internal or external) for genuinely hard judgement calls.
5. Relying on an overlay
An overlay promises conformance via a script tag. It patches a subset of symptoms in the browser, after load, while the product’s actual markup stays broken — for users, for crawlers, and for anyone who checks. Overlay-equipped sites get sued regularly, and disabled users have publicly campaigned against them.
Instead: spend the overlay subscription on fixing components. The work is smaller than teams fear — most common failures are one-line fixes — and it’s the only version that’s real.
6. Testing only with a mouse, on a big screen
The developer experience — large monitor, mouse, perfect vision, no zoom — is the one configuration that never hits accessibility barriers. Keyboard traps, invisible focus, hover-only content and reflow breakage are all invisible from that chair.
Instead: make one keyboard-only pass part of testing every significant UI change: Tab through it, operate it, Escape out of it. Add a 200% zoom check. Ten minutes per feature catches the failures automation can’t judge.
7. Treating conformance claims as marketing
Declaring “WCAG compliant” without evidence backfires the moment a buyer, auditor or plaintiff checks. Procurement teams read a lot of conformance reports; unsupported claims read as either ignorance or bluffing, and both lose deals.
Instead: claim what you can evidence. Scan data, manual check records, and an honest ACR with real remarks (“Partially Supports — fix scheduled Q3”) build more trust than a wall of green ever has.
The pattern behind the mistakes
Every one of these reduces to the same root: treating accessibility as an event rather than a property of how the team works. The teams that stay conformant don’t have larger budgets — they have accessibility folded into design review, the component library, the test plan and the pipeline, where it costs least and sticks longest. The business case follows from there.
Frequently asked questions
What is the biggest accessibility mistake product teams make?
Treating accessibility as a one-off audit instead of a habit. A single audit describes one moment; the next quarter of shipping erases it. Teams that stay accessible put checks in the workflow — design review, component library, CI and scanning — so regressions surface when they're introduced.
Should accessibility be handled by a dedicated specialist?
A specialist helps, but routing everything through one person creates a bottleneck and a single point of failure. The durable model is shared ownership — designers check contrast and focus states, engineers own semantics, QA includes keyboard passes — with a specialist for the hard judgement calls.
When in the product process should accessibility start?
At design. Contrast, focus order, target sizes, label placement and error handling are design decisions that cost nothing to get right in Figma and multiples more to retrofit in code. If accessibility first appears at QA, most fixes arrive too late to be cheap.
Do accessibility overlays fix a product's accessibility?
No. Overlays patch symptoms in the browser at runtime and miss most real failures — several vendors have faced legal action from the very users overlays claim to serve. Fixing your components fixes the product; an overlay defers the work and adds a script.