How do we learn a spec nobody reads?

Most designers open WCAG 2.2 perhaps twice a year, the way we open a tax code. That's no complaint about the document, which is free, thorough and carefully written.

It's a dictionary, though, and nobody learns a language by reading its dictionary. We learn one by hearing words often enough that they become familiar, and we only look them up later, when we need to be exact.

Our field has written an excellent dictionary and offers almost no exposure, and the consequences of that fall on other people.

You cannot look up what you have never heard of

Accessibility knowledge is lookup knowledge, and lookup only works if we already know there's something to look up.

We can't search for 1.4.11 if it has never occurred to us that non-text contrast is a thing with a number. We won't check 4.1.2 if "this has an accessible name" is a sentence we have never heard.

So the criterion sits in the document, correct and unread, while a control ships with no name on it.

The person who meets that control isn't confused about the spec. They're a screen reader user who hears "button", with no indication of what it does, and leaves.

So I don't think the failure is usually refusal. We both believe UX professionals do not intentionally exclude people from their work.

What goes wrong is that the thought (wait, I think there is a rule about this) never arrives, because nothing in the working day ever put the phrase in front of us.

Training is supposed to take care of that. Most of us have sat through an accessibility workshop, and some were excellent. The trouble comes on the Tuesday four months later, with three things due, when a decision about a tooltip goes past in eleven seconds.

Nothing from the workshop is in those eleven seconds. It stayed in a room in April.

Training is good at establishing that the field exists and that these are real people with real needs.

But what fires at the moment of a decision is vocabulary, and vocabulary comes from repetition in context. A workshop once a year is an event, and a phrase seen three hundred times becomes vocabulary.

Recognition comes from repetition

It comes from seeing the same thing over and over, in the places we already look.

That's the bet I made with a11y-tips-statusline (opens in a new tab). It puts all 87 WCAG 2.2 success criteria (Level A, AA and AAA) in the Claude Code statusline, rotating one every thirty seconds.

There's a /wcag command to search them, and it takes one line to install.

I want to be exact about how modest the claim is. Reading a criterion while a build runs doesn't make anyone a practitioner, any more than passing a fire extinguisher makes us firefighters.

It makes a phrase familiar enough that we recognize it later, when it matters, and that's the whole job.

It's my most-starred repository, and I read that as a fact about appetite and not about outcomes. (This field is full of tools whose authors let the first stand in for the second.)

Stars are measurable. Whether anyone shipped a more accessible interface because a criterion went past at the right moment is not, and I haven't measured it. So I don't know.

Two details in the tool do apply more widely, and both are about how a thing fails.

The tips word-wrap to the width of the statusline, so they stay clear of the messages the editor writes in the same space. That sounds unremarkable until you watch two systems write over each other in a region neither controls.

The second matters more. When the terminal is narrower than 120 columns, the tool doesn't truncate the tip. It replaces it with a short prompt to widen the window.

Most statusline tools truncate, because truncating is the obvious thing to do. I think it's almost always wrong. A line that's cut off silently reads as a complete one, and half a sentence arrives with no signal that there was ever more.

An accessibility tool that drops information on a narrow viewport is failing the people it exists for. It's also doing the very thing it's meant to be teaching us not to do.

That's the kind of default I keep finding. Nobody examined it, and it sits inside a category whose conventions are still soft.

The vocabulary belongs where the work is

The specific tool matters less than the move, which is to stop treating accessibility knowledge as something we go and fetch.

• Put the vocabulary where the work already is. That could be a statusline, a repository README, the bottom of a design file or a rotating item in a team channel.
• Use the numbers. 1.4.3, 2.4.7, 4.1.2. A shared identifier is something a colleague can look up and an agent can be pointed at. "It's not accessible" is an opinion someone must take on trust.
• Make one criterion unavoidable this quarter. Pick the one your team fails most and put it somewhere nobody can miss it.

None of that is expensive, which is why I'm suggesting it. It's cheap to change now, and it becomes an audit finding later.

The dictionary is already written, and it's free.