Where do accessibility decisions actually get made?

Picking #8A8A8A for helper text on white takes about two seconds. It's 3.45:1, it fails WCAG 1.4.3, and an auditor will discover it eleven months later.

By then it's no longer a color. It's a design system change, a migration, four teams and a conversation about timelines.

Ask where accessibility happens in your organization and you'll probably be given a stage like that one. It might be a review, an audit, a ticket queue, or a phase near the end with a budget attached.

Ask where the decisions happen and you get an entirely different answer. They happen in a design file, months earlier, while somebody picks a gray.

A decision is cheap in the file and expensive at the audit

The gap between those two answers matters because everything in the design file is cheap and everything in the late stage is expensive. We've arranged our craft so that almost all the effort goes to the expensive one.

The designer who chose that gray wasn't careless. They were choosing a visual weight, which is a legitimate thing to be doing. Nothing anywhere in their tool signaled that the choice had a second dimension.

Nothing in the file said 3.45:1, and nothing said this one excludes people. I see the same thing every time I look. The designer's values didn't fail. The information was missing, at the exact moment when it would have been free.

And who's on the other side of that gray? People with low vision are. So are people with age-related contrast sensitivity loss, which is most of us eventually, and people reading on a phone in sunlight, which is most of us weekly.

I resist the instinct to file this under "a small group with specific needs". Contrast is the clearest example we have of a requirement that is specific in its origin and universal in its benefit.

It's the curb cut argument, in a color picker.

The failure also compounds without much notice. One gray becomes a token, the token becomes a component, and the component becomes forty screens.

By the time anyone measures it, the decision has been copied so many times that undoing it is a program and no longer a fix.

The information belongs where the decision is

To move it, we'd have to put the information where the decision is.

That's why I built the WCAG Plugin for Figma (opens in a new tab), which is free and open source. It puts WCAG guidance, annotation cards and accessibility utility tokens inside the file where design decisions actually get made.

It isn't a separate checker to remember to open, and it isn't a report. The guidance is in the file, at the moment of the choice.

There's a ceiling on that claim, and I'd rather say so. A plugin doesn't make anyone an accessibility practitioner, and I haven't measured whether teams using it ship better interfaces.

What it changes is when the information arrives, and arriving early is the only thing that has ever made this work cheap.

The annotation cards do a second job. They give a designer a way to communicate intent to engineering (this is a button not a link, this heading is level two, this control needs a name), in the artifact engineering already reads.

A great deal of accessibility is lost in that handoff. Nobody disagreed with anything. The intent was never written down anywhere durable.

Where we ask sets what it costs

Where we ask a question sets what it costs.

Opening a separate contrast checker means leaving the file, switching context, copying two values, reading a result and coming back. That's perhaps ninety seconds, which sounds like nothing and in practice works as a wall.

It'll happen for the brand palette, and it won't happen for the forty incidental grays chosen in passing. The same question asked inside the file costs nothing, so it gets asked about all forty.

The checker is equally accurate in both cases. The only variable is distance, and distance is a property of our tooling and not of anybody's diligence.

That applies well beyond color. We attend to any quality property we care about according to how close the answer sits to the moment of the decision. Put it one context-switch away and it becomes a thing conscientious people do sometimes.

Other decisions can move earlier too

The plugin is one instance of a general move, and most of the others cost very little.

Contrast ratios can go in the token names or the documentation. If a palette entry is only safe above 18px, say so where someone picking it will read it.

Design review can take four more questions. Ask about keyboard order, screen reader output, how it rearranges itself at 375 pixels, and whether this value exists in the system.

Intent can be annotated in the file and not in a document, since the file is what engineering reads. That covers heading levels, landmarks and names for icon-only controls.

The build can fail on contrast, after a report-only period. Measure first, publish the number, let it be uncomfortable, then tighten. A gate that arrives as an obstacle before it arrives as information gets resented and routed around.

And name the criterion, as in 1.4.3, 1.4.11 or 2.4.7. A number is a shared reference that a colleague can check and an agent can be pointed at.

Everything after the decision is repair. Repair is always worth doing, but it's never as good as having been right when it was free.

Our tools decide when the information arrives, and our tools are ours to change. The design file is where the decisions are. Let's put the numbers there.