The WCAG design guidelines checklist: contrast, states, and structure

Most of what the WCAG guidelines ask for is a design decision, not an engineering one. The contrast a text color sits at, the size of a tap target, the order a screen reader meets the headings in, the words an error message uses when something goes wrong: none of that gets fixed by a developer after the fact. It gets decided, or left undecided, in the design file. Treated as a legal document to hand to QA, WCAG reads like a wall of clauses. Treated as a map of the decisions a design already has to make, it is short, specific, and answerable before the first screen ships.

That is the version of the checklist below. It is organized the way a design actually gets built, foundations first, then the states every interactive element must answer for, then the content and the markup that carries it, rather than the way the standard numbers its own clauses.

Foundations: the perceivable checks

The foundation layer is where most of what WCAG calls perceivable gets settled, because perceivable is mostly a question of color and type, and color and type are foundation decisions by definition.

Contrast is the one every team has at least heard of: body text needs to clear roughly 4.5:1 against its background, large text can go as low as 3:1, and the ratio has to be checked for the actual pair in use, not assumed from a palette that looks dark enough. The mistake is checking this per screen. The fix is checking it once, when the color roles are named, the way I argued for in what belongs in a design system before the first component. On SeniorConnect, a platform built for adults over fifty, the contrast pairs were settled before a single screen existed, because for that audience legible is not a nice-to-have. Once a pair passes at the foundation level, nobody downstream has to re-derive it.

Dark surfaces need their own pass here, not an inherited one. A contrast pair that clears the standard in light mode does not automatically clear it in dark, because the values are different, not inverted. I have written the full case for that in how contrast gets re-decided for a dark theme, and the short version belongs on this checklist too: check the dark pair on its own terms.

Type sizing and spacing round out this layer. Text needs to resize without the layout breaking, which is a foundation decision about how a type scale behaves under zoom, not a late fix applied when someone complains. Decide it with the scale, and every screen that uses the scale inherits the answer.

States: the operable checks

Operable is the layer teams skip most often, because it is invisible until someone tries to use the product without a mouse. Every interactive element needs a visible focus state, reachable in a sensible order, and a target large enough to hit without precision. None of that is an engineering afterthought. It is a states decision, the same ones I have argued belong before the first component gets built.

On Avalon, the clinical product I designed at CureMD, an appointment could exist in eight distinct states, and the system had to name every one of them, including what each looked like on keyboard focus, before the screens could be trusted. A physician moving between patients does not have a free hand for a mouse. The discipline generalizes past healthcare: anywhere a person is interrupted, in a hurry, or working one-handed, keyboard and touch access stop being an edge case and become the main path.

Target size is the part of this layer that is easiest to get wrong on a dense screen, because a designer looking at a crowded table wants to shrink the controls, and shrinking the controls is exactly what the guideline argues against. A tap target under roughly 24 by 24 pixels is hard to hit reliably, and a row of them packed together is harder still. The fix is rarely more screen space. It is usually fewer controls shown at once, with the rest moved behind a clear next step.

A focus state decided once, at the component, outruns a focus state argued over on every screen that uses it.

Why states belong in the foundation layer, not the review pass

Content: the understandable checks

Understandable is the layer that lives in words, and it is the one a visual design review tends to skip entirely, because the screen can look finished while the copy on it is still guessing. Two checks matter most here. The first is that an error says what happened and what to do next, not just that something failed. The second is that the same action reads the same way everywhere it appears, so a person is not learning a new vocabulary on every screen.

This is where labels and microcopy stop being a finishing touch and become the accessibility work itself. On Avalon, the error state on Add Patient names what is wrong at the field, in place, rather than failing silently at save, which is the same discipline I have written about for UX microcopy that makes an interface trustworthy. A screen that is visually clean but tells a confused person nothing useful has not passed the understandable check, whatever its contrast ratio says.

Predictability is the other half. Navigation that behaves the same way on every page, and a control that does what its label says it will do, are both understandable requirements before they are usability ones. A button labeled "Save" that sometimes also submits is not a minor inconsistency. It is the guideline failing in the one place a user actually notices.

Markup: the robust checks

Robust is the layer a design file cannot fully answer on its own, but it is set up or sabotaged by the design file long before an engineer opens it. A heading order with a level skipped, a button drawn as a plain shape with no real element behind it, an image with no description: these are markup problems, and they are also design problems, because the design is what tells the build which element to reach for.

The fix costs almost nothing when it happens at design time. Naming which element a component is, button, link, heading, list, at the point the component is defined, means the build uses the right one by default instead of reconstructing one visually with a styled division. I made this case at the foundation level in what belongs in a design system before the first component: a real element used from the start is close to free, and the same markup grafted on after a screen ships is a much larger job.

Alt text belongs here too, and it is worth stating plainly for anyone building graphics off this site's own writing kit: a diagram with no description is unfinished, in exactly the sense a button with no focus state is unfinished. Every graphic in this piece, including the one above, carries real text a screen reader can read, not an image standing in for one.

Running the checklist against a real screen

None of the four layers above is optional, and none of them substitutes for another. A screen with perfect contrast and no keyboard access has passed one layer and failed the product. A screen with full keyboard access and an error message that only says "something went wrong" has passed a different layer and failed the person reading it. The guideline is not satisfied by whichever check is easiest to run. It is satisfied by all four, because a real reader does not experience WCAG as four categories, they experience one screen, and the categories only describe where a failure is likely to be hiding.

Run the checklist in the order it is written here, foundations before states before content before markup, for the same reason I have argued a design system has to be built in that order: each layer is only as solid as the one underneath it, and checking contrast on a screen with no keyboard access fixes the wrong problem first. That order, applied specifically against WCAG rather than against a general design system audit, is a large part of what my accessibility-first design work actually checks, screen by screen, in the sequence that catches the expensive gaps before they ship.

I have made the philosophical case for this elsewhere, that accessibility is a budget spent from the start rather than a test passed at the end, and the practical case for why it does not have to slow a team down in how to design for accessibility without slowing the team. This piece is the reference the other two argue for: the actual checks, grouped by the layer that owns them, run once and inherited by everything built afterward.

Takeaways

WCAG is not one checklist, it is four, and each one lives at a different layer of the design: foundations carry contrast and type, states carry focus and target size, content carries error language and consistency, and markup carries the elements and structure underneath. Check a layer once, at the layer it belongs to, and every screen built on top of it inherits the answer instead of re-earning it. A screen can pass one layer and still fail the person reading it, so run all four, in the order that catches the expensive gaps first. And treat the standard the way you would treat any other foundation decision: write down which pair, which size, which words, and why, so the next person does not have to re-derive it from a clause number.

Questions people ask about WCAG and design