Process

Accessibility in Design Reviews

By EZUD Published · Updated

Accessibility in Design Reviews

Design reviews are one of the most cost-effective moments to catch accessibility issues. A barrier identified during design review costs a fraction of what it costs to fix after development. Yet most design review processes do not include accessibility criteria. Adding a structured accessibility checkpoint to design reviews embeds accessibility into the team’s natural workflow and ensures that accessibility is evaluated alongside aesthetics, usability, and brand consistency.

Why Design Reviews Matter for Accessibility

Designers make decisions that determine accessibility: color contrast, heading hierarchy, focus order, interaction patterns, motion, touch target sizes, and error handling. Once these decisions are locked in and handed to development, changing them becomes progressively more expensive (see cost of retrofitting vs. designing accessibly).

A design review that evaluates accessibility catches issues like:

  • Insufficient color contrast before the palette is finalized
  • Missing keyboard interaction patterns before development begins
  • Heading hierarchy that does not match visual structure
  • Interactive elements that rely on hover or gesture without keyboard alternatives
  • Focus order that does not match the visual reading order
  • Missing design annotations for developers (alt text, ARIA labels, error messages)

What to Review

Visual Design

  • Color contrast. Does all text meet the 4.5:1 ratio (normal text) or 3:1 ratio (large text)? Do UI components and graphical objects meet 3:1 against adjacent colors?
  • Color independence. Is information conveyed through a secondary channel (icon, text, pattern) in addition to color? Think form field errors, status indicators, chart data series.
  • Typography. Is the body text at least 16px? Is line height at least 1.5x the font size? Can text be resized to 200% without loss of content?

Interaction Design

  • Keyboard interaction. For every interactive element, is the keyboard interaction pattern specified? Does it follow the W3C ARIA Authoring Practices Guide?
  • Focus indicators. Are custom focus indicators designed? Do they meet WCAG 2.2 focus appearance requirements (minimum area, contrast)?
  • Touch targets. Are interactive targets at least 24x24 CSS pixels (WCAG 2.5.8)?
  • Error handling. Are error messages clear, specific, and programmatically associated with the fields they describe?

Content and Structure

  • Heading hierarchy. Does the heading structure reflect the content hierarchy? Are levels sequential?
  • Reading order. Does the visual layout match the intended reading order for assistive technology?
  • Alternative text. For every image and icon, is the purpose documented? Is alt text specified for informational images and empty alt for decorative ones?

Motion and Animation

  • Reduced motion. Is there a plan to respect prefers-reduced-motion? Is any essential content conveyed only through animation?
  • Autoplay. Does any content auto-play? Can it be paused?

Annotations for Development

  • Heading levels for all text that looks like a heading
  • Focus order for interactive elements (especially in complex layouts)
  • ARIA labels for interactive elements that lack visible text
  • Expected screen reader announcements for dynamic content (toasts, modals, live updates)
  • Error message location, content, and programmatic association

See training designers on accessibility for building the skills needed to create thorough annotations.

Review Process

Add accessibility to the review checklist

Create a standing accessibility checklist that reviewers use alongside existing criteria. Keep it concise and actionable: no more than 15-20 items. Align items with WCAG 2.2 Level AA success criteria.

Designate an accessibility reviewer

For each review, assign at least one reviewer with accessibility knowledge. This could be an accessibility champion, an accessibility specialist (see hiring accessibility specialists), or a designer who has completed accessibility training.

Use structured feedback

Organize feedback by category (visual, interaction, content, annotation) and severity (blocking, major, minor). Blocking issues prevent the design from proceeding to development. Major issues should be resolved before development starts. Minor issues can be tracked for resolution during implementation.

Review at multiple milestones

Do not wait for final mockups. Review accessibility at:

  • Wireframe stage: Information architecture, heading structure, focus order.
  • Visual design stage: Color contrast, typography, touch targets, focus indicators.
  • Interaction specification stage: Keyboard patterns, error handling, dynamic content behavior.
  • Prototype stage: If a coded prototype is built, test it with keyboard and screen reader before usability testing.

Integrating with the Broader Process

Design reviews are one checkpoint in the inclusive design process. They connect to:

Key Takeaways

  • Design reviews are the cheapest moment to catch accessibility issues.
  • Review color contrast, keyboard interaction, heading hierarchy, focus order, touch targets, and annotations at every design milestone.
  • Designate an accessibility reviewer and use a structured checklist.
  • Review at wireframe, visual design, and interaction specification stages, not just final mockups.
  • Document decisions and track unresolved issues through the backlog.

Sources

More in Process

Inclusive Design Process Guide: Building Accessibility Into Every Stage Guide Continuous Accessibility Monitoring Nothing About Us Without Us: The Principle That Shapes Inclusive Design Disability Etiquette in the Workplace: A Practical Guide

View all Process articles →