How to Build Accessibility into Your Design Process: A Recognition-Based Approach

Introduction

Designers are good people. You’ve never heard one say, “I don’t care if someone can’t read this” or “Who cares if this confuses people?” Yet we’ve all seen websites, apps, or services that exclude users—text that’s too small, confusing navigation, or interactions that work only for a narrow set of abilities. The problem isn’t malice—it’s overload. Designers are expected to remember everything: visual design principles, interaction patterns, performance best practices, and a growing list of accessibility guidelines. It’s too much to recall. This guide offers a practical, step-by-step method to make accessibility a natural part of your design workflow by shifting from recalling rules to recognizing issues as you work.

How to Build Accessibility into Your Design Process: A Recognition-Based Approach

In his classic essay “This Is All There Is,” Aral Balkan reminds us that even a bus timetable app can affect life events—like missing a daughter’s birthday or failing to say goodbye to a dying grandmother. Design exclusion isn’t just an inconvenience; it can be life‑or‑death. The good news: you don’t need to memorize every accessibility guideline. Instead, you can embed cues into your design environment so that problems become visible when they happen. Let’s get started.

What You Need

Basic knowledge of accessibility principles (WCAG 2.1/2.2 guidelines, inclusive design).
Access to a design tool (Figma, Sketch, Adobe XD, or even paper prototypes).
A checklist or reference sheet – keep common accessibility success criteria handy (e.g., contrast ratios, keyboard navigation, alt text).
Testing tools – color contrast analyzers, screen readers (VoiceOver, NVDA), keyboard‑only testing.
Optional but helpful: A copy of A Web for Everyone by Sarah Horton and Whitney Quesenbery for deeper context.

Step‑by‑Step Guide

Step 1: Recognize That Exclusion Happens – and That It Matters

Before diving into checklists, accept two truths: (1) every design choice includes or excludes someone; (2) exclusion can have serious consequences. Remind yourself of Aral Balkan’s life‑event/death‑event framing. This isn’t about guilt—it’s about motivation. When you start a project, take two minutes to imagine a user who relies on a screen reader, or someone with low vision, or a person with a motor tremor. Write down one critical task they need to complete on your site. Keep that in mind as you design.

Why this works: It transforms abstract guidelines into human stories, making it easier to recognize where a design may fall short.

Step 2: Apply Nielsen’s Heuristic #6 – Recognition Rather Than Recall – to Your Process

Jakob Nielsen’s tenth heuristic for usability is “Recognition rather than recall.” He applied it to users, meaning interfaces should show options instead of making users remember commands. Let’s apply the same idea to designers: make accessibility information visible or easily retrievable while you work. Instead of memorizing contrast ratios or heading levels, bake those rules into your tools and environment.

Create a “Design Accessibility Palette” – a library of components (buttons, forms, text styles) that already meet accessibility standards. Use these as building blocks.
Set up automated checks – plugins for Figma or Sketch that flag low‑contrast text, missing alt tags, or insufficient touch targets.
Post physical or digital reminders near your workspace (e.g., a poster of common accessibility errors).

Example: If you use a color picker, enable a contrast checker that shows pass/fail instantly. Suddenly, you don’t recall the 4.5:1 ratio; you see it.

Step 3: Let Go of Perfection – Use a Simple Checklist, Not a Manual

Full WCAG guidelines run hundreds of pages. Instead of recalling them all, use a condensed checklist that covers the most common issues. Start with these five critical checks:

Color contrast – text on background must meet at least 4.5:1 (AA) or 7:1 (AAA).
Keyboard navigation – can every interactive element be reached and used with the keyboard alone?
Meaningful link text – avoid “click here”; use descriptive labels like “View your account.”
Alt text for images – every image that conveys information needs alt text; decorative images should have empty alt.
Clear headings and landmarks – use proper heading hierarchy (H1, H2, etc.) and ARIA landmarks for screen readers.

Keep this checklist on a sticky note or as a template in your design file. Review it at each milestone: wireframes, high‑fidelity mockups, and before handing off to development.

Step 4: Design in a Way That Makes Accessibility Issues Obvious

If you’re creating wireframes, add labels like “This image will need alt text” or “This link’s purpose is unclear.” Use placeholders that force you to think about accessibility. For example, rather than inserting a generic icon, ask yourself: what’s the functional equivalent for a screen reader? Write it down right there.

Pro tip: In your design file, create a “critical fixes” layer that highlights known accessibility gaps – a layer you remove only after you’ve addressed each point.

Step 5: Test in a “Recognition‑Rich” Environment

During testing, don’t rely on memory. Set up a testing environment where you can instantly spot accessibility failures.

Use browser extensions like Axe, WAVE, or Lighthouse – they highlight issues directly on the page.
Test with a screen reader turned on while you navigate your prototype. Errors become audible.
Try keyboard‑only navigation: if you get stuck, you see the problem in real time.

Document what you find. Each time you identify a problem, it becomes easier to recognize the same pattern in future projects.

Step 6: Iterate and Educate – Make Recognition a Habit

Over time, your brain will build a mental library of accessibility patterns. The goal isn’t to memorize WCAG success criteria; it’s to recognize failure modes as quickly as you recognize a misspelled word. Share your checklists and automated checks with your team. Hold brief “accessibility moments” in design reviews.

Remember that good designers care – but caring isn’t enough when the cognitive load is too high. By designing your process around recognition, you free up mental energy for creativity while ensuring no one gets left behind.

Tips and Final Thoughts

Start small. Pick one or two accessibility checks to integrate into your daily routine before expanding.
Use the right tools. Contrast checkers, screen readers, and accessibility plugins are your friends – they turn recall into recognition.
Reference “A Web for Everyone.” Sarah Horton and Whitney Quesenbery’s book is an excellent resource for understanding user‑centered accessibility.
Remember: this is life‑or‑death stuff. A missing alt text or bad contrast can prevent someone from booking a life‑saving medical appointment or from staying connected with loved ones. But don’t dwell on fear – channel it into practical steps.
Be kind to yourself. You can’t fix everything at once. Aim for incremental improvement. Every accessible tweak you make is a win.

By shifting the burden from your memory to your design environment, you make accessibility a natural, nearly effortless part of your workflow. Start today: pick one of the steps above and add a recognition cue to your next project. Your users – and your future self – will thank you.