Designing for Accessibility: A Complete Guide

Good Design Works for Everyone. Great Design Works for Everyone Without Exception.

Over 1.3 billion people worldwide live with some form of disability. That is 16% of the global population — more than the entire population of the United States — who may be struggling to use your product right now.

Accessibility is not a checkbox. It is not a legal requirement you grudgingly meet. It is the difference between a product that includes people and one that silently excludes them.

💡 The best part about designing for accessibility: Every improvement you make for users with disabilities makes the experience better for every user. Captions help people in noisy environments. High contrast helps people in bright sunlight. Keyboard navigation helps power users.

This is the complete guide to building accessible products — from foundational principles to practical implementation.

What Is Accessibility in Design?

Accessibility in design means creating products, interfaces, and experiences that everyone can use — regardless of ability, disability, age, device, or environment.

The four core principles come from the Web Content Accessibility Guidelines (WCAG) and they spell out a framework every designer and developer should internalize:

🔑 Remember POUR. Perceivable, Operable, Understandable, Robust. If your design fails any one of these four, it fails accessibility.

The Types of Disability You Are Designing For

Accessibility is broader than most designers realize. You are not just designing for one type of user — you are designing for a wide spectrum of permanent, temporary, and situational needs.

Visual disabilities:

• Blindness or low vision

• Color blindness affecting 8% of men and 0.5% of women

• Light sensitivity and contrast sensitivity

Auditory disabilities:

• Deafness or hard of hearing

• Auditory processing disorders

Motor disabilities:

• Limited fine motor control

• Paralysis or limb differences

• Tremors affecting mouse precision

Cognitive disabilities:

• Dyslexia and reading disorders

• ADHD and attention difficulties

• Memory and processing challenges

Situational disabilities:

• Broken arm making mouse use impossible

• Bright sunlight washing out your screen

• Noisy environment making audio unusable

• Slow internet making heavy pages inaccessible

💡 Situational disabilities matter. When you design for permanent disability, you solve problems for temporary and situational disability too. This is called the Curb Cut Effect — solutions built for wheelchairs benefit parents with strollers, delivery workers, and travelers with luggage.

Section 1: Color and Contrast

Color is the first place most designs fail accessibility. Here is what to get right.

Contrast Ratios

WCAG defines minimum contrast ratios between text and background:

✅ Tool to use: Paste your hex colors into the WebAIM Contrast Checker at webaim.org/resources/contrastchecker and verify before shipping.

Never Use Color Alone to Convey Meaning

This is the most common accessibility mistake in UI design.

Inaccessible approach:

• A green dot means online, a red dot means offline

• Required form fields are marked only in red

• A chart uses only color to distinguish data series

Accessible approach:

• Green dot with label "Online", red dot with label "Offline"

• Required fields marked with a red asterisk AND the word "Required"

• A chart uses color AND different line patterns AND a legend with labels

⚠️ Test: Print your design in grayscale. If it still makes sense, you are on the right track.

Color Blindness Considerations

The most common types:

• Deuteranopia: cannot distinguish red from green (most common)

• Protanopia: reduced sensitivity to red light

• Tritanopia: cannot distinguish blue from yellow (rare)

Design rules:

• Never use red and green as the only distinguishing colors

• Use blue and orange as a safer high-contrast alternative pair

• Always pair color with shape, pattern, or label

Section 2: Typography and Readability

Readable type is accessible type. These are the rules that matter most.

Font size minimums:

• Body text: never below 16px on screen

• Supporting text: never below 12px

• Mobile body text: 16px minimum, 18px preferred

Line height and spacing:

• Line height: at least 1.5x the font size for body text

• Paragraph spacing: at least 2x the font size between paragraphs

• Letter spacing: at least 0.12x the font size

• Word spacing: at least 0.16x the font size

Font choice:

• Use fonts with clear distinction between similar characters like I, l, and 1

• Avoid decorative or script fonts for body text

• Sans-serif fonts are generally more readable on screen

• Never use all-caps for body text or long passages

💡 Dyslexia note: Fonts with slightly irregular letterforms actually help some dyslexic readers by making each letter more distinguishable. OpenDyslexic is purpose-built for this. Standard clean sans-serifs like Atkinson Hyperlegible are designed with accessibility as the primary goal.

Text alignment:

• Left-align body text always

• Never justify text on screen — the uneven word spacing it creates disrupts reading flow for users with dyslexia and cognitive disabilities

• Center-align only for short headings and display text

Section 3: Keyboard and Focus Navigation

10% of users navigate primarily by keyboard. This includes screen reader users, motor-impaired users, and power users who simply prefer not to use a mouse.

The Golden Rules of Keyboard Accessibility

1. Every interactive element must be reachable by Tab key

2. Every interactive element must be operable by keyboard alone

3. Focus must always be visible — never hide it

4. Focus order must follow a logical reading sequence

5. No keyboard traps — users must always be able to tab out

Focus Indicators

The default browser focus ring is often removed by designers because it looks ugly. This is a critical accessibility failure.

Never do this:

* { outline: none; }
button:focus { outline: none; }

Do this instead — a beautiful AND accessible focus style:

button:focus-visible {
  outline: 3px solid #0066CC;
  outline-offset: 3px;
  border-radius: 4px;
}

✅ Use :focus-visible instead of :focus to show focus rings only for keyboard users, not mouse users. Best of both worlds.

Skip Navigation Links

Long navigation menus force keyboard users to tab through every single link before reaching main content. A skip link solves this instantly.

<a href="#main-content" class="skip-link">
  Skip to main content
</a>

.skip-link {
  position: absolute;
  top: -100%;
  left: 0;
}

.skip-link:focus {
  top: 0;
}

🔑 Skip links are invisible until focused — they appear when a keyboard user presses Tab as their very first action on the page.

Section 4: Images and Alt Text

Every image needs a decision: does it convey meaning, or is it decorative?

Meaningful images need descriptive alt text:

<img src="chart.png" alt="Bar chart showing 40% increase in user signups from January to March 2026" />

Decorative images need empty alt text so screen readers skip them:

<img src="divider-swoosh.png" alt="" role="presentation" />

Writing good alt text:

• Describe what the image communicates, not just what it shows

• Keep it under 125 characters when possible

• Do not start with "Image of" or "Photo of" — screen readers already announce it is an image

• For charts and graphs, describe the key insight, not every data point

• For infographics with complex data, provide a longer text alternative nearby

Section 5: Forms and Input Accessibility

Forms are where accessibility failures cause the most real-world harm — people cannot sign up, cannot check out, cannot contact you.

Every input must have a visible label:

<label for="email">Email address</label>
<input type="email" id="email" name="email" />

Never use placeholder text as a label:

<input type="email" placeholder="Email address" />

Placeholder text disappears when the user starts typing, leaving them with no memory of what the field requires. It also fails contrast requirements in most browsers by default.

Error messages must be specific and helpful:

Inaccessible error: "Invalid input"

Accessible error: "Please enter a valid email address in the format name@example.com"

Form accessibility checklist:

• Every input has a visible, persistent label

• Required fields are clearly marked with text, not just color

• Error messages are specific and explain how to fix the problem

• Error messages are linked to the input they describe using aria-describedby

• Success confirmation is announced to screen readers

• Autocomplete attributes are set where relevant

Section 6: Touch and Mobile Accessibility

Touch target sizes:

• Minimum touch target: 44x44 pixels per Apple HIG and WCAG 2.5.5

• Recommended touch target: 48x48 pixels

• Minimum spacing between adjacent targets: 8px

⚠️ Small touch targets are an accessibility failure AND a usability failure. If your mobile users are mis-tapping buttons, your targets are too small.

Mobile accessibility rules:

• Support both portrait and landscape orientations — never lock to one

• Do not rely on complex gestures for core functionality

• Provide alternatives to swipe-only interactions

• Ensure pinch-to-zoom is never disabled in your viewport meta tag

Never do this:

<meta name="viewport" content="width=device-width, user-scalable=no" />

This prevents users with low vision from zooming in to read your content. It is both an accessibility failure and a WCAG violation.

Section 7: Screen Readers and Semantic HTML

The single most impactful thing you can do for screen reader accessibility is use semantic HTML correctly. Semantic elements tell screen readers what things are, not just what they look like.

Semantic HTML vs div soup:

Inaccessible:

<div class="header">
  <div class="nav">
    <div class="nav-item" onclick="go()">Home</div>
  </div>
</div>
<div class="main-content">
  <div class="article-title">My Post</div>
</div>

Accessible:

<header>
  <nav>
    <a href="/">Home</a>
  </nav>
</header>
<main>
  <article>
    <h1>My Post</h1>
  </article>
</main>

Heading hierarchy matters:

• One H1 per page — the main page title

• H2 for major sections

• H3 for subsections within H2 sections

• Never skip heading levels for visual styling reasons

• Never use headings just to make text bigger — use CSS for that

ARIA landmarks for navigation:

<header role="banner">
<nav role="navigation">
<main role="main">
<aside role="complementary">
<footer role="contentinfo">

💡 ARIA rule of thumb: The first rule of ARIA is to not use ARIA if a native HTML element already does the job. Native semantic HTML is always preferable to ARIA roles bolted onto divs.

Section 8: Video and Audio Accessibility

For all video content:

• Captions for all spoken dialogue and meaningful sound

• Audio description track for visual information not conveyed in dialogue

• Transcript available for all video and audio content

• Media player controls accessible by keyboard

Caption quality standards:

• Captions must be accurate — auto-generated captions alone are not sufficient

• Identify speakers when multiple people are speaking

• Include relevant non-speech sounds in brackets like [applause] or [door slams]

• Caption timing must sync with the audio

✅ Captions benefit far more than deaf users. 80% of people who use captions are not deaf or hard of hearing. They use captions in noisy environments, to improve comprehension, or because they process text faster than audio.

The Accessibility Audit Checklist

Use this before every major release:

Visual:

• Color contrast passes WCAG AA minimum ratios

• Color is never the only means of conveying information

• Text resizes up to 200% without loss of content or functionality

• Focus indicators are visible and clear

Content:

• All images have appropriate alt text

• Heading hierarchy is logical and sequential

• Link text is descriptive — no "click here" or "read more" alone

• Language of the page is declared in the HTML lang attribute

Interaction:

• All functionality is operable by keyboard alone

• No keyboard traps exist anywhere in the interface

• Skip navigation link is present

• Touch targets are at least 44x44 pixels

Forms:

• All inputs have visible persistent labels

• Error messages are specific, helpful, and linked to inputs

• Required fields are clearly identified

Media:

• All videos have accurate captions

• All audio has a transcript

• No content flashes more than 3 times per second

WCAG Compliance Levels Explained

🔑 Target WCAG 2.2 AA as your baseline minimum. This is the legal requirement in the EU under EN 301 549, in the US for federal websites under Section 508, and the standard referenced in most accessibility lawsuits.

Tools Every Accessibility Designer Needs

Testing and auditing:

• axe DevTools browser extension for automated accessibility testing

• WAVE by WebAIM for visual accessibility reporting

• Lighthouse in Chrome DevTools for accessibility scoring

• Color Contrast Analyzer desktop app for offline contrast checking

Screen reader testing:

• NVDA on Windows — free, widely used

• VoiceOver on Mac and iOS — built in, no install needed

• TalkBack on Android — built in

• JAWS on Windows — industry standard, paid

Design tools:

• Stark plugin for Figma for contrast and simulation checking

• Able plugin for Figma for color blindness simulation

• Microsoft Accessibility Insights for detailed component testing

The Business Case for Accessibility

If the moral case is not enough, the business case absolutely is.

💡 Accessibility and SEO are deeply aligned. Alt text, semantic HTML, logical heading structure, descriptive link text — every accessibility best practice is also an SEO best practice.

Conclusion

Accessibility is not a feature you add at the end. It is a quality standard you build into every decision from the very beginning.

The core principles to carry forward:

• Design for the full spectrum of human ability, not just the average user

• Use semantic HTML as your foundation — it does more heavy lifting than any ARIA attribute

• Never use color as the only way to convey information

• Always provide keyboard access to every interaction

• Test with real assistive technology, not just automated tools

• Treat accessibility audits as a regular part of your release process

Accessibility is someone else's problem. Accessibility is every designer's responsibility, every developer's responsibility, and every product manager's responsibility.

The most powerful thing you can build is something that genuinely works for everyone.