Why designers need their own accessibility checklist
Most accessibility checklists are written for developers. They talk about ARIA roles, semantic markup and automated test suites, which is useful once code exists but far too late in the process. By the time a build starts, roughly half of the accessibility issues on a typical website have already been baked into the design files: contrast that is too low, focus states that were never drawn, forms with placeholder-only labels, heading levels chosen for looks rather than structure.
This is a web accessibility checklist for designers that you can run yourself, visually, in Figma or directly in the browser, without writing a line of code. Every item below is tied to a real WCAG success criterion (we reference WCAG 2.2 AA, the current version), but explained in plain language with the reason it matters for an actual human being using your interface.
Run it as a pre-launch audit: allow about 90 minutes for a small marketing site, half a day for a product with forms and dashboards. The piece WCAG Checklist 2.1 AA and 2.2 AA makes a good next read.
Before you start: three things to have open
- Your design file with the final screens, plus any states (hover, focus, error, empty, loading).
- A contrast checker: a Figma contrast plugin, the WebAIM Contrast Checker, or your browser DevTools colour picker, which shows the ratio directly.
- A keyboard. Yes, really. Half of this checklist is done with the Tab key on a staging URL.
If the site is already in staging, run an automated scan too (axe DevTools, WAVE or Lighthouse). Automation catches around 30 to 40 percent of issues. The 18 checks below cover most of what automation misses, and they are exactly the parts a designer owns.
Part 1: Colour and contrast (checks 1 to 4)
1. Text contrast meets 4.5:1 (or 3:1 for large text)
Why it matters: low contrast is the single most common accessibility failure on the web. It affects people with low vision, anyone over 50 with reduced contrast sensitivity, and every user reading on a phone in daylight.
How to check: sample every text colour against the background it actually sits on, including text over photos, gradients and coloured buttons.
| Element | Minimum ratio (AA) | Notes |
|---|---|---|
| Body text, small labels | 4.5:1 | Under 24px regular, or under 19px bold |
| Large text | 3:1 | 24px+ regular, or 19px+ bold |
| Icons, borders, chart keys | 3:1 | Only when they carry meaning |
| Disabled elements | No requirement | Still keep them readable in practice |
WCAG 1.4.3 Contrast (Minimum), Level AA.
2. Non-text elements have 3:1 contrast
Why it matters: a form field with a pale grey 1px border is invisible to a lot of people. So is a ghost button, a toggle in its off state, or an icon-only menu button.
How to check: look at input borders, checkboxes, radio buttons, toggles, sliders, icon buttons and chart lines. Each must reach 3:1 against whatever sits next to it.
WCAG 1.4.11 Non-text Contrast, Level AA.
3. Colour is never the only signal
Why it matters: around 1 in 12 men has some form of colour vision deficiency. If a red border is the only sign that a field failed validation, or green versus red is the only difference between two statuses, that information disappears.
How to check: take a screenshot, desaturate it to greyscale, and ask whether you can still understand every state. Add an icon, a label, a pattern or text wherever the answer is no.
WCAG 1.4.1 Use of Color, Level A.
4. Links inside body text are identifiable without colour
Why it matters: this is check 3 applied to the most common case. A blue link in a paragraph of black text is a colour-only cue unless the contrast between link and surrounding text is at least 3:1 and a non-colour cue appears on hover and focus.
The safe design decision: underline in-text links. It is boring and it works. Navigation links and buttons, which are identifiable by position and shape, do not need it.
Part 2: Typography and reading (checks 5 to 7)
5. Body text is at least 16px with comfortable line height
Why it matters: WCAG does not set a minimum font size, but small type is the fastest way to make content unusable on mobile. 16px body text, line height around 1.5, and paragraph width capped near 70 to 80 characters are the practical defaults.
Also check: avoid justified text (uneven word spacing creates rivers that are hard to track) and avoid long passages in all caps or in light font weights on light backgrounds.
6. The layout survives 200% zoom and increased text spacing
Why it matters: many people browse at 150 to 200% zoom permanently. If your fixed-height cards, single-line buttons or sticky headers break, they lose content.
How to check in the browser: press Ctrl/Cmd and + until you reach 200%, then read the page. Nothing should be cut off, overlap, or require horizontal scrolling. In Figma, test whether text containers are set to hug or fill rather than fixed height.
WCAG 1.4.4 Resize Text and 1.4.12 Text Spacing, Level AA.
7. No text baked into images
Why it matters: text inside a JPG or PNG cannot be zoomed cleanly, cannot be selected, cannot be translated, and cannot be read by a screen reader unless it is duplicated in alt text. Hero banners with typographic slogans are the usual offender.
The fix: layer real text over the image. Logos are the only genuine exception.
WCAG 1.4.5 Images of Text, Level AA.
Part 3: Structure and hierarchy (checks 8 to 10)
8. Heading levels are planned, not styled by eye
Why it matters: screen reader users navigate by jumping from heading to heading, the way sighted users skim. A page where every heading is styled the same size, or where H2 is skipped to reach H4 because it looked better, becomes a flat wall of text.
How to check: annotate every heading in your design file with its level. One H1 per page, describing the page. No skipped levels going down. If two headings need to look identical but sit at different levels, that is a styling decision, not a structural one.
WCAG 1.3.1 Info and Relationships, Level A.
9. Reading order matches visual order
Why it matters: a screen reader follows the order of the code, not the order your eye takes. Two-column layouts, cards where the image sits after the text in the file, and absolutely positioned badges frequently read out in a scrambled sequence.
How to check: in Figma, the layer order is your best proxy. Order layers top to bottom the way they should be read. Better still, add an explicit annotation arrow on complex screens so the developer does not have to guess.
WCAG 1.3.2 Meaningful Sequence, Level A.
10. Landmarks and page titles are specified
Why it matters: header, navigation, main content, footer and search are the shortcuts assistive technology users rely on to skip past the parts they have already heard fifty times.
How to check: label the regions in your design annotations, and write the unique page title for each template (the browser tab text). If two templates in your file have the same title, someone with fifteen tabs open cannot tell them apart.
Part 4: Keyboard, focus and targets (checks 11 to 14)
11. Every interactive element has a designed focus state
Why it matters: keyboard users, people with motor impairments using switch devices, and plenty of power users navigate with Tab. If the focus ring is removed for aesthetic reasons and nothing replaces it, the interface becomes literally unusable: you cannot see where you are.
What good looks like: a visible indicator with at least 3:1 contrast against the adjacent background, at least 2px thick, ideally with a small offset so it does not blend into the component. Design it once as a token and apply it everywhere: links, buttons, inputs, cards, tabs, custom dropdowns.
WCAG 2.4.7 Focus Visible (AA) and 2.4.11 Focus Appearance (AAA in 2.2, but worth aiming for).
12. Tab order is logical and nothing hides the focused element
Why it matters: if focus jumps from the header to the footer and back up to a sidebar, users get lost. And if a sticky header, cookie banner or chat widget covers the element that just received focus, they cannot see what they are about to activate.
How to check in the browser: load the staging page, put your hands on the keyboard only, and press Tab through the entire page. Write down anything that is skipped, out of order, invisible, or covered. It is argued more carefully on penpot.app.
WCAG 2.4.3 Focus Order (A) and 2.4.11 Focus Not Obscured (AA, new in WCAG 2.2).
13. There is a skip link, and modals trap focus correctly
Why it matters: without a skip link, a keyboard user tabs through 40 navigation items on every single page. Without proper focus management, opening a modal leaves focus behind it, so the user tabs invisibly through the page underneath.
Design it: a “Skip to main content” link that is hidden until it receives focus, then appears clearly at the top left. For modals, specify where focus goes on open, that Escape closes it, and where focus returns on close.
14. Touch targets are large enough and well spaced
Why it matters: small, tightly packed targets are hard for anyone with tremors, limited dexterity, or a thumb on a moving train. WCAG 2.2 sets a minimum of 24 by 24 CSS pixels; usable design starts around 44 by 44.
How to check: measure icon buttons, close crosses, pagination numbers, table row actions and inline delete icons. Increase the clickable area even if the visual icon stays small. one studio that takes it seriously treats this as a baseline.
WCAG 2.5.8 Target Size (Minimum), Level AA, new in 2.2.
Part 5: Forms (checks 15 to 16)
15. Every field has a persistent visible label
Why it matters: placeholder-only forms look clean and fail badly. The placeholder disappears the moment someone starts typing, so anyone interrupted mid-form loses the context. Placeholder text is also usually low contrast, and some screen readers do not announce it reliably.
Checklist within the check:
- Label sits above or beside the field and stays visible
- Required fields are marked in text, not with a red asterisk alone
- Help text appears before the input, not only after an error
- Related radio buttons and checkboxes are visually grouped with a group label
WCAG 3.3.2 Labels or Instructions, Level A.
16. Errors are explained in text, next to the field
Why it matters: “Invalid input” in red at the top of a 20-field form helps nobody. Users need to know which field, what is wrong, and how to fix it.
Design the error state with: an icon plus colour plus text, the message adjacent to the field it concerns, a summary at the top of long forms that links to each error, and no loss of already-entered data. Also avoid asking users to re-enter information they gave earlier in the same process (WCAG 2.2 added 3.3.7 Redundant Entry for exactly this reason).
WCAG 3.3.1 Error Identification and 3.3.3 Error Suggestion.
Part 6: Media and motion (checks 17 to 18)
17. Alt text is written by the designer, not left to chance
Why it matters: if nobody writes the alt text, the content editor writes “image1.jpg” or the developer leaves it empty. The person who chose the image knows why it is there, so they are the right person to describe its purpose.
The three cases:
- Informative image: describe the information it carries, in one sentence, without starting with “Image of”.
- Decorative image: mark it explicitly as decorative so it is skipped (empty alt attribute). Background textures, dividers and mood photography usually fall here.
- Functional image: an icon or image used as a link or button. Describe the action, not the picture. A magnifying glass icon is “Search”, not “magnifying glass”.
Charts and infographics need more: a short alt plus a longer description or a data table nearby. Video needs captions, and audio needs a transcript.
WCAG 1.1.1 Non-text Content, Level A.
18. Motion is limited, pausable and respects reduced-motion settings
Why it matters: parallax, large sliding transitions and autoplaying carousels can trigger nausea, dizziness and migraines in people with vestibular disorders. Content that moves or scrolls automatically also makes reading harder for people with attention or reading difficulties.
How to check: anything that animates for more than 5 seconds needs a pause control. Nothing should flash more than three times per second. Specify a reduced-motion variant of your key animations (usually a simple fade or no motion at all) so the site respects the operating system preference.
WCAG 2.2.2 Pause, Stop, Hide and 2.3.1 Three Flashes.
The one-page summary table
| # | Check | Where to test | WCAG |
|---|---|---|---|
| 1 | Text contrast 4.5:1 / 3:1 | Figma or DevTools | 1.4.3 |
| 2 | UI element contrast 3:1 | Figma | 1.4.11 |
| 3 | No colour-only meaning | Greyscale screenshot | 1.4.1 |
| 4 | In-text links underlined | Figma | 1.4.1 |
| 5 | 16px+ body text, 1.5 line height | Figma | Best practice |
| 6 | Works at 200% zoom | Browser | 1.4.4 / 1.4.12 |
| 7 | No text inside images | Figma | 1.4.5 |
| 8 | Heading levels annotated | Figma | 1.3.1 |
| 9 | Reading order matches visuals | Layer panel | 1.3.2 |
| 10 | Landmarks and page titles | Annotations | 2.4.2 |
| 11 | Visible focus state everywhere | Figma + Tab key | 2.4.7 |
| 12 | Logical, unobscured tab order | Browser | 2.4.3 / 2.4.11 |
| 13 | Skip link and modal focus | Browser | 2.4.1 |
| 14 | Target size 24px min, 44px ideal | Figma | 2.5.8 |
| 15 | Persistent visible form labels | Figma | 3.3.2 |
| 16 | Clear inline error messages | Figma | 3.3.1 / 3.3.3 |
| 17 | Alt text written and specified | Content sheet | 1.1.1 |
| 18 | Motion pausable and reducible | Browser | 2.2.2 / 2.3.1 |
The five mistakes we see most often in design handoffs
- Focus states missing from the component library. Hover exists, active exists, focus does not. Developers then ship the browser default, or nothing at all.
- Placeholder-only forms. Still the most common pattern in modern design systems, still a failure.
- Heading levels chosen for size. A designer wants a smaller heading, so they pick H4 in a section that should be H2.
- Grey on grey. Secondary text at #999 on #FFF gives roughly 2.8:1, which fails. Push it to about #767676 and it passes.
- No error, empty or loading states delivered at all. Whatever you do not design, someone else will improvise.
Where this fits in the wider picture
Since June 2025, the European Accessibility Act applies to a broad range of digital products and services sold in the EU, including e-commerce, banking, transport and e-books. In Belgium and across the EU, WCAG 2.1 AA is the reference level in practice, with WCAG 2.2 AA increasingly expected as the baseline for new projects. We are not going to turn this into a legal briefing: the practical point is that the checks above cover the large majority of what an audit will flag, and they cost almost nothing when done during design instead of after launch.
A rough order of magnitude from our own projects: fixing a contrast or label problem in Figma takes minutes. Fixing the same problem after the component has shipped across 60 pages takes days. The team at github.io reached a similar conclusion.
How to make this stick beyond one project
- Bake it into the design system. Focus rings, error states, minimum target sizes and an accessible colour palette should be tokens, not per-project decisions.
- Add an accessibility column to your handoff annotations: heading level, alt text, label, aria intent, tab order.
- Make check 12 a habit. Tabbing through a staging page takes two minutes and finds more real problems than any plugin.
- Test with real assistive technology once per project. VoiceOver on macOS or NVDA on Windows, on your three most important flows.
FAQ
Do I need to be a developer to run this checklist?
No. Checks 1 to 11 and 14 to 17 are done entirely in your design file. Checks 12, 13 and 18 need a staging URL and a keyboard, which is still not coding.
Which WCAG version should designers follow in 2026?
WCAG 2.2 at Level AA. It includes everything from 2.1 AA plus a few criteria that are directly relevant to design work: focus appearance, focus not obscured, target size, dragging alternatives and redundant entry. WCAG 3.0 is still in draft and is not a compliance target yet.
Is AA enough, or should we aim for AAA?
AA is the recognised target for websites and the level referenced by most regulations. AAA is not realistic across an entire site (7:1 contrast on every text element, for instance), but individual AAA criteria are worth adopting selectively, especially the enhanced focus indicator.
How long does a pre-launch accessibility audit take?
For a brochure site of 8 to 12 templates, plan roughly 90 minutes with this checklist plus an automated scan. For an application with forms, tables, modals and dashboards, plan a full day and include a manual screen reader pass on the critical flows.
What about automated tools, are they enough?
They are useful and fast, and you should run them, but they detect only about a third of issues. No tool can tell you whether alt text is meaningful, whether the tab order makes sense, or whether the error message actually helps someone fix their mistake. Those are design judgements.
Can we retrofit accessibility after launch?
Yes, and sometimes there is no choice. It is simply more expensive. Contrast and label fixes are usually cheap; reworking heading structure, keyboard navigation and complex custom components after the fact often means rebuilding them.
Need a second pair of eyes?
At DRIC we run accessibility audits on design files and live sites, and we help teams turn the results into design system components that stay compliant. If you are approaching a launch and want an independent pass over your interface before it goes out, get in touch and we will tell you where you stand.
