Web Accessibility Checklist 2026: Complete WCAG Guide

Why Accessibility Matters (The Business Case)

Over one billion people worldwide live with some form of disability. That is roughly 16% of the global population. When your website is inaccessible, you are excluding a significant portion of potential users, customers, and contributors.

But accessibility is not just about ethics. It makes financial and legal sense. In the US alone, ADA-related web accessibility lawsuits exceeded 4,000 in 2025. The European Accessibility Act (EAA) went into effect in June 2025, requiring digital products and services across the EU to meet accessibility standards. Non-compliance carries real penalties.

Accessible sites also tend to perform better. Semantic markup improves SEO. Keyboard navigation benefits power users. Caption support helps people watching videos in noisy environments. Accessibility improvements benefit everyone, not just users with disabilities.

WCAG 2.2 Overview: Levels A, AA, AAA

WCAG 2.2 organizes its success criteria into three conformance levels:

Level	What It Means	When to Target
A	Minimum accessibility. Addresses the most severe barriers that prevent access entirely.	Absolute baseline. Every site should meet Level A.
AA	Reasonable accessibility. Addresses the most common barriers for the widest range of users.	The target for most websites and the legal standard in most jurisdictions.
AAA	Enhanced accessibility. Addresses additional barriers but may not be achievable for all content types.	Government, healthcare, education, and high-impact public services.

WCAG 2.2, released in October 2023, adds nine new success criteria on top of 2.1. The most impactful additions focus on target size (interactive elements must be at least 24x24 CSS pixels at AA), dragging movements (alternatives must exist for drag operations), and focus appearance (focus indicators must meet contrast requirements).

The four guiding principles remain: Perceivable (users can perceive the content), Operable (users can interact with the interface), Understandable (content and UI are comprehensible), and Robust (content works with assistive technologies).

Color Contrast

Insufficient color contrast is the number one accessibility failure on the web. If text does not have enough contrast against its background, users with low vision, color blindness, or even just direct sunlight on their screen will struggle to read it.

WCAG Contrast Requirements

Text Type	AA Ratio	AAA Ratio
Normal text (under 18pt / 14pt bold)	4.5:1	7:1
Large text (18pt+ / 14pt bold+)	3:1	4.5:1
UI components and icons	3:1	N/A

• ✓
  All body text meets 4.5:1 contrast ratio. Use the Color Contrast Checker to verify every text-background combination on your site. Critical
• ✓
  Do not rely on color alone to convey information. Error states, status indicators, and chart data must use shape, text, or pattern in addition to color. Critical
• ✓
  Links are distinguishable from surrounding text. Either underline links or ensure a 3:1 contrast ratio between link color and body text color, plus a visual change on hover/focus. Important
• ✓
  Test with color blindness simulation. Approximately 8% of men and 0.5% of women have some form of color vision deficiency. Use QTool's Color Blindness Simulator to preview your site under protanopia, deuteranopia, and tritanopia. Recommended

:root {
  /* These combinations all pass WCAG AA */
  --text-primary: #1a1a2e;    /* On white: 15.4:1 */
  --text-secondary: #4a4a6a;  /* On white: 7.2:1  */
  --text-muted: #6b6b8a;      /* On white: 4.6:1  */
  --bg: #ffffff;

  /* Error state: use icon + text, not just red */
  --error: #d32f2f;           /* On white: 5.9:1  */
  --error-bg: #fef2f2;

  /* Links: underline OR 3:1 contrast vs body text */
  --link: #1a5fb4;            /* On white: 7.1:1, vs body: 3.2:1 */
}

/* Focus indicators: visible and high contrast */
:focus-visible {
  outline: 3px solid #1a5fb4;
  outline-offset: 2px;
}

Need to find accessible color combinations quickly? The Color Picker tool lets you sample and convert colors, and the Color Palette Generator can help you build palettes that meet WCAG requirements from the start.

Keyboard Navigation

Every interactive element on your site must be reachable and operable with a keyboard alone. This is a hard requirement, not a suggestion. Users who rely on keyboard navigation include people with motor disabilities, power users, and screen reader users.

• ✓
  All interactive elements are reachable via Tab key. Links, buttons, inputs, selects, and custom controls must all receive keyboard focus in a logical order. Critical
• ✓
  Focus indicators are visible. Never set outline: none without providing an alternative focus style. WCAG 2.2 requires focus indicators to have at least a 3:1 contrast ratio. Critical
• ✓
  No keyboard traps. Users must be able to navigate away from any component using standard keys (Tab, Escape). Modals must trap focus internally but release it when dismissed. Critical
• ✓
  Provide a skip navigation link. The first focusable element on each page should be a "Skip to main content" link that bypasses the navigation. Important
• ✓
  Custom widgets follow WAI-ARIA keyboard patterns. Tabs use Arrow keys. Menus use Arrow keys + Enter. Accordions use Enter/Space. Important

<body>
  <a href="#main-content" class="skip-link">Skip to main content</a>
  <nav>...navigation...</nav>
  <main id="main-content">
    ...page content...
  </main>
</body>

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 10000;
  font-size: 0.875rem;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;  /* Visible only when focused */
}

function openModal(modalEl) {
  modalEl.setAttribute('aria-hidden', 'false');
  modalEl.style.display = 'flex';

  // Store the element that opened the modal
  const previousFocus = document.activeElement;

  // Find all focusable elements inside the modal
  const focusable = modalEl.querySelectorAll(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  const firstFocusable = focusable[0];
  const lastFocusable = focusable[focusable.length - 1];

  // Focus the first element
  firstFocusable.focus();

  // Trap focus inside the modal
  modalEl.addEventListener('keydown', function trap(e) {
    if (e.key === 'Escape') {
      closeModal(modalEl, previousFocus);
      modalEl.removeEventListener('keydown', trap);
      return;
    }
    if (e.key !== 'Tab') return;

    if (e.shiftKey) {
      if (document.activeElement === firstFocusable) {
        e.preventDefault();
        lastFocusable.focus();
      }
    } else {
      if (document.activeElement === lastFocusable) {
        e.preventDefault();
        firstFocusable.focus();
      }
    }
  });
}

function closeModal(modalEl, previousFocus) {
  modalEl.setAttribute('aria-hidden', 'true');
  modalEl.style.display = 'none';
  previousFocus.focus();  // Return focus to the trigger
}

Semantic HTML

Semantic HTML is the foundation of accessible web development. Screen readers and other assistive technologies rely on HTML semantics to communicate the structure, purpose, and relationships of content to users.

Use the Right Element for the Job

Instead of...	Use...	Why
<div onclick>	<button>	Buttons are focusable, activatable with Enter/Space, and announced as buttons by screen readers.
<div class="nav">	<nav>	Screen readers can jump directly to navigation landmarks.
<div class="header">	<header>	Defines the banner landmark for the page or section.
<div class="main">	<main>	Identifies the primary content. Screen readers offer shortcuts to jump to main.
<b> for headings	<h1>–<h6>	Heading hierarchy enables navigation by heading level. A properly structured heading tree is one of the most important accessibility features.
<div class="list">	<ul>, <ol>	Screen readers announce "list, 5 items" and let users skip the entire list.

• ✓
  Page has exactly one <h1> and headings follow a logical hierarchy. Do not skip levels (e.g., h1 to h3). Screen reader users navigate by heading level. Critical
• ✓
  Use landmark elements: <header>, <nav>, <main>, <footer>. These create navigable regions for screen reader users. Critical
• ✓
  Use <button> for actions and <a> for navigation. Buttons trigger actions on the current page. Links navigate to a new page or section. Important

You can verify your HTML structure and validate landmark regions using QTool's HTML Beautifier, which formats your markup into a readable structure that makes semantic issues obvious.

ARIA Attributes

ARIA (Accessible Rich Internet Applications) provides additional semantics when native HTML elements fall short. However, ARIA should be your last resort, not your first choice.

Essential ARIA Patterns

<!-- Bad: div with no semantics -->
<div class="toggle" onclick="toggle()">Dark Mode</div>

<!-- Good: button with ARIA state -->
<button
  role="switch"
  aria-checked="false"
  aria-label="Dark mode"
  onclick="toggleDarkMode(this)"
>
  Dark Mode
</button>

<script>
function toggleDarkMode(btn) {
  const isOn = btn.getAttribute('aria-checked') === 'true';
  btn.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode');
}
</script>

<!-- Announce search results count to screen readers -->
<div aria-live="polite" aria-atomic="true" class="sr-only" id="search-status">
  <!-- Updated via JavaScript when results change -->
</div>

<script>
function updateSearchResults(results) {
  renderResults(results);
  document.getElementById('search-status').textContent =
    `${results.length} results found`;
}
</script>

<!-- Screen-reader-only class -->
<style>
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}
</style>

<div role="tablist" aria-label="Project settings">
  <button role="tab" aria-selected="true" aria-controls="panel-general"
          id="tab-general" tabindex="0">
    General
  </button>
  <button role="tab" aria-selected="false" aria-controls="panel-security"
          id="tab-security" tabindex="-1">
    Security
  </button>
  <button role="tab" aria-selected="false" aria-controls="panel-billing"
          id="tab-billing" tabindex="-1">
    Billing
  </button>
</div>

<div role="tabpanel" id="panel-general" aria-labelledby="tab-general">
  <!-- General settings content -->
</div>
<div role="tabpanel" id="panel-security" aria-labelledby="tab-security" hidden>
  <!-- Security settings content -->
</div>
<div role="tabpanel" id="panel-billing" aria-labelledby="tab-billing" hidden>
  <!-- Billing settings content -->
</div>

Images and Media

• ✓
  Every <img> has an alt attribute. Informative images need descriptive alt text. Decorative images should use alt="" (empty string, not missing). Critical
• ✓
  Alt text describes the content and function, not the appearance. "Submit button" is better than "Green arrow icon". "Line chart showing 40% growth in Q4" is better than "chart.png". Important
• ✓
  Videos have captions. Audio has transcripts. Captions benefit deaf users, non-native speakers, and anyone in a noisy or quiet environment. Important
• ✓
  No auto-playing media with sound. Auto-playing audio is disorienting for screen reader users and disruptive for everyone. If auto-play is necessary, start muted with visible controls. Important
• ✓
  Avoid flashing content. Content that flashes more than 3 times per second can trigger seizures in people with photosensitive epilepsy. This is a WCAG Level A requirement. Critical

<!-- Informative image: describe what it shows -->
<img src="dashboard.png"
     alt="Analytics dashboard showing 12,847 monthly active users with a 23% increase from last month">

<!-- Functional image (link or button): describe the action -->
<a href="/home">
  <img src="logo.svg" alt="QTool home page">
</a>

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

<!-- Complex image: use figcaption or aria-describedby -->
<figure>
  <img src="architecture-diagram.svg"
       alt="System architecture diagram"
       aria-describedby="arch-desc">
  <figcaption id="arch-desc">
    The frontend sends API requests to a load balancer,
    which routes traffic to three application servers.
    Each server connects to a shared PostgreSQL database
    and Redis cache cluster.
  </figcaption>
</figure>

Accessible Forms

Forms are where accessibility failures cause the most direct harm. An inaccessible form can prevent a user from purchasing a product, signing up for a service, or completing a required process.

• ✓
  Every input has a visible <label> element. Labels must be programmatically associated using for/id or by wrapping the input. Placeholder text is not a label. Critical
• ✓
  Error messages identify the field and describe the problem. "Email is required" is good. A red border with no text is not. Errors should appear adjacent to the field, not just at the top of the form. Critical
• ✓
  Required fields are indicated in the label, not just with an asterisk. Use aria-required="true" and visible text like "(required)" for clarity. Important
• ✓
  Use autocomplete attributes on common fields. This helps autofill tools and assistive technologies pre-populate data like name, email, address, and credit card information. Recommended

<form novalidate>
  <div class="field">
    <label for="email">Email address (required)</label>
    <input
      type="email"
      id="email"
      name="email"
      autocomplete="email"
      aria-required="true"
      aria-describedby="email-error"
      aria-invalid="false"
    >
    <p id="email-error" class="error" role="alert" hidden>
      Please enter a valid email address (e.g., name@example.com).
    </p>
  </div>

  <fieldset>
    <legend>Notification preferences</legend>
    <label>
      <input type="checkbox" name="notify-email" checked>
      Email notifications
    </label>
    <label>
      <input type="checkbox" name="notify-sms">
      SMS notifications
    </label>
  </fieldset>

  <button type="submit">Save preferences</button>
</form>

Screen Reader Compatibility

Screen readers convert on-screen content into speech or braille output. The three most widely used screen readers are:

• NVDA (Windows, free) — The most common screen reader for testing. Pairs with Firefox and Chrome.
• VoiceOver (macOS/iOS, built-in) — Activate with Cmd+F5 on macOS. Essential for testing Apple devices.
• JAWS (Windows, commercial) — Widely used in corporate environments. Most feature-rich.

Screen Reader Testing Checklist

• ✓
  Page title is unique and descriptive. Screen readers announce the page title when a tab is opened. "Dashboard - MyApp" is clear. "MyApp" on every page is not. Important
• ✓
  The <html lang> attribute is set correctly. Screen readers use the language attribute to select the correct pronunciation rules. <html lang="en"> for English. Critical
• ✓
  Dynamic content updates are announced. Use aria-live="polite" for non-urgent updates (search results) and aria-live="assertive" for urgent announcements (errors). Important
• ✓
  All interactive elements have accessible names. Icon-only buttons need aria-label. Inputs need labels. Links need descriptive text (avoid "click here"). Critical

<!-- Icon-only button: needs aria-label -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">...X icon...</svg>
</button>

<!-- Decorative icons: hide from screen readers -->
<span aria-hidden="true">★</span> 4.8 out of 5 stars

<!-- Link with meaningful text -->
<!-- Bad -->
<a href="/pricing">Click here</a>
<!-- Good -->
<a href="/pricing">View pricing plans</a>

<!-- Loading state: announce to screen readers -->
<div aria-live="polite">
  <span role="status">Loading search results...</span>
</div>

Responsive Design and Zoom

WCAG requires that content is usable at 200% browser zoom and that text can be resized up to 200% without loss of content or functionality. Many users with low vision rely on zoom as their primary accommodation.

• ✓
  Content is readable at 200% zoom without horizontal scrolling. Test by zooming your browser to 200% (Ctrl/Cmd + =). No content should overflow or become hidden. Critical
• ✓
  Touch targets are at least 24x24 CSS pixels. WCAG 2.2 AA requires a minimum target size of 24x24px. For mobile, 44x44px is the recommended minimum. Important
• ✓
  Do not disable pinch-to-zoom. Never use user-scalable=no or maximum-scale=1.0 in your viewport meta tag. Important

<!-- Correct: allows user scaling -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<!-- WRONG: prevents zooming (accessibility violation) -->
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

Use QTool's Responsive Tester to preview how your pages render at different viewport sizes and zoom levels.

Testing Tools

The best accessibility testing combines automated scanning with manual testing. Automated tools catch about 30-40% of accessibility issues. The rest requires human judgment.

Automated Tools

Tool	Type	What It Catches
axe DevTools	Browser extension	WCAG violations, best practices. The industry standard for automated a11y testing.
Lighthouse	Built into Chrome	Accessibility score plus performance, SEO, and best practices in one scan.
WAVE	Web-based / extension	Visual overlay showing errors, alerts, and structural elements directly on the page.
Pa11y	CLI / CI integration	Automated accessibility testing in CI pipelines. Fails builds on WCAG violations.

QTool Accessibility Tools

---