The WCAG 2.1 AA Checklist Every WordPress Site Owner Needs

Only 4 in every 100 websites pass basic automated accessibility checks. That is not a projection — it is the finding of the WebAIM Million 2025 report, which tested the homepages of the world’s top one million websites and found detectable WCAG failures on 95.9% of them. The average homepage had 56 distinct errors. That number has barely moved in six consecutive years of reporting.

If your WordPress site is in that majority — and statistically it probably is — the consequences are concrete. Users with disabilities cannot access your content. You face growing legal exposure under the ADA, the UK Equality Act, and the European Accessibility Act (enforceable from June 2025). And you are leaving real revenue on the table: 1 in 6 people globally lives with some form of disability, and many more benefit from accessible design every day — users zooming on mobile, navigating by keyboard, or watching video without sound.

WCAG 2.1 AA is the compliance target that almost every legal and regulatory framework points to. This checklist cuts straight to the criteria WordPress sites fail most often and tells you exactly what to fix.

---

What Is WCAG 2.1 AA and Why Does It Matter for WordPress?

The Web Content Accessibility Guidelines (WCAG) 2.1 are published by the W3C and built around four principles — Perceivable, Operable, Understandable, Robust (POUR). Level AA is the target for most regulations worldwide, covering 50 success criteria across those four principles.

WordPress powers over 43% of all websites. That means millions of site owners are directly responsible for whether the web becomes more or less accessible. The platform itself has made meaningful progress, but every theme install, plugin update, and block customisation is an opportunity to introduce new failures.

WCAG 2.1 vs WCAG 2.2: What You Need to Know

The W3C published WCAG 2.2 in October 2023, adding nine new success criteria focused mainly on focus appearance, dragging movements, and accessible authentication. This checklist uses WCAG 2.1 AA as the current legal baseline, with clearly marked callouts wherever WCAG 2.2 raises the bar. If you are building toward 2.2 compliance — increasingly expected by procurement teams and regulators — treat those callouts as required, not optional.

Use this checklist as a structured audit guide. Work through each section, flag failures, and prioritise fixes by page traffic and user impact.

---

Perceivable: Can Every User Access Your Content?

Content must be presentable to users in ways they can perceive, regardless of which senses they rely on.

1.1.1 — Non-Text Content (Alt Text)

Every image, icon, button graphic, and chart must have a text alternative. The WebAIM Million 2025 report found missing or empty alt text on 39.4% of all homepage images tested — making it the single most common WCAG failure for six consecutive years.

In WordPress:

• Add meaningful alt text in the Media Library or directly in the block editor’s image settings
• Decorative images — dividers, background textures, purely stylistic icons — must use alt="" so screen readers skip them
• Linked images need alt text describing the destination, not the image itself (e.g. “AccessYes plugin page on WordPress.org”, not “blue button”)
• Complex charts, infographics, or diagrams need either a full text description nearby or a <figure><figcaption> pairing

Quick win: Run your site through WAVE — every flagged missing alt attribute is typically a five-second fix in the block editor.

1.3.1 — Info and Relationships

Visual structure must be communicated in code, not just through appearance. Sighted users understand that a bold, large line of text is a heading — a screen reader user needs that relationship confirmed in the markup.

• Use a proper heading hierarchy (<h1> → <h2> → <h3>) — never skip levels purely for visual sizing
• Use real HTML lists (<ul>, <ol>) instead of manually typed dashes or bullet characters
• Use <table> with <th scope="col"> for tabular data — never use tables for visual layout only

1.4.1 — Use of Colour

Colour alone must not be the only means of conveying information. A red form validation error also needs an icon, a label such as “Error:”, or descriptive inline text. This applies to charts, status badges, required field indicators, and any link distinguished from surrounding body text by colour alone.

1.4.3 — Contrast (Minimum)

Text type	Minimum contrast ratio
Normal text (below 18px regular or 14px bold)	4.5:1
Large text (18px regular or 14px bold and above)	3:1
Disabled UI components	Exempt

Check every text-and-background combination on your site — including text overlaid on images, subtitle text in hero sections, and placeholder text in form fields. Use WebAIM’s Contrast Checker or the built-in colour picker in Chrome or Firefox DevTools.

1.4.4 — Resize Text

Users must be able to zoom to 200% without losing content or functionality. Two fixes prevent most failures here:

• Avoid fixed px units for font sizes in your theme CSS — use rem so operating system and browser zoom scales correctly
• Test at 200% browser zoom on your most content-dense pages and verify nothing overflows, truncates, or disappears

1.4.11 — Non-Text Contrast (Added in WCAG 2.1)

UI components — buttons, text inputs, checkboxes, radio buttons, sliders — and their focus indicators must achieve at least a 3:1 contrast ratio against adjacent colours. This is one of the most consistently missed criteria on WordPress sites using pastel or light-grey UI palettes.

---

Operable: Can Every User Navigate and Use Your Site?

Users must be able to operate your site’s interface regardless of input method — mouse, keyboard, switch device, or voice control.

2.1.1 — Keyboard Accessible

Every piece of functionality must be reachable and usable with a keyboard alone. Run this test right now:

1. Unplug or disable your mouse
2. Tab through your homepage using only the keyboard
3. Can you reach every link, button, and form field?
4. Can you open, navigate, and close the main navigation menu?
5. Can you activate sliders, accordions, and modals?
6. Can you complete and submit your contact form?

Common WordPress failures: navigation menus that only open on hover, image sliders with no keyboard controls, and custom JavaScript widgets that receive focus but cannot be activated or dismissed with the keyboard.

2.1.2 — No Keyboard Trap

If keyboard focus enters a component — a modal dialog, a date picker, a cookie consent banner — the user must be able to exit it using only the keyboard (typically the Escape key). Trapped focus prevents screen reader users from accessing anything else on the page and is classified as a critical barrier, not a minor inconvenience.

2.4.3 — Focus Order

Tab order must follow a logical reading sequence. If you use CSS order, flexbox reordering, or position: absolute to visually rearrange content, verify that the underlying DOM order still reads sensibly from top to bottom.

2.4.4 — Link Purpose (In Context)

Every link must be understandable from its text alone or from its immediate surrounding context. Audit your site for these patterns and replace them with descriptive alternatives:

• “Click here” → “Download the AccessYes plugin”
• “Read more” → “Read our guide to WCAG 2.1 AA for WordPress”
• “Learn more” → “Learn more about accessible form design”
• Bare URLs used as link text

2.4.7 — Focus Visible

The keyboard focus indicator must always be visible. Removing the focus outline without replacing it is one of the most common — and most damaging — accessibility mistakes in WordPress theme development.

/* Never do this without a carefully designed replacement */
:focus {
  outline: none;
}

/* Do this instead — visible and scoped to keyboard navigation */
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
  border-radius: 2px;
}

WCAG 2.2 upgrade: Success criterion 2.4.11 (Focus Appearance) requires that the focus indicator has a minimum 2px perimeter around the component and meets a 3:1 contrast ratio against adjacent colours. If you are targeting WCAG 2.2, your :focus-visible styles must meet both of those thresholds.

---

Understandable: Is Your Content and UI Predictable?

Both your content and your interface must be understandable — users should never be surprised or blocked by unexpected behaviour.

3.1.1 — Language of Page

The <html> element must declare the page’s language so screen readers load the correct pronunciation engine and language rules.

<html lang="en">

WordPress sets this automatically based on your site language under Settings → General. Verify your active theme is not overriding it. If your site serves content in multiple languages, set the lang attribute on individual sections or page templates accordingly.

3.2.2 — On Input

Changing a form field’s value must not trigger an unexpected context change — no automatic page redirects, no modal launches, no form submissions — unless the user has been explicitly warned in advance. Significant actions should always be triggered by a clearly labelled button, not by the act of selecting a value.

3.3.1 — Error Identification

When a form submission fails validation, each error must be described in text and programmatically associated with the specific input that caused it. A red border or pink background alone does not meet this criterion.

<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-error"
  aria-invalid="true"
>
<span id="email-error" role="alert">
  Enter a valid email address, for example name@example.com
</span>

3.3.2 — Labels or Instructions

Every form input must have a persistent, visible label. Placeholder text — the grey hint text that disappears as soon as the user starts typing — does not meet this criterion on its own. If your design cannot accommodate a visible label, use a visually hidden label that remains available to screen readers:

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip: rect(0 0 0 0);
  white-space: nowrap;
}

---

Robust: Does Your Code Work With Assistive Technologies?

Content must be robust enough for both current and future assistive technologies to interpret reliably.

4.1.1 — Parsing

Your HTML must be well-formed: elements properly nested, no duplicate id attributes on a single page, all required attributes present. Validate any high-traffic page at validator.w3.org. Malformed markup is the second most commonly detected failure category in automated accessibility testing.

4.1.2 — Name, Role, Value

Every UI component must expose its name, role, and current state to assistive technologies. For custom widgets not built from native HTML elements:

• Assign semantic ARIA roles: role="dialog", role="tabpanel", role="alert", role="navigation"
• Expose dynamic state: aria-expanded="true", aria-checked="false", aria-disabled="true", aria-selected="true"
• Test with NVDA + Firefox on Windows (both free) or VoiceOver + Safari on macOS and iOS (built in)

A practical rule: use native HTML elements wherever they exist. A <button> is always better than a <div role="button"> because native elements carry their semantics and keyboard behaviour automatically.

4.1.3 — Status Messages (Added in WCAG 2.1)

Dynamically injected messages — “Item added to cart,” “Form submitted successfully,” “Showing 12 of 48 results” — must reach screen reader users without moving keyboard focus away from where the user is working. Use ARIA live regions to announce them:

<div
  aria-live="polite"
  aria-atomic="true"
  class="visually-hidden"
  id="status-message"
>
  Your message has been sent successfully.
</div>

Use aria-live="assertive" only for time-sensitive errors requiring immediate attention. Overusing assertive interrupts whatever the screen reader was reading and quickly becomes disruptive.

---

How to Prioritise Your WCAG 2.1 Fixes

Working through 50 success criteria across an entire WordPress site is a significant project. Use this sequence to make meaningful progress quickly rather than stalling at the starting line.

1. Run an automated scan first. WAVE, Axe DevTools, or the built-in accessibility checker in some page builders will detect 30–40% of failures automatically. Fix everything they flag before doing anything manual.
2. Keyboard-test your five most-visited pages — your homepage, main product or services page, contact form, any gated content, and your checkout if you have one.
3. Audit all images for alt text. It is the highest-volume failure and usually the fastest to fix at scale. The WordPress block editor makes it straightforward.
4. Check your full colour palette for contrast. A single theme-level fix in your theme.json or custom CSS can resolve dozens of individual failures at once.
5. Screen reader test every form. Forms are where critical failures are most likely to completely block users from completing a task.
6. Fix dynamically generated content. Carousels, modals, flyout menus, live search results, and cart notifications are common sources of keyboard trap and missing live region failures.
7. Publish an Accessibility Statement. Document what you have done, what you are still working on, and how users can report issues. This is a legal requirement under the EAA and increasingly expected under other frameworks.

---

Give Users Immediate Control With AccessYes

Full remediation takes time — especially on mature WordPress sites with established themes and extensive plugin stacks. In the meantime, AccessYes lets your visitors take direct control of their own browsing experience from the moment they arrive.

The free WordPress plugin adds a configurable accessibility widget that allows users to:

• Increase font size and adjust line spacing
• Enable high contrast or dark mode
• Switch to a dyslexia-friendly typeface
• Activate a reading guide and enlarged cursor

It installs in under two minutes, requires no coding, and is built to be WCAG-aware in its own implementation. It will not make a non-compliant site fully compliant on its own — no widget can — but it delivers an immediate, tangible improvement to real users while you work through the fixes above.

---

Make Accessibility a Continuous Practice, Not a One-Off Audit

A completed WCAG audit is not a permanently valid certificate. Every new page you publish, every plugin you update, and every theme change you make is an opportunity to introduce or remediate accessibility failures. Build basic keyboard and screen reader testing into your publishing workflow, train content editors on alt text and heading structure, and revisit your accessibility statement quarterly.

Every improvement you make benefits users well beyond the traditional definition of disability — people on slow mobile connections, older users who zoom or increase contrast, anyone navigating by keyboard because it is simply faster. Accessibility done well is good web design, full stop.

Don’t let another week pass with 56 errors on your homepage. Install AccessYes free from WordPress.org and give every visitor a more accessible experience today — while you work through the rest of this checklist at a sustainable pace.