Design Review Accessibility Checklist

Accessibility checks for visual and interaction design. Use during design review or handoff to catch accessibility issues before they reach code.

Interactive Design

0 of 24 items complete

Color and Contrast

Text contrast meets WCAG AA 4.5:1 for body text, 3:1 for large text (18pt+). Color Contrast guide
Non-text elements meet 3:1 contrast Borders, icons, focus rings, form field outlines (SC 1.4.11). Color Contrast guide
Information is not conveyed by color alone Use icons, patterns, underlines, or text labels alongside color (SC 1.4.1).
Design works in both light and dark modes Contrast ratios verified in each theme, no invisible elements.
Design is usable in Windows High Contrast Mode Text and interactive elements remain visible with system colors.

Typography and Content

Heading hierarchy is logical (h1-h6) One h1 per page, no skipped levels, headings reflect content structure. Semantic HTML guide
Body text is at least 16px Smaller text is harder to read, especially on mobile.
Line height is at least 1.5x the font size Paragraph text has sufficient spacing for readability (SC 1.4.12).
Content width does not exceed 80 characters Long lines are harder to track; max-width helps readability.
Link text is descriptive and meaningful "Read the accessibility guide" not "click here" or "read more".

Interactive Elements

Touch/click targets are at least 24x24 CSS pixels Buttons, links, form controls, icons (SC 2.5.8). WCAG 2.2 Overview
Focus states are designed and visible Custom focus indicators with 2px+ outline and 3:1 contrast.
Hover/focus content is dismissable and persistent Tooltips and popovers: Escape to dismiss, hoverable, visible until dismissed (SC 1.4.13). Tooltip pattern
Error states use multiple signals Color + icon + text message, not just red border. Forms pattern
Loading and progress states are communicated Spinners have text alternatives, progress bars indicate status.

Layout and Navigation

Visual order matches reading/DOM order Layout doesn't reposition content in ways that break logical reading sequence.
Navigation is consistent across pages Same position, same order, same labels (SC 3.2.3).
Help mechanism appears in consistent location Contact, FAQ, or support is in same place on every page (SC 3.2.6).
Design works at 400% zoom / 320px width Content reflows to single column without horizontal scrolling (SC 1.4.10).
Modal and overlay designs include focus management Design specifies where focus goes on open and close. Modal pattern

Motion and Animation

Reduced motion alternative exists for all animations Essential content changes don't rely on animation. prefers-reduced-motion support.
No content flashes more than 3 times per second Risk of seizures (SC 2.3.1).
Auto-playing media can be paused Video, audio, and animated content has pause/stop controls (SC 1.4.2, 2.2.2).
Carousels and sliders have pause and keyboard controls Auto-advance pauses on hover/focus, arrow keys or buttons navigate slides.

Frequently asked questions

Who runs this checklist — designer or developer?

Designers, primarily. The items are about decisions made in Figma / Sketch / Adobe XD before implementation — color contrast, target sizes, focus indicators, type hierarchy. A developer can review the same questions during code review, but the cost-to-fix is much lower if these are caught in the design phase.

Should I run this during the design phase or after?

During. The whole point of a design-review checklist is catching accessibility decisions while they're still cheap to change. By the time mocks are handed off to engineering, redesigning the focus indicator or recoloring the warning state is much more work. Run this at component-design and at page-flow review.

What tools help with design-time contrast checking?

Use the Stark plugin (Figma/Sketch), Adobe's built-in contrast checker, or web tools like WebAIM Contrast Checker. Every text/background pair must clear 4.5:1 (normal text) or 3:1 (large/UI). See the Color Contrast guide.

Why is design accessibility separate from development?

Some issues are baked in at design (color choices, type hierarchy, target sizes) and can't be fixed in code without a design redo. Other issues are introduced in development (ARIA, focus management, semantic HTML). The checklists separate so each role catches what they own — developers shouldn't be debugging a low-contrast warning state that was approved in the mock.

Does this cover dark mode?

Yes — every contrast and color decision must be verified in both modes. Dark-mode designs often quietly drop below contrast minimums because designers test against bright displays. Use a luminance-based contrast checker on the dark palette explicitly, and verify focus indicators are visible against the darker backgrounds.

How do I sign off on the design before handoff?

Complete the checklist, screenshot the progress (or print it), and attach to the design ticket. If items can't be fully verified at the design stage (e.g., motion behavior, screen reader announcements), flag them as "verify in dev" and link to the Developer checklist for the engineering pass.