Accessibility lands on a designer's desk labelled as a development problem, and the label is wrong. Contrast is a colour decision. Target size is a spacing decision. Focus states, error wording, heading levels and reading order all get settled in the file, weeks before anyone opens an editor. So the honest answer to what accessibility asks of a designer is a short list of decisions, and this page walks through them in the order you would actually make them.
Making those decisions in the file costs minutes. Making them again in production costs a sprint, plus the awkward conversation about why the thing that was signed off has to change. That gap is the whole argument for reading on.
The Myth Worth Killing First
Accessible design does not mean ugly design. It does not mean a beige page with black text and no ideas in it.
What it actually constrains is smaller than most designers fear. Colour pairs need measurable contrast. Interactive things need to be big enough to hit and visible when they take focus. Meaning cannot ride on colour alone, layouts have to survive being enlarged, and anything that starts moving on its own needs a way to stop it. That is close to all of it. The typography, the imagery, the illustration, the motion, the personality, all of that is still yours, and nothing below takes any of it away.
We have audited beautiful sites that passed and beautiful sites that failed. The difference was never how much visual ambition the designer had. It was whether the five decisions below got made on purpose or by accident.
The Five Decisions That Get Made in the File
1. Your Palette, Decided Once Rather Than Per Screen
Low-contrast text is the failure automated testing detects on more home pages than any other, and it is the one that arithmetic settles completely before you ship. Body text needs 4.5:1 against its background. Large text needs 3:1, and large has a specific meaning here. WCAG defines it in points, at least 18 point, or 14 point bold, and W3C gives the pixel equivalents as roughly 24px and 18.5px. Anything smaller than that owes the full 4.5:1, which catches out a lot of 20px headings.
There is a third ratio, and it is the one designers miss because it is not about text at all. Where a graphic or a control can only be identified by how it looks against what surrounds it, that visual information needs 3:1 as well. Be precise about the scope, because it saves you real work. The rule covers what is required to identify a component or its state. A purely decorative border, a hover tint, and a colour shift between two states you can already tell apart some other way all sit outside it.
Settle all of this once, at the palette stage, rather than screen by screen. Our palette builder takes your brand colour and marks each shade against the 4.5:1 body-text bar with white or dark text, so you can settle the combinations before anyone uses them across sixty screens. It measures that one threshold, so a shade it marks as failing may still carry large text or a border at 3:1. The contrast checker settles individual pairs, and our colour and contrast guide covers the cases a formula cannot reach, such as text over photography.
2. The States Nobody Draws
Most design files show the resting state, and maybe hover. The states that carry accessibility sit further down the list, and every one of them is a decision somebody has to make deliberately, because the file is where the words and the colours for it get chosen.
- Focus. What a keyboard user sees, and it is not hover. The indicator needs 3:1 against the colours next to it, and it has to stay visible rather than sliding under a sticky header. Remove the browser default without drawing a replacement and keyboard users lose their place on your site entirely.
- Hover, focus and touch activation, as three separate things. W3C's own designer guidance names all three, because a phone has no hover and a keyboard has no pointer. A cue that only exists on hover is invisible to most of the people it was drawn for.
- Error. With the real message written into the file, not "Error text here". "Invalid input" is a placeholder pretending to be a design, and it ships more often than you would believe.
- Empty, loading and success. Each one has to announce itself to a screen reader, which means somebody has to decide the words. Leave them out and the page changes in silence.
- Disabled. Draw it readable anyway, and know that you are choosing to. WCAG exempts inactive components from both of its contrast rules, so a greyed-out button at 2:1 is not a finding. It is still a person who cannot read why they cannot continue.
That last one is worth separating from the rest, because a designer who reports a low-contrast disabled state as a WCAG failure will be wrong and will lose the argument. Four of those states are rules. The fifth is our advice, and it is good advice.
3. Size and Spacing of Anything Clickable
WCAG 2.2 asks for 24 by 24 CSS pixels, and there are five ways out of it rather than the one exception most summaries mention. Spacing, where the targets sit far enough apart that a 24-pixel circle centred on each one does not touch its neighbour. Equivalent, where the same job can be done by another control on the same page that does meet the size. Inline, where the target sits inside a sentence or is held to the line height of the text around it. User agent control, where the browser decides the size and you have not touched it. And essential, where that exact presentation is required.
The spacing one is the exception that matters, and it is not really an exception. It is a second way to pass, and most small targets with room around them already meet it. So the design rule that keeps you safe is 24 by 24, or spaced far enough apart that those circles never touch.
Above the minimum, the platform vendors ask for more than W3C does. Apple's guidance is 44 by 44 points and Android's is 48dp, and neither number comes from WCAG. Design to those and the question stops coming up. This bites hardest on icon rows, close buttons, table row actions and anything in a dense toolbar, which is exactly where a design file tends to stop paying attention.
4. Layout That Survives Being Enlarged
Somebody using magnification is reading your page at a size you never mocked. The rule that covers it asks for no scrolling in two directions at once, at a width equivalent to 320 CSS pixels for content that scrolls down, or a height equivalent to 256 for content that scrolls sideways.
Two facts about that number turn an abstract rule into a test you can run this afternoon. The first is that 320 CSS pixels is what a 1280-pixel window becomes at 400% zoom, which is where the 400% figure everyone quotes comes from. The second is that a single column is not required, whatever you have read. Two narrow columns that still read down the page scroll in one direction and pass, so collapsing a card grid that already conformed is work the standard never asked anyone to do.
The rule also excuses content that genuinely needs two dimensions, and that is a permission slip as much as a constraint. Images required for understanding, such as maps and diagrams. Video. Games. Presentations. Data tables, as tables rather than as individual cells. And interfaces that have to keep a toolbar in view alongside the thing it acts on. Knowing you have that exception stops you flattening a data table into something nobody can read.
Mock the 400% state deliberately for one complex screen. Fixed-height cards, side-by-side columns that never collapse, and sticky headers that eat the viewport are the three things that break, and all three are cheaper to solve in the file than in the build.
5. Anything That Starts Moving On Its Own
W3C's designer guidance ends on the point design files address least often, which is that content starting by itself needs a control to stop it. A rotating carousel, a background video, an animated hero. Anything that moves, blinks or scrolls by itself for more than five seconds owes the user a way to pause it, stop it, or hide it.
That control is a design element, and it belongs in the file with a size, a position and a label. Leave it out and it gets bolted on later as a small grey square in a corner nobody can hit. Our motion and animation guide covers which rule catches which kind of movement, because auto-playing motion and interaction-triggered motion are two different requirements at two different levels.
The greyscale test
Take any screen and view it in greyscale. Anything that becomes ambiguous was leaning on colour: required fields, error states, chart series, links inside paragraphs. It takes ten seconds. It also over-reports, because stripping the hue strips the lightness difference that can satisfy the rule on its own, so treat what it finds as candidates to look at rather than failures to log.
Every Breakpoint Counts as Its Own Page
One line in WCAG's conformance section changes how a design review should work. Where a page presents different content or a different layout at different window sizes, every one of those variations has to conform on its own.
So your mobile layout is not a shrunken version of a desktop page that already passed. It is a page, and it is judged as one. That is also why the 400% mock earns its half hour, and why a design review that only ever looks at the desktop composition is reviewing a fraction of what ships.
What to Hand the Developer
What you annotate gets built. What you leave unsaid gets guessed, usually wrong, and then it turns up as a finding in somebody's audit report months later with your name on the file that caused it.
| Annotate | Why | If you do not |
|---|---|---|
| Heading level of every text block | H1 to H6 is structure, not size | Developers pick by appearance, and the outline lies |
| Focus order on complex screens | Especially where visual layout differs from source order | Focus jumps around and keyboard users get lost |
| Alt text for every image | You know what the image is for. They do not | You get the filename, or "image" |
| Accessible names for icon-only buttons | A screen reader announces the name, not the icon | It is announced as "button", meaning nothing |
| Which images are decorative | Decorative ones must be skipped, not described | Screen reader users wade through announced noise |
| Real error message wording | Errors have to say what is wrong and what to do | You ship "Invalid input" |
Designing for the People, Not the Rule
It helps to picture who each decision serves, because the rules read as arbitrary right up until you do.
- Someone using magnification reads your page at 400%, which is 320 pixels of width. Your reflow decision settles whether they read a sentence straight through or drag sideways for every line of it.
- Someone colour blind, which is roughly one man in twelve and about one woman in two hundred, sees your red error border as a grey border. Your decision to add an icon or a word settles whether they know what went wrong.
- Someone with a tremor aims at your close button. Your target size decision settles whether they hit it or the thing behind it.
- Someone using a keyboard after a wrist injury tabs through your form. Your focus state decision settles whether they can see where they are.
- Someone with a cognitive disability reads your error message. Your wording decision settles whether they finish the task or abandon it.
- Someone with vestibular sensitivity loads your animated hero. Your decision to give it a stop control settles whether they can stay on the page at all.
None of those people are edge cases. Colour vision deficiency alone reaches around 300 million people worldwide, and the rest of that list is the ordinary variety of people who use websites.
Where to Start Tomorrow
- Audit your palette, once, and mark which combinations pass, so everything downstream inherits a decision that is already been made.
- Draw the focus state into your design system, and nobody has to invent one per screen or leave it out under deadline.
- Run the designer's checklist on your next major screen. Nineteen checks, about thirty minutes, and you will know where you stand before anyone builds it.
- Write the error messages in the file rather than leaving placeholders, and the words that ship are the ones you chose.
- Mock one screen at 400% and see what breaks, which is cheaper today than after forty templates inherit it.
One honest limit
Design checks catch what can be decided before build. They cannot catch what happens during it. A heading that becomes a styled div, a focus state dropped for looking untidy, a modal that lets focus wander out behind it. Those need testing on the built thing, which is what our design-stage review and then a full audit are for.