Complete Web Accessibility Compliance Checklist for Developers

A checklist simplifies the implementation of accessibility principles across your design process. It serves as a practical guide for your team, helping ensure all aspects of accessibility are considered and implemented effectively.

Enhance Your Website’s Accessibility

Are you ready to implement accessibility best practices for your website and digital content? Take a look at my quick start guide for accessibility – all the information you need is in one convenient location.

The legal landscape for web accessibility underwent historic changes in 2024 with the Department of Justice’s final rule requiring WCAG 2.1 AA compliance for state and local government websites. With 2,452 federal accessibility lawsuits filed in 2024 and the DOJ establishing WCAG 2.1 Level AA as the technical standard for ADA Title II compliance, accessibility is now a critical legal and business requirement. This comprehensive checklist provides developers with actionable requirements, testing methods, and compliance standards based on current ADA case law, Section 508 requirements, and WCAG 2.1 AA guidelines.

Legal compliance foundation

Current Legal Standards (2024-2025):

  • ADA Title II: WCAG 2.1 AA required by DOJ final rule (April 2024)
  • ADA Title III: No federal regulation, but WCAG 2.1 AA is de facto standard in litigation
  • Section 508: Currently WCAG 2.0 AA (agencies encouraged to adopt 2.1)
  • Litigation Risk: 41% of businesses sued multiple times; $25,000-$100,000+ in legal fees

Key Enforcement Updates:

  • State/local government compliance deadlines: April 2026 (50,000+ population) or April 2027 (smaller entities)
  • Accessibility widgets cited in 25% of 2024 lawsuits as inadequate solutions
  • FTC fined accessiBe $1M in January 2025 for false advertising claims

1. Visual design and typography

Color and contrast requirements

WCAG Success Criteria: 1.4.3 (Contrast Minimum), 1.4.11 (Non-text Contrast), 1.4.1 (Use of Color)

Technical Requirements:

ElementContrast Ratio
Normal text4.5:1 minimum contrast ratio
Large text (18pt/24px+ or 14pt/18.66px+ bold)3:1 minimum
UI components (buttons, form controls, focus indicators)3:1 minimum
Graphics (icons, charts, diagrams)3:1 minimum against adjacent colors

Implementation Checklist:

  • Test all text against background colors using WebAIM Contrast Checker
  • Verify UI component borders and backgrounds meet 3:1 ratio
  • Ensure focus indicators have 3:1 contrast against adjacent colors
  • Use multiple indicators (color + icon/text) for important information
  • Test with Colour Contrast Analyser for visual impairment simulations
CSS

Compliant color implementation

/* Compliant color implementation */
:root {
  --text-primary: #212529; /* 4.5:1 on white */
  --text-large: #495057; /* 3:1 on white for large text */
  --focus-indicator: #005fcc; /* High contrast focus */
}

.error {
  color: #d73502;
  border-left: 4px solid #d73502; /* Multiple indicators */
}
.error::before {
  content: "⚠ ";
  font-weight: bold;
}

Testing Methods

  • Use browser DevTools contrast ratio display
  • Test with TPGi Colour Contrast Analyser eyedropper tool
  • Verify in grayscale mode for color-blind users

Typography and text spacing

WCAG Success Criteria: 1.4.4 (Resize Text), 1.4.12 (Text Spacing), 1.4.5 (Images of Text)

Technical Requirements:

Font Sizes
Base font size16px minimum for body text
Resizable to 200%without horizontal scrolling or loss of functionality
Text spacing adaptabilityLine height: 1.5× font size minimum
Paragraph spacing: 2× font size minimum
Letter spacing: 0.12× font size minimum
Word spacing: 0.16× font size minimum

Implementation Checklist:

  • Use relative units (rem, em) instead of pixels for scalability
  • Avoid fixed heights that break with text spacing adjustments
  • Replace images of text with CSS-styled text where possible
  • Test text scaling to 200% zoom level
  • Verify layout accommodates user-defined text spacing
CSS

Scalable typography implementation

/* Scalable typography implementation */
body {
  font-size: 1rem; /* 16px base, user-scalable */
  line-height: 1.5;
}

/* Flexible containers for text spacing */
.content {
  min-height: 50px; /* Use min-height, not height */
  word-spacing: 0.16em;
  letter-spacing: 0.12em;
}

h1 { font-size: 2rem; } /* 32px, scales with user preferences */

Responsive design and reflow

WCAG Success Criteria: 1.4.10 (Reflow), 1.3.4 (Orientation), 1.4.13 (Content on Hover or Focus)

Technical Requirements:

Reflow
320px widthsupport without horizontal scrolling (400% zoom at 1280px)
Portrait and landscapeorientation support (exceptions: games, maps)
Hover/focus contentmust be dismissible, hoverable, and persistent

Implementation Checklist:

  • Test reflow at 320px viewport width
  • Verify no content loss at 400% zoom level
  • Ensure touch targets minimum 44×44 CSS pixels (24×24 for WCAG 2.2)
  • Provide alternatives to orientation-dependent content
  • Implement dismissible tooltips and hover content
CSS

Responsive reflow implementation

/* Responsive reflow implementation */
.container {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
  gap: 1rem;
}

/* Touch-friendly targets */
.button {
  min-height: 44px;
  min-width: 44px;
  padding: 12px 16px;
}

/* Accessible tooltips */
.tooltip {
  position: absolute;
  /* Allow pointer to hover over tooltip content */
}

2. Keyboard navigation and focus management

Core keyboard accessibility

WCAG Success Criteria: 2.1.1 (Keyboard), 2.1.2 (No Keyboard Trap), 2.4.3 (Focus Order), 2.4.7 (Focus Visible)

Technical Requirements:

Focus management
All functionalityavailable via keyboard interface
Focus indicatorsvisible with 3:1 contrast ratio minimum
Logical tab orderfollowing visual presentation
No keyboard trapsusers can navigate away from all components

Implementation Checklist:

  • Test complete site navigation using only Tab, Shift+Tab, Enter, Space, Arrow keys, Escape
  • Verify all interactive elements respond to keyboard activation
  • Implement visible focus indicators for all focusable elements
  • Ensure custom components have proper keyboard event handlers
  • Test modal dialogs for focus trapping and escape functionality
HTML

Semantic HTML provides built-in keyboard support

<!-- Semantic HTML provides built-in keyboard support -->
<nav role="navigation" aria-label="Main navigation">
  <ul>
    <li><a href="/home">Home</a></li>
    <li><a href="/products">Products</a></li>
  </ul>
</nav>

<!-- Custom components need keyboard handling -->
<div role="button" tabindex="0" onclick="handleClick()" onkeydown="handleKeypress(event)">
  Custom Button
</div>

function handleKeypress(event) {
  if (event.key === 'Enter' || event.key === ' ') {
    event.preventDefault();
    handleClick();
  }
}

Advanced keyboard patterns

WCAG Success Criteria: 2.1.4 (Character Key Shortcuts), 2.5.1 (Pointer Gestures)

Implementation Checklist:

  • Implement skip links for bypassing repetitive content
  • Use roving tabindex for complex widgets (toolbars, data grids)
  • Provide keyboard alternatives for gesture-based interactions
  • Ensure single-character shortcuts can be disabled or remapped
  • Test arrow key navigation within grouped elements
CSS

High-contrast focus indicators

/* High-contrast focus indicators */
:focus {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

.skip-link {
  position: absolute;
  top: -40px;
  left: 6px;
  background: #000;
  color: #fff;
  padding: 8px;
  text-decoration: none;
  z-index: 1000;
}

.skip-link:focus {
  top: 6px;
}

3. Screen reader compatibility and ARIA

Semantic HTML foundation

WCAG Success Criteria: 1.3.1 (Info and Relationships), 4.1.2 (Name, Role, Value), 4.1.3 (Status Messages)

Implementation Checklist:

  • Use semantic HTML elements before adding ARIA
  • Implement proper heading hierarchy (single h1, logical h2-h6 structure)
  • Include landmark roles for page structure (banner, navigation, main, complementary, contentinfo)
  • Ensure all interactive elements have accessible names
  • Provide alternative text for all informative images
HTML

Proper semantic structure

<!-- Proper semantic structure -->
<header role="banner">
  <nav role="navigation" aria-label="Main">
    <ul>
      <li><a href="/">Home</a></li>
    </ul>
  </nav>
</header>

<main role="main">
  <h1>Page Title</h1>
  <section aria-labelledby="section-heading">
    <h2 id="section-heading">Section Title</h2>
  </section>
</main>

<aside role="complementary" aria-label="Related articles">
</aside>

<footer role="contentinfo">
</footer>

ARIA implementation patterns

Technical Requirements:

  • Labels: aria-label, aria-labelledby for accessible names
  • Descriptions: aria-describedby for additional context
  • Live regions: aria-live for dynamic content updates
  • States: aria-expanded, aria-selected, aria-checked for component states

Implementation Checklist:

  • Apply ARIA labels only when semantic HTML is insufficient
  • Use aria-live regions for dynamic content updates
  • Implement proper ARIA states for interactive components
  • Ensure ARIA references point to existing DOM elements
  • Test with NVDA (65.6% usage) and JAWS (60.5% usage) screen readers
HTML

Accessible dropdown menu

<!-- Accessible dropdown menu -->
<div class="dropdown">
  <button aria-expanded="false" aria-haspopup="true" id="menu-button">
    Options
  </button>
  <ul role="menu" aria-labelledby="menu-button" hidden>
    <li role="menuitem"><a href="#">Option 1</a></li>
    <li role="menuitem"><a href="#">Option 2</a></li>
  </ul>
</div>

<!-- Live regions for dynamic updates -->
<div aria-live="polite" id="status"></div>
<div role="alert" aria-live="assertive">Error: Please fix required fields</div>

<!-- Status messages -->
<div role="status">Form saved successfully</div>

Testing Methods:

  • Use NVDA screen reader (free) for development testing
  • Test with VoiceOver on macOS/iOS (70.6% mobile usage)
  • Verify ARIA announcements with screen reader testing tools
  • Use browser accessibility trees for debugging

4. Form accessibility

Form labels and structure

WCAG Success Criteria: 3.3.2 (Labels or Instructions), 1.3.5 (Identify Input Purpose), 4.1.2 (Name, Role, Value)

Technical Requirements:

  • Explicit labels for all form controls
  • Autocomplete attributes for user information fields
  • Fieldsets and legends for grouped form controls
  • Required field indication in text, not just visual cues

Implementation Checklist:

  • Associate all form inputs with explicit labels using for/id attributes
  • Group related fields with fieldset and legend elements
  • Include autocomplete attributes for personal information fields
  • Indicate required fields with text, not just asterisks or color
  • Provide clear instructions for form completion
HTML

Proper form labeling

<!-- Proper form labeling -->
<form>
  <fieldset>
    <legend>Contact Information</legend>
    
    <label for="name">Full Name (required)</label>
    <input type="text" id="name" name="name" required aria-required="true" autocomplete="name">
    
    <label for="email">Email Address (required)</label>
    <input type="email" id="email" name="email" required aria-describedby="email-desc" autocomplete="email">
    <div id="email-desc">We'll use this for order confirmations</div>
    
    <label for="phone">Phone Number</label>
    <input type="tel" id="phone" name="phone" autocomplete="tel">
  </fieldset>
</form>

Error handling and validation

WCAG Success Criteria: 3.3.1 (Error Identification), 3.3.3 (Error Suggestion), 3.3.4 (Error Prevention)

Implementation Checklist:

  • Provide clear, descriptive error messages in text
  • Link error messages to relevant form fields using aria-describedby
  • Use role=”alert” for error announcements to screen readers
  • Offer specific suggestions for fixing errors when possible
  • Implement error prevention for critical submissions (financial, legal, data)
HTML

Error summary at top of form

<!-- Error summary at top of form -->
<div role="alert" aria-live="assertive" class="error-summary">
  <h2>Please correct the following errors:</h2>
  <ul>
    <li><a href="#email">Email address is required</a></li>
    <li><a href="#password">Password must be at least 8 characters</a></li>
  </ul>
</div>

<!-- Inline error messages -->
<label for="email">Email Address</label>
<input type="email" id="email" aria-invalid="true" aria-describedby="email-error">
<div id="email-error" role="alert">Please enter a valid email address (example: user@domain.com)</div>

// Accessible real-time validation
function validateField(field) {
  const errorElement = document.getElementById(field.id + '-error');
  
  if (!field.validity.valid) {
    field.setAttribute('aria-invalid', 'true');
    errorElement.textContent = getErrorMessage(field);
    errorElement.setAttribute('role', 'alert');
  } else {
    field.setAttribute('aria-invalid', 'false');
    errorElement.textContent = '';
    errorElement.removeAttribute('role');
  }
}

4. Multimedia accessibility

Video and audio requirements

WCAG Success Criteria: 1.2.2 (Captions Prerecorded), 1.2.4 (Captions Live), 1.2.5 (Audio Description Prerecorded)

Technical Requirements:

  • Synchronized captions for all video content with speech
  • Audio descriptions for video with important visual information
  • Live captions for real-time video content
  • Transcripts for audio-only content

Implementation Checklist:

  • Provide WebVTT caption files for all video content
  • Include audio description tracks for videos with visual information
  • Ensure video players are keyboard accessible with proper ARIA labels
  • Offer transcript downloads for all multimedia content
  • Test caption synchronization and accuracy
HTML

Accessible video implementation

<!-- Accessible video implementation -->
<video controls>
  <source src="video.mp4" type="video/mp4">
  <track kind="captions" src="captions-en.vtt" srclang="en" label="English" default>
  <track kind="descriptions" src="descriptions-en.vtt" srclang="en" label="English Audio Descriptions">
  <p><a href="video-transcript.html">Read full transcript</a></p>
</video>

<!-- Audio content with transcript -->
<audio controls>
  <source src="podcast.mp3" type="audio/mpeg">
  <p><a href="podcast-transcript.html">Read full transcript</a></p>
</audio>

WebVTT Caption Format:

YAML

WEBVTT

00:00:11.000 --> 00:00:13.000
<v Presenter>Welcome to our accessibility guide.

00:00:13.000 --> 00:00:17.000
<v Presenter>Today we'll cover WCAG 2.2 requirements.

00:00:17.000 --> 00:00:20.000
<v Presenter>Let's start with visual design.

5. Testing methodology and tools

Automated testing integration

Current Tool Capabilities (2024-2025):

  • aXe-core: Detects 57% of issues, zero false positives, industry standard
  • WAVE: Best visual feedback, detected 7/8 test issues in comparative testing
  • Pa11y: Excellent CI/CD integration, command-line interface
  • Lighthouse: Built into Chrome DevTools, combines performance and accessibility

Implementation Checklist:

  • Integrate aXe-core into development workflow and CI/CD pipeline
  • Use WAVE browser extension for visual accessibility feedback
  • Set up automated testing with Pa11y in continuous integration
  • Configure accessibility testing thresholds and quality gates
  • Implement regular accessibility regression testing
YAML

GitHub Actions accessibility testing

# GitHub Actions accessibility testing
name: Accessibility Testing
on: [push, pull_request]
jobs:
  accessibility:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm install
      - run: npm install @axe-core/cli
      - run: axe --dir ./build --threshold 0

Manual testing procedures

Essential Manual Testing:

  • Keyboard navigation: Complete site traversal using only keyboard
  • Screen reader testing: NVDA (free), JAWS (enterprise), VoiceOver (mobile)
  • Color contrast verification: Manual checking with specialized tools
  • Zoom testing: 200% and 400% zoom levels without functionality loss

Testing Checklist:

  • Complete keyboard navigation test (Tab, Shift+Tab, Enter, Space, Arrow keys, Escape)
  • Screen reader testing with NVDA for DOM accuracy
  • Focus indicator visibility assessment across all interactive elements
  • Content reflow testing at 320px width and 400% zoom
  • Touch target sizing verification (44×44 CSS pixels minimum)

Screen Reader Testing Commands:

BASH

NVDA Commands

NVDA Commands:
- Insert + F6: Navigate by headings
- Insert + F7: Links list
- Insert + Space: Review mode toggle
- Tab: Navigate form controls

JAWS Commands:
- Insert + F6: Headings list
- Insert + F7: Links list
- Insert + F5: Form fields list
- Virtual cursor navigation

Compliance validation framework

Legal Compliance Verification:

  • WCAG 2.1 AA: All 50 success criteria met
  • Section 508: WCAG 2.0 AA minimum (upgrade to 2.1 recommended)
  • ADA Title II: WCAG 2.1 AA required for government entities
  • ADA Title III: WCAG 2.1 AA de facto standard for litigation protection

Documentation Requirements:

  • Maintain accessibility testing records
  • Document remediation efforts and timelines
  • Create accessibility policy and procedures
  • Establish user feedback channels for accessibility issues
  • Regular accessibility audits with third-party validation

Implementation priorities and best practices

Critical implementation priorities

Phase 1: Foundation (Must Fix First)

  1. Keyboard navigation (WCAG 2.1.1, 2.1.2) – core functionality access
  2. Color contrast (WCAG 1.4.3) – text readability for low vision users
  3. Alternative text (WCAG 1.1.1) – image accessibility for screen readers
  4. Form labels (WCAG 3.3.2) – form usability for all users

Phase 2: Core Accessibility

  1. Focus indicators (WCAG 2.4.7) – keyboard navigation visibility
  2. Error identification (WCAG 3.3.1) – form error communication
  3. Page structure (WCAG 1.3.1) – semantic HTML and heading hierarchy
  4. Skip navigation (WCAG 2.4.1) – bypass repetitive content

Phase 3: Enhanced Compliance

  1. WCAG 2.1 specific criteria: Reflow, Non-text Contrast, Text Spacing, Status Messages
  2. Mobile accessibility: Touch targets, orientation, pointer gestures
  3. Multimedia: Captions, audio descriptions, transcripts
  4. Advanced ARIA: Complex widgets, live regions, dynamic content

Common implementation pitfalls

Critical Mistakes to Avoid:

  • Over-reliance on overlay widgets (cited in 25% of 2024 lawsuits as inadequate)
  • Incorrect ARIA implementation causing more harm than good
  • Testing only with automated tools (only detects 30-57% of issues)
  • Ignoring keyboard users in favor of mouse/touch interactions
  • Using color alone to convey critical information
  • Creating keyboard traps in modal dialogs and complex widgets

Organizational compliance strategy

Legal Risk Management:

  • Prioritize WCAG 2.1 AA compliance as legal protection strategy
  • Document accessibility efforts for litigation defense
  • Establish ongoing monitoring and maintenance programs
  • Train development teams on accessibility requirements
  • Create vendor accessibility requirements for third-party services

Success Metrics:

  • Quantitative: WCAG 2.1 AA conformance percentage, issue remediation time
  • Qualitative: User feedback from people with disabilities, usability testing results
  • Process: Team accessibility knowledge, testing coverage, policy compliance

This comprehensive checklist provides developers with the technical requirements, testing methods, and compliance standards necessary to meet current American accessibility laws. With the DOJ’s 2024 final rule establishing WCAG 2.1 AA as the legal standard and continued high litigation activity, implementing these requirements is essential for legal compliance and inclusive user experiences.

Final Thoughts on Enhancing Accessibility

Ensuring that your website and digital content are accessible to all users is not just a best practice; it’s a responsibility. By applying the principles of clear communication, thoughtful design, and regular testing, you can create a digital experience that is inclusive of everyone, regardless of their abilities.

From using meaningful headings and descriptive link text to optimizing typography and image alt text, each aspect plays a critical role in enhancing usability. Moreover, understanding the importance of color contrast and inclusive language further reinforces your commitment to accessibility.

Remember, accessibility is an ongoing process. It requires regular updates and collaboration across teams to adapt to new content, features, and standards. By prioritizing accessibility in your design and content strategies, you not only comply with legal requirements but also foster a more enriching environment for all users. Together, let’s create digital spaces where everyone feels seen, heard, and included.

Last updated: August 7, 2025