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.

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:

1. Perceivable — Information must be presentable to users in ways they can perceive. If someone can’t see, they need an alternative (alt text, captions).
2. Operable — Interface components must be operable. If someone can’t use a mouse, they need keyboard access.
3. Understandable — Information and UI operation must be understandable. Clear language, predictable behavior, error guidance.
4. 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:

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.

Keyboard Navigation

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 Reader Compatibility

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:

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

Keyboard Navigation

• 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.

What to Read Next

• 20 UX Terms Every Designer Should Know — Build the vocabulary foundation for every design discussion
• Usability Testing: A Complete Guide — Learn how to validate your accessible designs with real users

Related Articles

Deepen your understanding with these curated continuations.

View All Articles

UX 5 min read

User Research Methods Every UX Designer Should Know

Discover essential user research methods for UX designers. Learn when to use interviews, surveys, usability tests, and more to understand your users.

Aayushi Gajjar Jan 25, 2026

UX 5 min read

Usability Testing: A Complete Guide

Learn how to conduct usability testing with real users. Step-by-step guide covering methods, metrics, and how to derive actionable insights from tests.

Aayushi Gajjar Jan 15, 2026

UX 5 min read

10 Essential UX Laws Every Designer Should Know

Master the foundational rules of UX design, including Fitts's Law, Hick's Law, and Miller's Law. Improve your product's usability with these key principles.

Aayushi Gajjar Dec 21, 2025