Some of your users cannot complete the task. Some cannot start it. An expert review finds what breaks, testing with real users and assistive technology proves it, and the fixes go into your components so the same problem does not come back next quarter.
“Is this usable? Is it accessible? And how would we know?”
A conformance checklist tells you which rules you break. It does not tell you who is stuck and where. Both matter: the audit gives you the list, the testing gives you the reason, and only the second one changes what a team builds next.
Three phases, each ending with something the next one needs: a ranked list, then proof, then a fix that holds. The usability work behind it runs through my cases — the ING document inbox began with a heuristic evaluation and ended with measurably fewer support calls.
Two passes over the same product. A heuristic evaluation finds where the interface fights the user, and a conformance audit checks it against WCAG 2.1 AA — contrast, focus order, keyboard operation, labelling, error handling. Every finding gets a severity, not just a tick.
A checklist can pass while people still fail. The critical paths get tested with real users — including keyboard-only, screen reader and magnification. What you learn is not that a rule was broken, but that someone could not finish.
Fixing a screen fixes a screen. The findings go into components, states and acceptance criteria instead, so the next feature inherits them. Accessibility that lives in a report decays; accessibility that lives in a component library does not.
Two passes over the same product. A heuristic evaluation finds where the interface fights the user, and a conformance audit checks it against WCAG 2.1 AA — contrast, focus order, keyboard operation, labelling, error handling. Every finding gets a severity, not just a tick.
A checklist can pass while people still fail. The critical paths get tested with real users — including keyboard-only, screen reader and magnification. What you learn is not that a rule was broken, but that someone could not finish.
Fixing a screen fixes a screen. The findings go into components, states and acceptance criteria instead, so the next feature inherits them. Accessibility that lives in a report decays; accessibility that lives in a component library does not.
Findings first, then proof, then fixes that outlive the project. You end up with a product more people can use and a team that no longer discovers accessibility during the audit.
Audit, sprint or ongoing support
This is for products that people already use — and where some of them quietly cannot.
Conformance is a legal obligation, not a quality goal, and an audit report alone does not make the product usable.
You get conformance evidence and the usability findings behind it.
A checklist can pass while people still fail. Rules describe the floor, not whether anyone reaches the goal.
You get recorded evidence of where people actually get stuck.
Since June 2025 many private digital products in the EU fall under it, and nobody on the team has done this before.
You get a ranked plan instead of a panic.
An audit checks the product against written criteria — WCAG 2.1 AA has 50 of them. A usability test checks whether a person can finish a task. A product can pass every criterion and still be unusable, and it can be pleasant for most people while being impossible with a screen reader. The two methods answer different questions, which is why both are in here.
It applies from 28 June 2025 to a defined set of products and services in the EU — among them e-commerce, banking services, e-books, transport and telecommunications — with exemptions for microenterprises. German public bodies were already covered by BITV. Whether your specific product falls under it is a legal question, and I will tell you when the honest answer is to ask a lawyer rather than a designer.
Where the budget allows, yes, and it is always the better evidence. Where it does not, I test the critical paths myself with keyboard only, with a screen reader and at 200 percent magnification. That finds most blocking problems, and I say plainly which findings come from simulation rather than from a real user.
You probably do not need another audit. You need the second half: why the findings persist, which of them actually block someone, and how to fix them so they stay fixed. Most reports end at the list. A list nobody can act on is the usual reason the same findings appear again a year later.
An audit of a defined scope is one to two weeks. Usability testing adds two to three, mostly spent recruiting the right people. Embedding the fixes into components depends on what exists — it is fastest when there is already a design system to put them in.
A free 30-minute call. No pitch, no pressure — an honest look at your product and whether I can help.