From "Compliant" to Genuinely Usable: A Maturity Model

Teams don’t go from inaccessible to accessible in one step. They climb through stages, and the stages are predictable enough that you can usually tell within five minutes of looking at a site which one its makers have reached. What’s interesting is that the hardest transition isn’t the first one. It’s the last one, the move from technically compliant to genuinely usable, and it’s hard because it requires a change in what you’re measuring rather than more effort at the same measurement.

The first stage is innocence. Nobody on the team has thought about accessibility at all. Images have no alternative text, forms have no labels, the color palette was chosen entirely for mood. This stage isn’t malicious; it’s the default output of building fast with people who all happen to see well and use mice. Most young companies live here, and the honest thing to say about it is that leaving costs surprisingly little, because the defects are so basic that fixing them is mostly typing.

The second stage begins with a jolt: a customer complaint, a procurement questionnaire from an enterprise deal, a legal letter, or just a founder reading something unsettling. The team runs an automated checker for the first time, sees a wall of errors, and starts fixing them. This stage is genuinely productive. Automated checks catch real problems, missing alt attributes, insufficient contrast, inputs without labels, and clearing them helps real users. The danger of this stage is only that it feels like the destination. The checker goes green, someone writes an accessibility statement, and the topic is declared handled.

The third stage is compliance proper. The team maps its work to WCAG, the Web Content Accessibility Guidelines, at some conformance level, and can say so with a straight face. This is a real achievement and I don’t want to sneer at it; a WCAG-conformant site is far better than the average site. But here is the uncomfortable fact about this stage: automated tools can only verify a minority of what the guidelines actually require, because the guidelines are full of judgments no scanner can make. A tool can confirm an image has alt text; it cannot confirm the alt text says anything useful. It can confirm a page has headings; it cannot confirm they describe the sections under them. It can confirm a button has a name; it cannot confirm the name makes sense to someone hearing it out of visual context. A site can pass every automated test and still be miserable to use with a screen reader, the way a sentence can be grammatical and still be nonsense.

Which is what defines the fourth stage: someone actually tries to do the thing. Not audit the pages, do the task. Sign up, search, buy, cancel, using only a keyboard, then using a screen reader, ideally by watching a person who uses one every day. This is where teams discover the gap between compliant and usable. The checkout technically works with a keyboard, but takes ninety Tab presses because there’s no way to skip the navigation. Every field has a label, but the error summary appears at the top of the page where a screen reader user, parked at the submit button, will never hear it. The modal traps focus correctly but announces nothing when it opens, so the user doesn’t know it’s there. None of these are checker failures. All of them are task failures, and the task is the only thing the customer came for.

The final stage, which few reach and none stay at without effort, is habit. Accessibility stops being a project with a start and end and becomes a property the team maintains the way it maintains uptime: designers check contrast when they pick colors rather than after, engineers reach for native elements first, keyboard testing is part of reviewing a feature, regressions get caught in weeks rather than years. The distinguishing mark of this stage is boring: nothing dramatic happens, because the drama was moved upstream into defaults.

The model matters because each stage needs a different push, and applying the wrong one wastes effort. A stage-one team doesn’t need a screen reader lab; it needs a scanner and an afternoon. A stage-three team doesn’t need a stricter scanner; it needs to watch one real user fail. That’s roughly how I think about GazeSite’s role: automation is superb at the early climb, at finding the mechanical defects fast and cheap and repeatedly, and honest automation should say plainly that the summit is beyond it. The scanner gets you to the door of usability. Walking through it means picking your most important flow and completing it the hard way.

If you want to locate yourself in the model, one question does it: has anyone at the company ever completed a purchase on your site with the screen off? If the answer is no, you don’t yet know which stage you’re in. You only know which one you hope you’re in, and hope, in my experience, grades generously.