Beyond Accessibility Compliance: Designing Interfaces People Actually Want to Use

We've written before about building accessibility into design systems from the start rather than retrofitting it. That gets a product to compliant. Compliant and genuinely pleasant to use are related but not the same achievement, and the gap between them is where a lot of technically-accessible products still lose users.

Where Compliance and Usability Diverge

WCAG defines a floor — minimum contrast ratios, keyboard operability, screen-reader labels. Meeting that floor is necessary and non-negotiable, but a product can hit every WCAG checkpoint and still make a user work harder than they should to accomplish a task, still bury the action they need behind unnecessary steps, still use interaction patterns that are technically operable but not actually intuitive. Compliance testing catches "can a screen reader user complete this task at all." It doesn't catch "does this take three times longer than it should."

What We Actually Design For, Past the Checklist

Cognitive Load, Not Just Technical Operability

A form that's fully keyboard-navigable and properly labeled can still overwhelm a user with too many decisions presented at once. We audit interfaces for how much a user has to hold in their head at any given moment — grouping related decisions, deferring optional complexity, and defaulting to sensible choices — which is a usability concern WCAG doesn't directly measure but that affects every user, not only users of assistive technology.

Real Users Testing Real Tasks, Not Just Automated Scans

Automated accessibility scanners catch missing labels and contrast violations reliably. They don't catch a focus order that's technically valid and still confusing to actually tab through, or an interaction pattern that's operable but non-obvious. We test genuinely difficult workflows with real users — including users of screen readers and other assistive technology — completing real tasks, because that's the only way to catch the usability gap a scanner can't see.

Consistency Across the Product, Not Just Within One Component

A design system with perfectly accessible individual components can still produce an inconsistent product if different teams apply those components differently — one team's form flow groups fields one way, another team's groups them differently for no reason a user would understand. We treat interaction pattern consistency across the whole product as part of the usability bar, not just component-level correctness.

A Practical Example

A SaaS client's onboarding flow passed every automated accessibility check and had genuinely solid component-level compliance. User testing — including with screen-reader users — found that the flow presented eleven configuration decisions on a single screen before a new user could do anything with the product, and several screen-reader users abandoned the flow specifically because tabbing through eleven decisions in sequence, with no sense of progress or grouping, was exhausting even though every field was correctly labeled. We restructured the flow into three grouped stages with sensible defaults pre-selected, cutting the decisions a typical user needed to actively make from eleven to three, while keeping every field just as accessible technically as before. Completion rates improved across all users, not only users of assistive technology — the fix helped everyone, because the actual problem was cognitive load, and accessibility compliance had correctly never claimed to solve that.

The Actual Lesson

WCAG compliance is the floor every product needs to clear, and it's not optional. It's also not the ceiling for what makes an interface genuinely good to use — that requires designing for cognitive load, testing with real users on real tasks, and holding interaction patterns consistent across the whole product, none of which an automated scan will tell you about.

If your product is technically compliant but you suspect users are still struggling with it, our design team can run real-user testing to find the gap between passing a scan and actually being usable.