Where do accessibility decisions actually get made?
The color that failed our audit was chosen eleven months earlier, in about two seconds.
Ask where accessibility happens in your organization and you will probably be given a stage: a review, an audit, a ticket queue, a phase near the end with a budget attached.
Ask where the decisions happen and the answer is entirely different. They happen in a design file, months earlier, in the two seconds it takes to pick a gray.
Why does the gap between those two answers matter?
Because everything in the second location is cheap and everything in the first is expensive, and we have arranged our craft so that almost all the effort goes to the expensive one.
Picking #8A8A8A for helper text on white is a decision. It is 3.1:1, it fails
WCAG 1.4.3, and it will be discovered eleven months later by an auditor, at
which point it is not a color any more. It is a design system change, a
migration, four teams, and a conversation about timelines.
The designer who chose it was not careless. They were choosing a visual weight, which is a legitimate thing to be doing, with no signal anywhere in their tool that the choice had a second dimension. Nothing in the file said 3.1:1. Nothing said this one excludes people.
That is the shape it takes every time I look. Not a values failure, an information failure, at the exact moment when the information would have been free.
Who is on the other side of that gray?
People with low vision. People with age-related contrast sensitivity loss, which is most of us eventually. 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: the curb cut argument, in a color picker.
And the failure compounds quietly. One gray becomes a token. The token becomes a component. 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 rather than a fix.
What would it take to move the decision earlier?
Put the information where the decision is.
That is why I built the WCAG Plugin for Figma (opens in a new tab), free and open source, putting WCAG guidance, annotation cards and accessibility utility tokens inside the file where design decisions actually get made. Not a separate checker to remember to open. Not a report. In the file, at the moment.
I want to be plain about the ceiling on that claim: a plugin does not make anyone an accessibility practitioner, and I have not 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.
Annotation cards do a second job I want to name. 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, not because anyone disagreed, but because the intent was never written down anywhere durable.
Why does the tool decide this?
Because the cost of a question is set by where it is asked.
Opening a separate contrast checker means leaving the file, switching context, copying two values, reading a result, and coming back. That is perhaps ninety seconds, which sounds like nothing and is in practice a wall. It will happen for the brand palette and it will not 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 accuracy of the checker is identical in both cases. The only variable is distance, and distance is a property of our tooling rather than of anybody's diligence.
I would generalize that, because it applies well beyond color. Any quality property we care about will be attended to 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.
What can we move earlier?
The plugin is one instance of a general move. Here are others that cost very little:
- Put contrast ratios 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.
- Add the four questions to design review. Keyboard order, screen reader output, how it rearranges itself at 375 pixels, does this value exist in the system.
- Annotate intent in the file, not in a document. Heading levels, landmarks, names for icon-only controls. Engineering reads the file.
- Fail the build 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.
- Name the criterion. 1.4.3, 1.4.11, 2.4.7. A number is a shared reference a colleague can check and an agent can be pointed at.
The position, stated plainly
Accessibility is applied early or it is not really applied at all. Everything after the decision is repair, always worth doing, 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.