WCAG 2.1 AA Checklist for WordPress Sites (2026 Edition)

Here is a number that should stop you in your tracks: 96.3% of the top one million homepages on the web have detectable WCAG failures. That figure comes from the WebAIM Million 2025 report — the most comprehensive annual accessibility audit of the public web — and it means the overwhelming probability is that your WordPress site is failing people right now, today, without you knowing it.

The average failing page carries 56.8 distinct accessibility errors. The most common are low colour contrast, missing image alt text, empty links, missing form labels, and missing document language — all things that are straightforwardly fixable once you know to look for them.

This matters beyond usability alone. WCAG 2.1 AA is the technical benchmark cited by the ADA, Section 508, and the European Accessibility Act, which became enforceable for private businesses in June 2025. US federal accessibility lawsuits have held above 4,000 annually since 2022. The legal and ethical case for fixing these problems has never been stronger — and this checklist gives you the clearest possible path to doing it.

---

What WCAG 2.1 AA Actually Requires

The Web Content Accessibility Guidelines (WCAG) 2.1 are published by the W3C and built around four principles — Perceivable, Operable, Understandable, Robust (POUR). There are three conformance levels: A (minimum), AA (the legal and practical standard), and AAA (enhanced). WCAG 2.1 AA covers 50 success criteria in total.

A note on WCAG 2.2: W3C published WCAG 2.2 in October 2023, adding nine new criteria with stronger requirements around focus appearance, mobile interactions, and authentication. It is not yet the universal legal baseline everywhere, but the EU and UK are already referencing it, and US federal agencies must meet WCAG 2.1 AA as a minimum floor. This checklist covers WCAG 2.1 AA — and flags WCAG 2.2 additions where it is practical to implement them now.

The sections below focus on the criteria most commonly failed on WordPress sites, organised by POUR principle, with specific fixes for each.

---

Perceivable: Make Sure Every User Can Access Your Content

Your content must be available in a form every user can perceive — regardless of whether they use a screen reader, rely on captions, or cannot distinguish certain colours.

1.1.1 — Non-Text Content (Level A)

Every image, icon, button graphic, chart, and infographic needs a text alternative that conveys its meaning or function.

In WordPress:

• Write meaningful alt text for every image in the Media Library — describe what the image communicates, not just what it depicts
• Decorative images (dividers, backgrounds, flourishes) get alt="" — this tells screen readers to skip them entirely
• Complex visuals like charts need a longer description: use <figure> with <figcaption>, or link to a text summary

<!-- Informative image -->
<img src="chart.png" alt="Bar chart: organic traffic increased 40% from Q1 to Q3 2025">

<!-- Decorative image -->
<img src="wave-divider.png" alt="">

A common WordPress-specific failure: images inserted via page builders where the alt field defaults to the filename (image-001.jpg). Audit your Media Library regularly and treat any filename-as-alt-text as an immediate failure.

1.3.1 — Info and Relationships (Level A)

Structure must be encoded in the HTML, not just implied visually. A sighted user may understand that large bold text is a heading — a screen reader only knows if you have used an actual heading element.

Checklist:

• One <h1> per page (WordPress sets this as the post or page title by default — verify your theme does not override this)
• Heading levels are sequential — no jumping from <h2> to <h4>
• Lists use <ul> or <ol>, never dashes or asterisks inside a paragraph
• Data tables use <th> with the appropriate scope attribute (col or row)

1.4.1 — Use of Colour (Level A)

Colour must never be the only means of conveying information. If your form fields turn red on error, that is insufficient on its own — add an icon, a label, or descriptive text that does not rely on colour perception alone.

1.4.3 — Contrast Minimum (Level AA)

Text Type	Minimum Contrast Ratio
Normal text (below 18px regular / 14px bold)	4.5:1
Large text (18px+ regular / 14px+ bold)	3:1
Disabled UI components	Exempt
Logotypes	Exempt

Do not guess — measure. Use the WebAIM Contrast Checker or the built-in contrast tools in Chrome and Firefox DevTools. Check text over images, text inside buttons, and text in hover or focus states — not just default body copy.

1.4.4 — Resize Text (Level AA)

Users must be able to zoom to 200% without losing content or functionality. The most common cause of failure on WordPress sites is using px units for font sizes, which overrides the user’s browser font size preferences.

/* ❌ Ignores the user's system font size setting */
body { font-size: 16px; }

/* ✅ Scales with the user's preferences */
body { font-size: 1rem; }

Test this yourself: set your browser to 200% zoom and check that text reflows cleanly and that no content is clipped or obscured.

1.4.11 — Non-Text Contrast (Level AA, added in WCAG 2.1)

UI components — form field borders, checkbox outlines, radio buttons, toggle switches, and their focus indicators — must have at least 3:1 contrast against adjacent colours. Many WordPress themes use light grey borders on white backgrounds that fail this criterion outright. Audit your theme’s form styles specifically, and do not assume a popular theme has handled this correctly.

---

Operable: Build an Interface Anyone Can Navigate

Users must be able to operate your interface regardless of how they interact with it — keyboard, switch control, voice input, or pointer device.

2.1.1 — Keyboard Accessibility (Level A)

Every feature available by mouse must be reachable and operable by keyboard alone. This is the single most impactful criterion for users with motor impairments — and one of the most commonly failed on WordPress sites.

How to test it:

1. Unplug (or disable) your mouse
2. Use Tab to move forward, Shift+Tab to move back, Enter to activate links and buttons, Space for checkboxes and toggles, and arrow keys for grouped controls like radio buttons
3. Check that you can open and close navigation menus
4. Check that you can operate carousels, accordions, and tab panels
5. Check that you can complete and submit every form
6. Check that you can dismiss modals and overlays

If any of these fail, keyboard-only users — including a significant portion of screen reader users and people with motor impairments — are blocked entirely.

2.1.2 — No Keyboard Trap (Level A)

If keyboard focus enters a component (a modal, a date picker, a mega-menu), users must be able to leave it using only the keyboard — typically Escape or continued Tab navigation. A keyboard trap is a critical failure: it leaves users stranded with no path forward and no way to proceed without a mouse or a page reload.

2.4.3 — Focus Order (Level A)

Tab order must follow a logical reading sequence. If you use CSS order or position: absolute to visually reorder content, the underlying HTML (the DOM order) still determines tab sequence. Check that visual order and DOM order align, particularly in complex layouts built with page builder plugins.

2.4.4 — Link Purpose (Level A)

Every link must be understandable from its text alone, or from the context immediately surrounding it. Screen reader users commonly navigate a page by jumping between links — vague link text gives them no useful information about the destination.

❌ Avoid	✅ Use instead
Click here	Download the 2026 accessibility checklist (PDF)
Read more	Read our full guide to WCAG 2.1 for WordPress
Learn more	Learn more about AccessYes features

2.4.7 — Focus Visible (Level AA)

The keyboard focus indicator must always be visible. This is one of the most commonly disabled browser defaults in the wild — often removed with a single CSS rule that someone added years ago because they found the default outline aesthetically unwelcome.

/* ❌ Never do this without a robust custom replacement */
*:focus { outline: none; }

/* ✅ A custom focus style that passes WCAG 2.1 AA */
*:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
  border-radius: 2px;
}

WCAG 2.2 upgrade: Success criterion 2.4.11 (Focus Appearance) sets minimum size and contrast requirements for focus indicators. If you are refreshing your theme’s styles, build to this standard now — it will become a legal requirement in more jurisdictions as WCAG 2.2 adoption grows.

---

Understandable: Content and Behaviour That Makes Sense

Your content must be readable and predictable. Your interface must help users avoid — and recover from — mistakes.

3.1.1 — Language of Page (Level A)

The lang attribute on the <html> element tells screen readers which language rules and pronunciation to apply. If it is missing or incorrect, screen readers may mispronounce every word on your site.

<html lang="en">

WordPress sets this automatically when you configure your site language under Settings → General. Check your rendered page source to confirm it is present — some caching or minification configurations strip HTML attributes unexpectedly.

3.2.2 — On Input (Level A)

Changing a form control’s value must not automatically trigger unexpected context changes — submitting the form, navigating to a new page, or opening a modal without warning. Users must initiate changes explicitly by activating a button. This most commonly fails in custom dropdown menus that navigate on the change event rather than waiting for explicit user confirmation.

3.3.1 — Error Identification (Level A)

When a form submission fails, describe each error in text — specifically and clearly. Never rely on colour, icons, or field position alone.

<!-- ✅ Accessible error message -->
<p id="email-error" role="alert">
  Error: Please enter a valid email address (e.g. name@example.com).
</p>
<input
  type="email"
  aria-describedby="email-error"
  aria-invalid="true"
>

The role="alert" causes screen readers to announce the error immediately on injection. The aria-invalid attribute signals to assistive technology that this specific field has a problem.

3.3.2 — Labels or Instructions (Level A)

Every form input must have a visible, persistent label. Placeholder text is not a label — it disappears the moment a user starts typing, carries insufficient contrast in most browser defaults, and is not reliably announced by all screen reader and browser combinations.

<!-- ❌ Placeholder-only pattern — common and non-compliant -->
<input type="text" placeholder="Your name">

<!-- ✅ Visible label with supplementary placeholder -->
<label for="name">Your name</label>
<input type="text" id="name" placeholder="e.g. Jane Smith">

---

Robust: Code That Assistive Technologies Can Reliably Parse

Your content must be built on a solid technical foundation that current and future assistive technologies can interpret accurately.

4.1.1 — Parsing (Level A)

Invalid HTML can cause screen readers to misinterpret your content in unpredictable ways. Duplicate id attributes are particularly damaging because ARIA relationships depend on unique IDs to function correctly — and page builders are notorious for generating them.

Quick checks:

• Run key pages through the W3C HTML Validator
• Search your theme’s source for duplicate id values
• Confirm ARIA landmark regions (<main>, <nav>, <header>, <footer>) are used correctly and not duplicated without distinguishing labels

4.1.2 — Name, Role, Value (Level A)

Every interactive component must expose its name, role, and current state to assistive technology. This is straightforward for native HTML elements. For custom components — accordions, carousels, tab panels, dropdown menus, date pickers — it requires explicit ARIA.

<!-- Accordion button with correct ARIA -->
<button aria-expanded="false" aria-controls="faq-1">
  What is WCAG 2.1 AA?
</button>
<div id="faq-1" hidden>
  <p>WCAG 2.1 AA is the mid-tier conformance level of the Web Content Accessibility Guidelines...</p>
</div>

When the accordion opens, aria-expanded must update to "true" and hidden must be removed. Test every custom component with a real screen reader — NVDA is free for Windows, VoiceOver is built into macOS and iOS. If you cannot understand and operate a component using audio feedback alone, it fails this criterion.

4.1.3 — Status Messages (Level AA, added in WCAG 2.1)

Dynamic updates — “Item added to cart,” “Your message has been sent,” “3 results found” — must reach screen reader users without requiring a page reload or shifting keyboard focus. Use aria-live regions for this.

<div
  aria-live="polite"
  aria-atomic="true"
  class="sr-only"
  id="status-message"
>
  <!-- Dynamically injected: "Your message has been sent successfully." -->
</div>

Use aria-live="polite" for non-urgent updates (it waits for the user to finish their current action). Reserve aria-live="assertive" for genuinely critical alerts — overusing it creates a disruptive, unusable experience for screen reader users.

---

How to Prioritise Your WCAG 2.1 AA Fixes

A full audit of a complex WordPress site can surface dozens of issues simultaneously. Here is a practical sequence that maximises impact without requiring you to fix everything at once.

1. Run automated scans first. Tools like WAVE, Axe, or Lighthouse catch roughly 30–40% of WCAG issues automatically. They are fast, free, and give you a defensible baseline. Start here before doing anything else.
2. Prioritise your highest-traffic pages. Your homepage, core landing pages, product pages, and contact or checkout flows affect the most users. Fix these before lower-traffic pages.
3. Do a keyboard-only walkthrough. Disable your mouse and spend 15 minutes trying to complete key tasks on your site. You will find critical blockers that no automated tool catches.
4. Test with a real screen reader. Even 30 minutes with VoiceOver or NVDA will reveal gaps in ARIA implementation, missing labels, and content structure problems that are invisible to automated scanners.
5. Audit contrast across all interactive states. Check hover, focus, active, error, and disabled states — not just default body styles.
6. Publish an Accessibility Statement. Document what you have tested, what you are working on, and how users can report issues. It is legally required in some jurisdictions under the European Accessibility Act, and it signals to disabled users that their experience matters to you.

---

Where AccessYes Fits Into Your Accessibility Strategy

Achieving full WCAG 2.1 AA conformance requires a proper audit