Web Accessibility Testing Guide: WCAG 2.1 Compliance Checklist

Why Accessibility Testing Matters

Web accessibility ensures that people with disabilities can perceive, understand, navigate, and interact with websites. According to the WHO, over 1 billion people -- about 16% of the global population -- live with some form of disability. Beyond the moral imperative, accessibility is increasingly a legal requirement: ADA lawsuits against websites exceeded 4,600 in 2023, and the European Accessibility Act takes full effect in 2025.

Accessible websites also benefit everyone. Captions help users in noisy environments. High contrast benefits users in bright sunlight. Keyboard navigation is faster for power users. Good semantic HTML improves SEO because search engines parse the same structure that screen readers use.

This guide covers the WCAG 2.1 standard, testing methodologies (automated and manual), essential ARIA patterns, and a practical checklist you can apply to any web project.

WCAG 2.1 Conformance Levels Explained

WCAG organizes its success criteria into three conformance levels. Each level builds on the previous one, adding stricter requirements.

Most organizations target WCAG 2.1 Level AA, which covers the majority of accessibility needs. The four foundational principles (POUR) organize all criteria: content must be Perceivable, Operable, Understandable, and Robust.

Automated Testing Tools

Automated tools catch approximately 30-40% of WCAG issues. They excel at structural checks but cannot evaluate subjective quality (like whether alt text is meaningful). Use them as a first pass, never as the only testing method.

// axe-core in Playwright tests
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('homepage passes axe accessibility checks', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
    .analyze();

  expect(results.violations).toEqual([]);
});

// Jest + React Testing Library
import { render } from '@testing-library/react';
import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);

test('form has no a11y violations', async () => {
  const { container } = render(<LoginForm />);
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

Manual Testing Techniques

Manual testing catches the 60-70% of issues that automated tools miss. Focus on these core techniques:

Keyboard Navigation Testing

Every interactive element must be reachable and operable with keyboard alone. Test these key interactions:

Screen Reader Testing

Test with at least one screen reader. NVDA (Windows, free) and VoiceOver (macOS, built-in) are the most common. Verify that headings create a logical outline, images have descriptive alt text, form fields have associated labels, and dynamic content changes are announced.

Color Contrast Requirements

Insufficient color contrast is the single most common accessibility issue on the web. WCAG defines specific contrast ratio thresholds based on text size and conformance level.

Use BytePane's Color Converter to check contrast ratios between any two colors, or use browser DevTools which shows contrast ratio in the color picker.

ARIA Roles, States, and Properties

ARIA (Accessible Rich Internet Applications) adds semantic information to HTML elements that screen readers use to describe the UI. The first rule of ARIA: do not use ARIA if a native HTML element provides the same semantics.

<!-- BAD: Using ARIA when native HTML works -->
<div role="button" tabindex="0" onclick="submit()">Submit</div>

<!-- GOOD: Native HTML button -->
<button type="submit">Submit</button>

<!-- BAD: ARIA checkbox -->
<div role="checkbox" aria-checked="false" tabindex="0">
  Accept terms
</div>

<!-- GOOD: Native checkbox -->
<label>
  <input type="checkbox" name="terms" />
  Accept terms
</label>

When you must use ARIA (for custom widgets with no HTML equivalent), follow these essential patterns:

<!-- Tab component -->
<div role="tablist" aria-label="Settings sections">
  <button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1">
    General
  </button>
  <button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2">
    Security
  </button>
</div>
<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
  General settings content...
</div>

<!-- Live regions for dynamic content -->
<div aria-live="polite" aria-atomic="true">
  3 results found
</div>

<!-- Modal dialog -->
<div role="dialog" aria-modal="true" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Confirm deletion</h2>
  <p>This action cannot be undone.</p>
  <button>Cancel</button>
  <button>Delete</button>
</div>

Semantic HTML Checklist

Proper semantic HTML eliminates the need for most ARIA attributes. Screen readers and search engines rely on HTML semantics to understand page structure.

Common Accessibility Issues and Fixes

1. Missing or Empty Alt Text

<!-- Decorative image: use empty alt -->
<img src="divider.svg" alt="" role="presentation" />

<!-- Informative image: describe the content -->
<img src="chart.png" alt="Bar chart showing 40% increase in sales Q3 2025" />

<!-- Linked image: describe the destination -->
<a href="/dashboard/">
  <img src="logo.svg" alt="Return to dashboard" />
</a>

2. Missing Form Labels

<!-- BAD: no label association -->
<span>Email</span>
<input type="email" />

<!-- GOOD: explicit label -->
<label for="email">Email</label>
<input type="email" id="email" />

<!-- GOOD: implicit label (wrapping) -->
<label>
  Email
  <input type="email" />
</label>

<!-- For visually hidden labels -->
<label for="search" class="sr-only">Search</label>
<input type="search" id="search" placeholder="Search..." />

3. Focus Management in SPAs

// After route change, move focus to main content
useEffect(() => {
  const main = document.querySelector('main');
  if (main) {
    main.setAttribute('tabindex', '-1');
    main.focus();
    main.addEventListener('blur', () => {
      main.removeAttribute('tabindex');
    }, { once: true });
  }
}, [pathname]);

// Skip navigation link
<a href="#main-content" className="sr-only focus:not-sr-only
  focus:fixed focus:top-0 focus:left-0 focus:z-50
  focus:p-4 focus:bg-white focus:text-black">
  Skip to main content
</a>

WCAG 2.1 Quick-Reference Checklist

Use this checklist for every page or component you build. Items marked with asterisks (*) are the most commonly failed criteria.

Frequently Asked Questions

Related Articles