How do we learn a spec nobody reads?

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

But it's a dictionary, 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 Non-text Contrast if it has never occurred to us that non-text contrast is a thing with a number.

We won't check 4.1.2 Name, Role, Value if "this has an accessible name" is a sentence we've never heard.

So the criterion sits in the document, correct and unread, and 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 hint of what it does, and they leave.

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.

But think about a Tuesday four months later. Three things are due, and 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 showing 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, while 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 86 WCAG 2.2 success criteria, Level A, AA and AAA, in the Claude Code statusline, and a new one appears 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 walking past a fire extinguisher makes us firefighters.

What it does is make a phrase familiar enough that we recognize it later, when it matters. That's the whole job.

It's my most-starred repository, and I read that as a fact about appetite, 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. 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 first: the tips 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 space neither controls.

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

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

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

That's the kind of default I keep finding: one nobody examined, in a category whose conventions are still soft.

The vocabulary belongs where the work is

The tool matters less than the move: 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 Contrast (Minimum), 2.4.7 Focus Visible, 4.1.2 Name, Role, Value. 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. Later, it becomes an audit finding.

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