Website Accessibility Audit Checklist for WordPress (WCAG 2.1 AA)
Most WordPress sites we audit fail WCAG 2.1 AA in the same dozen places.
Not because the people who built them didn't care, but because accessibility problems hide in the parts of a site nobody looks at closely: the color of a link, the order of headings, the name of a form field, the PDF someone uploaded in 2019. We've spent years doing WCAG 2.1 AA audits and remediation on WordPress sites for universities, research institutions, nonprofits, and businesses. This is the checklist we actually use, adapted for a site owner who wants to know where their site stands — or what a specialist should be looking at.
Before You Start: Three Tools
You’ll want a browser extension like WAVE or axe DevTools, which catch roughly a third of issues automatically. You’ll want a keyboard (you already have one). And you’ll want a screen reader for spot checks: VoiceOver is built into every Mac, and NVDA is free on Windows. Automated tools are a starting point, not an audit. Everything below that says “test manually” means exactly that.
A note on scope: WCAG 2.1 AA has 50 success criteria. This isn’t all of them. It’s the ones that fail most often on WordPress sites specifically, organized by where the problem usually lives.
Part 1: Theme-Level Issues
These live in your theme and affect every page. Fixing them once fixes them everywhere.
-
#1 - Color contrast
Normal text needs a contrast ratio of at least 4.5:1 against its background; large text (roughly 24px, or 19px bold) needs 3:1. The usual failures: light gray body text, white text on brand colors that are too light, placeholder text in forms, and link colors that don’t contrast enough with surrounding text. Run your palette through the WebAIM Contrast Checker.
-
#2 - Keyboard focus is visible
Press Tab and move through the page. Can you always see where you are? Many themes remove the focus outline for aesthetic reasons, which makes the site unusable for keyboard-only visitors. Every interactive element needs a visible focus state.
-
#3 - Everything works by keyboard
Keep tabbing. Can you open the mobile menu, operate dropdowns, close a modal, play a video, and advance a slider without a mouse? Can you get out of everything you get into? Keyboard traps are a Level A failure.
-
#4 - Skip link
There should be a “Skip to content” link as the first focusable element on the page. Many themes include one; many hide it in a way that also hides it from keyboard users.
-
#5 - Navigation menus
Dropdown menus need to be reachable by keyboard and announced properly to screen readers. Mega-menus are a frequent failure point.
-
#6 - Text resizes to 200%
Zoom your browser to 200% and check that content doesn’t overlap, get cut off, or disappear.
-
#7 - Motion
Auto-playing carousels, background videos, and parallax effects need a pause control or must respect the user’s reduced-motion setting. Carousels are the single most common accessibility problem we see — and the easiest to eliminate.
Part 2: Content and Block Editor Issues
These live in the pages and posts, which means they’re usually created by content editors, not developers — and they recur every time someone publishes.
-
#1 - Heading structure
Headings should form an outline: one H1 per page, H2s for major sections, H3s beneath them. Don’t skip levels, and don’t choose a heading because it looks the right size. Screen reader users navigate by headings the way sighted users skim, so a scrambled outline is disorienting.
-
#2 - Alt text on images
Every meaningful image needs alt text that conveys its purpose. Decorative images should have empty alt text, which WordPress produces when you leave the field blank. Common failures: the filename as alt text (“IMG_4032.jpg”), “image of” prefixes, and text baked into images without that text in the alt.
-
#3 - Link text
“Click here,” “read more,” and “learn more” fail when they appear repeatedly on a page, because screen reader users often pull up a list of links out of context. Link text should describe the destination. Most blog index templates need attention here.
-
#4 - Tables
Data tables need a header row marked as such. The core Table block supports this; many page builders don’t. Never use tables for layout.
-
#5 - Documents
Every PDF, Word file, and PowerPoint you’ve uploaded is part of your website for accessibility purposes. Untagged PDFs are among the most common failures on university and government sites. Either remediate the documents or provide the content as an HTML page.
-
#6 - Embedded media
Videos need captions. Audio needs transcripts. Embedded YouTube players are keyboard accessible, but auto-generated captions are not sufficient on their own for accuracy.
-
#7 - Language
The page’s language should be declared (WordPress does this by default) and any passages in another language should be marked up as such.
Part 3: Forms
Forms are where accessibility failures do the most damage, because they’re where visitors are trying to accomplish something.
-
#1 - Every field has a real label
Placeholder text is not a label. Every field needs a visible, programmatically associated label. In Gravity Forms, WPForms, and Contact Form 7 this is configurable — and it’s often configured wrong.
-
#2 - Required fields
Required fields are indicated in a way that isn’t color alone.
-
#3 - Error messages
“There was an error” fails. “Email address is required,” adjacent to the field and announced to screen readers, passes.
-
#4 - CAPTCHAs
Visual-only CAPTCHAs are an accessibility failure. Use an invisible alternative or an accessible one.
-
#5 - Multi-step and donation forms
These need special attention: progress indication, focus management between steps, and clear success messaging.
Part 4: Third-Party Embeds and Plugins
Everything you embed inherits its accessibility from someone else. Event calendars, donation widgets, chat bubbles, social feeds, maps, and booking tools are all frequent offenders. Test each one by keyboard and with a screen reader, and if it fails, ask the vendor for their VPAT or accessibility statement. If they don’t have one, that tells you something.
Part 5: What Automated Tools Miss Entirely
Run WAVE on a page and you might get a clean report while the page still fails. Here’s what only a human catches:
- Whether alt text is actually meaningful (a tool sees that it exists, not that it says “banner”).
- Whether reading order makes sense when CSS is removed or a screen reader reads the DOM.
- Whether focus goes somewhere sensible when a modal opens and closes.
- Whether custom components (accordions, tabs, sliders) announce their state.
- Whether the site is usable end-to-end: can a screen reader user find the contact form, fill it out, and know it was submitted?
What to Fix First
If your audit turns up a long list, prioritize in this order: keyboard traps and anything that blocks a task entirely; forms; contrast and focus visibility; heading and alt text hygiene on your highest-traffic pages; then documents and embeds. The goal is to remove barriers in the order visitors hit them.
