How do we learn a spec nobody reads?

Nobody learns a language by reading its dictionary. We learn one by hearing words often enough that they become familiar, and only then looking them up when we need to be exact.

Our field has produced an excellent dictionary and almost no exposure. WCAG 2.2 is free, thorough, and carefully written. It is also something most designers open perhaps twice a year, the way we open a tax code, and the consequences of that fall on other people.

Why does a documentation gap exclude anyone?

Because accessibility knowledge is lookup knowledge, and lookup only works if we already know there is something to look up.

We cannot search for 1.4.11 if it has never occurred to us that non-text contrast is a thing with a number. We will not check 4.1.2 if "this has an accessible name" is not a sentence we have ever heard. The criterion sits in the document, correct and unread, while a control ships with no name on it.

The person who meets that control is not confused about the spec. They are a screen reader user who hears "button", with no indication of what it does, and leaves. The gap between the document and the interface closed on top of them.

So the failure is rarely refusal. We both believe UX professionals do not intentionally exclude people from their work. The failure is that the thought never arrived (wait, I think there is a rule about this) because nothing in the working day ever put the phrase in front of us.

That jolt of recognition is the precondition for everything else. Without it, the best documentation in the world is a closed book.

Why does training not close it?

Because training is an event, and recognition is a frequency.

Most of us have sat through an accessibility workshop. Some were excellent. The problem is what happens 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 that eleven seconds. It was in a room, in April.

I do not mean that as a criticism of training, which does something training is good at: establishing that the field exists, and that these are real people with real needs. But the thing that fires at the moment of a decision is vocabulary, and vocabulary comes from repetition in context, not from a session.

Our field has invested heavily in events and hardly at all in exposure.

Where does recognition actually come from?

From repetition, in the places we already look.

That is the bet I made with a11y-tips-statusline (opens in a new tab): all 87 WCAG 2.2 success criteria (Level A, AA and AAA) in the Claude Code statusline, rotating one every thirty seconds, with a /wcag command to search them. One line to install.

I want to be exact about how modest the claim is. Ambient exposure is not expertise. Reading a criterion while a build runs does not make anyone a practitioner, any more than passing a fire extinguisher makes us firefighters. What it is good at is the narrow job of making a phrase familiar enough to be recognized later, when it matters.

It is my most-starred repository. I read that as a fact about appetite rather than about outcomes, and I try to hold the distinction. This field is full of tools whose authors quietly upgraded the first into 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 have not measured it.

What would make me trust ambient tooling?

Two details in that tool generalize, 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. 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 tip is replaced by a short prompt to widen the window. It does not truncate.

Most statusline tools truncate, because truncating is the obvious thing to do. Truncating is almost always wrong, because a silently cut-off line reads as a complete one: half a sentence arrives with no signal that there was ever more. An accessibility tool that quietly drops information on a narrow viewport is failing exactly the people it exists for, in exactly the way it is meant to be teaching us not to.

That is the kind of default I keep finding: never examined, sitting inside a category whose conventions are still soft.

What can we put in front of ourselves this week?

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. A statusline, a repository README, the bottom of a design file, a rotating item in a team channel. Anywhere already in the eyeline.
• 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.
• Prefer recognition to training. A workshop once a year is an event. A phrase seen three hundred times is a vocabulary. Do both, but do not mistake the first for the second.
• Check how your own tools fail. Anything that truncates, hides, or silently drops information is teaching the opposite of what it says.
• 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 the point: it is cheap to change now, and it becomes an audit finding later.

The dictionary is written and free. What our field lacks is the ordinary, repeated exposure that makes anyone open it. Let's put the words where we already look.