Accessibility Checklist for Web Designers

Accessibility isn’t a feature you add later. It’s not a checkbox to tick before launch. It’s a fundamental part of design that determines whether 15-20% of your users can actually use your product.

That’s not a niche concern. That’s one in five people. In your family. On your commute. In your user base.

If your checkout flow doesn’t work for someone using a screen reader, you’ve excluded them completely. If your color scheme makes your site unreadable for someone with low vision, you’ve lost them. These aren’t edge cases—they’re real users with real money to spend.

This checklist gives you a practical roadmap to build sites that work for everyone. No theory, no excuses. Just what to do and how to do it.

:::note[TL;DR]

WCAG 2.2 AA is the standard target for most websites—aim here first
Color contrast must be at least 4.5:1 for normal text, 3:1 for large text
Keyboard navigation must be complete and logical—every action must be accessible without a mouse
Alt text is required for every meaningful image—describe content, not “image”
Focus states must be visible—don’t remove outline and leave nothing
Form labels must be programmatically connected to inputs—placeholders don’t count
Motion must be pauseable—never auto-play animations that can’t be stopped :::

Why Accessibility Matters

The Business Case

Accessible design isn’t charity. It’s good business.

The global disability market has $8 trillion in annual disposable income. That’s not a small segment—it’s a massive market you’re ignoring if your site excludes users with disabilities.

Beyond the direct market:

Legal protection. ADA lawsuits increased 50% from 2020 to 2023. Courts have ruled that inaccessible websites violate the Americans with Disabilities Act. Do you want to explain to your client why they got sued?
SEO benefits. Accessibility improvements overlap heavily with SEO. Semantic HTML, proper heading structure, alt text—these help search engines index your content. You’re optimizing for humans and algorithms simultaneously.
Better design for everyone. Curb cuts were designed for wheelchair users. Everyone uses them now. Accessible design improves usability for all users, not just those with disabilities.

Real example: The BBC’s accessible redesign reduced cognitive load for all users, not just those with cognitive disabilities. Task completion improved across the board. Accessibility made their product better for everyone.

The Ethical Case

The business case matters. But let’s be clear: some things are right because they’re right.

People with disabilities deserve equal access to information, services, and experiences. When you build an inaccessible site, you’re telling millions of users that your product doesn’t include them. That their time, their money, their needs don’t matter.

This isn’t about pity or charity. It’s about basic fairness. If your product works for someone without disabilities, it should work for someone with them. That’s not optional.

WCAG Guidelines Overview

The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility. Published by the W3C, they’re your roadmap to building accessible sites.

The Four Principles: POUR

Every WCAG guideline falls under one of four principles:

Perceivable — Information must be presentable to users in ways they can perceive. If someone can’t see, they need an alternative (alt text, captions).
Operable — Interface components must be operable. If someone can’t use a mouse, they need keyboard access.
Understandable — Information and UI operation must be understandable. Clear language, predictable behavior, error guidance.
Robust — Content must be robust enough for assistive technologies to interpret. Valid HTML, proper semantics.

Conformance Levels: A, AA, AAA

WCAG defines three levels of conformance:

Level	What It Means	Your Target
A	Minimum. Blocks access for some users.	Fix immediately
AA	Standard. Legal requirement in most jurisdictions.	Your baseline
AAA	Enhanced. Not always achievable for all content.	Aspirational

AA is your target. It’s what laws reference. It’s what audits check. It’s where you should be before launch.

Real example: A major airline was sued because their booking site was completely unusable with a screen reader. They had to pay damages and rebuild the entire booking flow. Fixing it during design would have cost $50,000. The lawsuit cost millions.

What’s New in WCAG 2.2

WCAG 2.2, finalized in late 2023, adds several new criteria worth knowing:

Dragging Movements (Level A): If your interface uses drag-and-drop, you must provide an alternative. Not everyone can drag—give them click alternatives.
Focus Appearance (Level AA): The visible focus indicator must be at least as large as a 2px border around the component. No more hidden focus states.
Target Size (Enhanced): Previous guidelines recommended 44x44px. WCAG 2.2 makes the 24x24px threshold explicit for adjacent targets—give users breathing room.
Animation from Interactions: If content animates based on user interaction (like expanding accordions), users should be able to disable it via prefers-reduced-motion.

Your takeaway: If you’re already hitting WCAG AA, checking these new criteria keeps you ahead of the curve. Most apply to specific interaction patterns—not blanket requirements.

Visual Accessibility

Color Contrast

Color contrast isn’t optional. Low contrast text excludes users with low vision, color blindness, and anyone viewing in bright sunlight or on a dirty screen.

Minimum contrast ratios (WCAG AA):

Normal text: 4.5:1 against background
Large text (18pt or 14pt bold): 3:1 against background
UI components and graphical objects: 3:1 against adjacent colors

How to check:

Use browser dev tools (Chrome’s accessibility panel)
Use contrast checkers (WebAIM, Coolors, or Figma’s contrast checker)
Test in context—check every text color combination used in your design

Common failures:

Gray text on white backgrounds
Blue links on white backgrounds (barely passes at 2.9:1)
Text over complex backgrounds without solid fallbacks

Example failure: WhatsApp’s dark mode initially used #333333 on #121212—a contrast ratio of 2.5:1. Below AA standards. Users with low vision couldn’t read messages. They eventually fixed it to pass AA.

Color as Information

Never use color as the only way to convey information. This excludes users with color blindness (approximately 8% of men, 0.5% of women).

Wrong:

“Required fields are marked in red”
“Green means success, red means error”
“Click the highlighted option”

Right:

Required fields have labels AND indicators (“Name (required)”)
Error states have icons AND color AND text
Interactive elements have underlines, borders, or other non-color indicators

Real example: An airline booking system used red/green color coding for seat availability. Users with red-green color blindness couldn’t determine which seats were available. They added seat status icons (filled circle vs empty circle) alongside color. Everyone could use it.

Text Size and Scaling

Your design must work when users zoom to 200% without horizontal scrolling. This helps users with:

Low vision who need larger text
Motor impairments who have difficulty with precise mouse movements
Anyone who prefers larger text for comfort

Design rules:

Use relative units (rem, em) for font sizes, not pixels
Ensure layouts reflow at larger text sizes
Don’t fix text containers at pixel widths
Test at 200% zoom in your browser before shipping

Real example: A banking app’s transaction list broke at 150% zoom. The date column pushed below the transaction amount. Users with low vision had to scroll horizontally to see full transactions. They rebuilt the layout to reflow properly.

Every function available by mouse must be available by keyboard. This is non-negotiable for users who:

Have motor impairments preventing mouse use
Use keyboard alternatives for efficiency
Navigate with switch controls or eye-tracking
Use screen readers (which often use keyboard navigation)

Focus Management

The focus indicator must be visible. When you tab through a page, you must always know where you are.

Requirements:

Never remove focus outlines without replacement
Focus outline must have sufficient contrast (3:1 against adjacent colors)
Focus order must follow visual/logical order
Focus must move to modals when opened and return to trigger when closed

Common failures:

outline: none with no replacement
Focus jumping around the page unpredictably
Modal focus not trapped inside the modal
Focus disappearing after dynamic content loads

Code pattern:

/* Don't do this */
:focus {
  outline: none;
}

/* Do this instead */
:focus {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

Tab Order

Tab order must follow reading order (left to right, top to bottom in LTR languages). This is natural in most cases, but breaks with:

CSS positioning that moves things visually
Hidden elements that are still in tab order
Complex grid layouts

Design rules:

Don’t use tabindex values greater than 0
Keep tab order logical without manipulation
Test by tabbing through your entire interface
Ensure all interactive elements are reachable

Real example: An e-commerce checkout had the “Continue” button placed visually at the bottom but positioned with CSS above other elements. Tab order followed the DOM, not visual layout. Users tabbing through had the button appear early, then see new content load, then have focus jump around. Confusing and inaccessible.

Screen readers convert visual content to speech. They’re used by blind users, users with reading difficulties, and sometimes users who just prefer audio. Making your site work with screen readers requires understanding how they work.

Semantic HTML

Screen readers identify elements by their HTML tags. A <button> is announced as a button. A <nav> is announced as navigation. A <h1> is announced as heading level 1.

Use the right element for the job:

<button> for actions
<a> for links
<nav> for navigation regions
<main> for main content
<h1> through <h6> for headings (don’t skip levels)

Wrong:

<div onclick="submit()">Submit</div>

Right:

<button type="submit">Submit</button>

Alt Text

Every image that conveys information needs alt text. Alt text is read by screen readers and displayed when images don’t load.

Rules:

Write alt text that conveys the same information as the image
Keep it concise (under 125 characters)
Don’t start with “Image of” or “Picture of”—screen readers already say that
Mark decorative images with empty alt (alt="")

Examples:

Image	Bad Alt	Good Alt
Photo of happy team	”image"	"Team members celebrating project launch”
Chart showing growth	”chart"	"Bar chart showing 40% revenue growth in Q3 2025”
Decorative divider	”decorative divider”	`alt=""`
Company logo	”logo"	"Acme Corporation, return to homepage”

ARIA When HTML Isn’t Enough

ARIA (Accessible Rich Internet Applications) adds accessibility information to custom components. Use it only when HTML semantics aren’t sufficient.

When to use ARIA:

Custom interactive widgets without native HTML elements
Live regions that update without page reloads
Enhanced descriptions beyond native labels

When NOT to use ARIA:

When native HTML provides the semantics you need (just use the native element)
When ARIA conflicts with native behavior
As a band-aid for bad HTML structure

Real example: A custom dropdown menu was built with <div> elements. It needed extensive ARIA: role="listbox", role="option", aria-expanded, aria-selected. A native <select> would have provided all this for free. They rebuilt it with proper HTML and the screen reader experience improved dramatically.

Forms and Input Accessibility

Forms are where accessibility most often breaks down. Users with screen readers, motor impairments, and cognitive disabilities struggle with poorly built forms.

Label Association

Every form input must have a visible label programmatically associated with it.

Wrong approaches:

Placeholder text as the only label
Labels placed visually but not associated in code
Labels that describe the field but aren’t connected to it

Right approach:

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

For complex forms with hints:

<label for="password">Password</label>
<span id="password-hint">Must be at least 8 characters</span>
<input type="password" id="password" name="password" aria-describedby="password-hint" />

Error Handling

Error messages must be:

Announced to screen readers (use aria-live regions)
Visible and text-based (not just color changes)
Specific about what’s wrong and how to fix it
Associated with the relevant field

Wrong approach:

Red text below the field with no connection to the input
“Invalid input” with no explanation
Color change only

Right approach:

<label for="email">Email</label>
<input type="email" id="email" aria-invalid="true" aria-describedby="email-error" />
<span id="email-error" role="alert">Please enter a valid email address (e.g., name@example.com)</span>

Required Fields

Mark required fields clearly:

Use the word “required” in the label (not just an asterisk without explanation)
Use aria-required="true" on the input
Don’t rely on color alone (asterisk is often red)

Example:

<label for="name">
  Full name <span class="required-indicator">(required)</span>
</label>
<input type="text" id="name" required aria-required="true" />

Real example: A government benefits form marked required fields with red asterisks. Users with red-green color blindness couldn’t see them. Users with screen readers weren’t told fields were required until they submitted and got errors. They added “(required)” text to labels and used aria-required. Form completion rates improved.

Media Accessibility

Images

Beyond alt text (covered above), consider:

Complex images (charts, diagrams) need longer descriptions—use aria-describedby or a visible caption
Image maps must have text alternatives for each region
Infographics should have text alternatives or provide the data in text form

Video

Video accessibility requires:

Captions for deaf/hard-of-hearing users (auto-generated captions aren’t sufficient—review and fix them)
Audio descriptions for blind users (describe what’s happening on screen)
Transcripts for users who can’t watch video
Controls that are keyboard accessible and screen reader compatible

Captions minimum requirements:

Synchronized with audio
Identify speakers when multiple people speak
Include relevant sound effects [“[applause]”]
At minimum 99% accurate (auto-caption accuracy is often 70-85%)

Audio

Audio accessibility requires:

Transcripts for all audio content (podcasts, interviews, audio clips)
No auto-play—let users choose to play audio
Controls that are accessible (play, pause, volume, seek)

Real example: A podcast platform auto-played episodes when users opened the app. Screen reader users couldn’t stop playback because the controls weren’t keyboard accessible. Users with cognitive disabilities couldn’t understand what was happening. The auto-play feature was removed and replaced with an explicit “Play latest episode” button.

Motion and Animation

Motion can cause serious problems:

Vestibular disorders: Animation can trigger nausea, dizziness, and headaches
Attention disorders: Moving elements can cause severe distraction
Seizures: Flashing content above 3 flashes per second can trigger photosensitive seizures

Respect User Preferences

/* Check for reduced motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

This CSS ensures users who’ve set “Reduce motion” in their OS get a static experience instead of animations.

Design Rules

No auto-playing animations that loop more than 3 times
No flashing content that flashes more than 3 times per second
Provide pause controls for any animation that plays automatically
Never use motion to convey critical information—supplement with text
Keep animations subtle—they should enhance, not distract

Real example: A gaming website had animated ads with rapidly flashing elements. Several users reported motion sickness. One user with photosensitive epilepsy had a seizure. The site had to remove the ads entirely and rebuild their ad system with motion restrictions. The lawsuit could have been avoided with proper design choices.

Quick Audit Checklist

Use this checklist before every launch. Mark each item as pass/fail/not applicable.

Structure and Semantics

Heading hierarchy is logical (h1 → h2 → h3, no skipped levels)
Every page has exactly one h1
Navigation is wrapped in <nav> with accessible label if multiple navs exist
Main content is wrapped in <main>
Landmarks are used correctly (header, nav, main, footer, aside)

Color and Contrast

All body text meets 4.5:1 contrast ratio
All large text meets 3:1 contrast ratio
Color is never the only indicator of meaning
Interactive elements have 3:1 contrast against adjacent colors
Tested with browser contrast checker tool

Tab order follows logical reading order
Focus is always visible (no outline: none without replacement)
All interactive elements are reachable by Tab
Modal focus is trapped within the modal
Focus returns to trigger when modal closes
Skip link is provided to bypass navigation

Images and Media

All meaningful images have descriptive alt text
Decorative images have empty alt (alt="")
Complex images have extended descriptions
Video has captions
Audio has transcripts
No content relies solely on sensory characteristics

Forms

Every input has an associated visible label
Error messages are programmatically associated with inputs
Required fields are marked visually and with aria-required
Error messages are specific and helpful
Form has proper autocomplete attributes where applicable

Motion

No content flashes more than 3 times per second
Animations respect prefers-reduced-motion
Auto-playing media can be paused/stopped
Essential information is not conveyed through motion alone

Testing

Tested with screen reader (NVDA, VoiceOver, or browser-based)
Tested with keyboard only
Tested at 200% zoom
Tested with high contrast mode
No accessibility errors in automated scan (Axe, WAVE, Lighthouse)

FAQ

What’s the difference between WCAG A, AA, and AAA?

A is the minimum—you’re blocking access for some users without it. AA is the standard that most laws and regulations reference. AAA is enhanced accessibility that’s not always achievable for all content types. Target AA for compliance, use AAA as an aspirational goal.

Do I need to test with actual disabled users?

Automated tools catch about 30% of accessibility issues. For the other 70%, you need human testing—including users with disabilities. At minimum, test with screen readers and keyboard-only navigation yourself. For major projects, include users with disabilities in your testing.

How do I make a business case for accessibility?

Start with the numbers: 15-20% of users have disabilities, that’s trillions in purchasing power. Add legal risk: ADA lawsuits are increasing every year. Then mention SEO benefits and improved usability for all users. Concrete example: Target paid $6 million in a settlement and spent millions rebuilding their accessible site. Building it right the first time costs a fraction of that.

Can I use automated tools alone for accessibility testing?

No. Automated tools check technical compliance (contrast ratios, alt text presence, semantic structure) but can’t evaluate whether your design actually works for users. They miss: whether your form flow makes sense, whether your error messages are helpful, whether your navigation is intuitive, whether your content is understandable. Use automation to find technical issues, then do human testing for usability issues.

What if my client won’t pay for accessibility work?

Explain the legal risk. Document your recommendation in writing (email, project notes). Get sign-off that they declined accessibility work. Offer a reduced scope that hits the minimum AA requirements. If they still refuse, consider whether you want to be associated with an inaccessible product that could harm users and expose them to lawsuits.

Summary

Accessibility is a legal requirement, not a nice-to-have. WCAG AA is the standard.
Color contrast is measurable and testable. 4.5:1 for body text. Check every combination.
Keyboard navigation is mandatory. Every mouse action must have a keyboard equivalent.
Screen readers depend on semantic HTML. Use the right element for every purpose.
Forms break more than any other component. Associate labels, handle errors properly, mark required fields clearly.
Motion causes real harm. Respect prefers-reduced-motion and avoid flashing content.
Automated testing catches ~30% of issues. You need human testing to find the rest.
Accessibility improves usability for everyone. Better contrast helps in sunlight. Keyboard navigation is faster for power users. Clearer error messages help everyone.

Build accessible sites because it’s the right thing to do. You’ll also avoid lawsuits, improve SEO, and create better products for all users. There’s no downside.