How we test, and what we found

Who is asking

Usable Access is an accessibility compliance practice. We work with mid-sized businesses that sell to consumers in the EU. If we have written to you, it is because we went through one of your journeys and found something we thought you would want to know.

We come at it from research rather than engineering, which is why we test whole journeys rather than pages, and why the question we ask is whether someone can finish rather than whether the code passes.

We are not a scanning tool, and we are not an agency looking for build work — anything that needs fixing goes back to whoever builds your site. What we do is find what stops people, tell you plainly, and help you show what you did about it.

Will a company we test be named anywhere?

No. We are writing the findings up as aggregate research — sector, journey type, where the barrier occurred, what kind of control caused it. No company is named, and no individual finding is attributed to anyone. Anything we send a company is theirs alone, and we would not publish it against their name.

If we have written to you and you would rather we deleted the finding and your details entirely, say so and we will, and confirm when it is done.

What we actually do

We open the journey a real customer would use and try to complete it, using a keyboard alone and a screen reader. We record where it stops, what the control is, and what a customer would experience at that point. Every barrier we report is confirmed by at least two independent methods before we mention it to anyone.

That is it. It is a manual walkthrough of a public page, done the way an actual customer would do it. It takes about an hour per journey.

What we never do

• We never submit anything. No applications, no bookings, no quotes requested. We stop the moment the barrier is confirmed, which is well before the point where a record would be created in your systems.
• We never enter real personal data — no real names, no real contact details, nobody’s actual identity.
• We only test public pages. Never an account area, never anything behind a login.
• We do not scan, script or crawl at volume. A person goes through it, once.
• We never name a company publicly as an example of a failure.

What we have found so far

Thirteen of the nineteen had a confirmed barrier. Only two of those stopped the customer at the very start. Eleven stopped them in the middle — at the point where the customer specifies what they want. Dates, occupancy, product, country, title, occupation.

That is the commercially worst place for it. A customer blocked there has already chosen you, arrived, and started. They then hit a control they cannot operate, and leave. In your analytics it looks like an ordinary mid-journey drop-off.

The symptom was consistent: the control did not say what it was. The cause split roughly evenly. In about half the cases a standard HTML control — a dropdown, a radio button, an input, a button — had been replaced by a custom widget, and the accessibility the standard element provides for free had not been rebuilt. In the other half the correct element was used and simply never labelled.

That second half is the more uncomfortable one, because nothing clever went wrong. The right element was there. The label was never written.

Two journeys passed cleanly, and they prove the point from opposite directions. One kept the native controls. The other used a custom widget with the accessibility deliberately written back in. So this is not an argument against custom interfaces. It is that whether you replace a native control or keep it, the work of making it say what it is has to be done deliberately, and often it simply is not.

What went wrong in our method

We publish this because a method you cannot inspect is not really a method. Every study makes mistakes; the ones worth trusting are the ones that catch them and say so.

Four times, automated accessibility tooling told us a control was correctly labelled when it was not. In three cases the tool had inferred a name from text sitting next to the control rather than attached to it. In one case the semantics it reported were being injected by an accessibility overlay, not provided by the page. Each would have produced a false clean result.

We now confirm every negative finding by computing the accessible name directly, or by live behaviour, rather than trusting a tool’s summary. We also started with a different hypothesis — that most barriers would be at the very first step — and the data did not support it. We reported what we found instead.

What this is, and what it is not

Everything above is screening. It finds what the code exposes to assistive technology, and it does that well — but it is a walkthrough by someone who knows what to look for, not a study of what happens to a person.

It cannot tell you what it is actually like to hit the barrier. How long someone tries. What they attempt. Whether they work around it, ring you instead, or quietly go somewhere else. That takes sessions with disabled people using the product, which is scoped and priced separately as part of a full evaluation.

Our first research report will include that layer, and we will say plainly what it changed about the findings.

What a single finding does and does not tell you

It is not an audit. It is one confirmed barrier on one journey, found in about an hour. It does not tell you whether the rest of your product conforms, and we would not claim it does. A representative sample never permits a whole-product conformance claim, which is a point the W3C’s own evaluation methodology makes repeatedly.

It is a real finding about a real journey, and it is usually the start of a longer answer rather than the whole of one.