Making accessibility everyone’s job

For a long time, accessibility on our team was a phase, and it came last. Just before a release, someone ran an audit. The audit found missing labels, focus that vanished, contrast that failed on the brand colour. We fixed them in a hurry, shipped, and a quarter later the next audit found the same things again. The fixes were real. The habit never changed.

This is how that changed, without anyone being put in charge of it.

Checked last, found again

Nobody on the team was against accessibility, and most people knew the basics. The problem was where the check sat. A check at the end of a process is a gate, and gates get negotiated: the deadline is tomorrow, the issue is “minor”, it goes on the backlog. The backlog is where accessibility issues go to be found again.

The repeat findings were almost always the same few:

• Form fields without a programmatic label, so a screen reader announced “edit text” and nothing else.
• Focus lost after a dialog closed, dropping keyboard users back at the top of the page.
• Colour as the only cue for an error, invisible to anyone who can’t tell red from green.
• Custom controls a keyboard couldn’t reach at all.

None of these is hard to fix. Every one of them is cheaper to prevent. In [N] audits, [N] of every 10 findings were repeats.

A workshop

The first step was not a guideline. It was an hour with a keyboard and a screen reader, on our own product. Everyone took a feature they had built and tried to use it without a mouse.

Watching a colleague press Tab [N] times to reach the main button of their own form does more than any document can. Nobody needed convincing afterwards; they needed to know what to do next.

A checklist

So the second step was a checklist, short enough to use: one page, each item a question you can answer in a minute.

• Can every action be reached and used with the keyboard alone?
• Is the focus always visible, and does it land somewhere sensible after a dialog closes?
• Does every field have a label a screen reader announces?
• Is any meaning carried by colour alone?
• Does the text still read at 200% zoom?

The list lives in the definition of done and in the pull-request template. If a check isn’t somewhere people already look, it doesn’t exist.

Reviews, earlier

The third step moved the checks forward. Designers now annotate focus order and the states of each control in the design file, and a front-end developer reviews the design before it is built, not after.

The cheapest place to fix an accessibility issue is the design file. The most expensive is the audit report.

The audit still happens. It just finds less, and what it finds is new.

No mandate

I had no title that let me require any of this, so none of it was required. What worked instead:

• Make the right thing the easy thing: components with accessible defaults, so doing nothing is already correct.
• Share findings as stories about people, not as violations of a standard.
• Credit the people who fix things, in public.
• Start small, with one team that wanted it, and let the results travel.

What changed

Repeat findings fell from [N] to [N] per audit, and [N] teams now use the checklist. More importantly, accessibility stopped being a separate job. It became part of everyone’s, which is the only place it was ever going to work.