How to Audit WordPress Accessibility: Manual and Automated Steps

A WordPress accessibility audit checks whether people with disabilities can use your site, measured against the Web Content Accessibility Guidelines. A good audit has two halves: automated scans that catch common code errors fast, and manual testing with a keyboard, a screen reader and real tasks like submitting a form. This guide shows the process we use, step by step, so you can run a first pass yourself or know what to expect from a professional audit.

This article is general information, not legal advice.

Before you start: pick the standard and the scope

Choose your target

Audit against WCAG 2.2 Level AA. It is the current version and, according to the World Wide Web Consortium (W3C), content that meets it also meets WCAG 2.1 Level AA. That matters because US federal rules, such as the Department of Justice rule for state and local governments, reference 2.1. Our ADA compliance guide for WordPress explains the legal background, and our summary of WCAG 2.2 changes for WordPress covers the newest criteria.

Choose a representative sample

You do not need to test every blog post. WordPress sites are built from templates, so test each template and every important user journey. The W3C’s WCAG-EM evaluation methodology describes this approach: define the scope, explore the site, select a representative sample, evaluate it, and report.

A typical WordPress sample:

• Home page
• One page from each main template (standard page, blog post, archive, landing page)
• Search results and the 404 page
• Contact form and any lead forms
• Login, account and checkout pages, if you have them
• Any page with video, maps, sliders or embedded third-party tools
• Your most visited pages from analytics

Step 1: Run automated scans

Automated tools are fast and consistent. They are good at catching missing alternative text, low color contrast, missing form labels, empty links and buttons, and invalid ARIA attributes.

Useful free tools:

• axe DevTools browser extension, built on the open source axe-core engine.
• WAVE from WebAIM, which shows issues directly on the page.
• Lighthouse, built into Chrome DevTools, which includes an accessibility section.

Run at least one tool on every page in your sample. Record each issue with the page, the element and the WCAG success criterion it relates to.

Keep the limits in mind. The W3C says that tools cannot check all accessibility aspects automatically and that human judgment is required. A tool can tell you an image has alternative text. It cannot tell you whether the text is accurate. A clean scan is a starting point, not a pass.

Step 2: Test with a keyboard only

Put your mouse aside. Many people navigate with a keyboard or a device that acts like one. Use these keys:

Work through each page in your sample and check:

1. A skip link appears first. Pressing Tab on a fresh page should show a “Skip to content” link.
2. Focus is always visible. You can see a clear outline on every focused item. Many themes remove it with CSS.
3. Focus is never hidden. Sticky headers, cookie banners and chat widgets should not cover the focused item. This is WCAG 2.2 success criterion 2.4.11.
4. Order makes sense. Focus moves in a logical order that matches the visual layout.
5. Menus work. Dropdown menus open with the keyboard, not just on mouse hover.
6. No traps. You can always Tab out of embedded videos, maps and widgets.
7. Modals behave. When a popup opens, focus moves into it. When it closes, focus returns to where you were.

Keyboard testing finds some of the most serious issues, because if a keyboard user cannot reach the “Submit” button, the form does not work for them at all.

Step 3: Test with a screen reader

A screen reader reads the page aloud and lets users jump by headings, links, landmarks and form fields. Free options are NVDA on Windows and VoiceOver, which is built into macOS and iOS. Learn a few basic commands before you start; the first session takes some patience.

Check:

• Page title is unique and describes the page.
• Headings form a logical outline. Use the screen reader’s headings list and look for skipped levels or text styled as a heading but not marked up as one.
• Landmarks such as header, navigation, main and footer are present.
• Images have alternative text that conveys meaning, and decorative images are ignored.
• Links make sense out of context. A list of ten “Read more” links is a failure of usefulness, even when each one technically works.
• Buttons announce a name. Icon-only buttons, like a hamburger menu or a search icon, often announce nothing useful.
• Dynamic updates are announced, such as “Added to cart” or “3 results found.”

Step 4: Test forms end to end

Forms are where accessibility turns into revenue, so test them as a user would. Fill in each form with the keyboard and the screen reader, then submit it with mistakes on purpose.

• Every field has a visible label that is connected to the field in the code. Placeholder text is not a label.
• Required fields are marked in text, not only with color or an asterisk that is not explained.
• Error messages say what went wrong and how to fix it, and the screen reader announces them.
• Focus moves to the error summary or the first field with an error after a failed submit.
• Multi-step forms do not ask for the same information twice (WCAG 2.2 criterion 3.3.7).
• Login forms work with password managers and do not use puzzle CAPTCHAs (criterion 3.3.8).

If you use Gravity Forms, many of these settings are available in the form editor, and custom styling is where they often break. Our article on Gravity Forms custom development covers when custom work is the right fix.

Step 5: Check zoom, reflow, contrast and media

Zoom and reflow

• Zoom the browser to 200%. Text should still be readable, and nothing should be cut off.
• Set the browser window to 320 CSS pixels wide, or zoom to 400% on a 1280-pixel-wide window. Content should reflow into one column without horizontal scrolling (success criterion 1.4.10).

Color contrast

• Normal text needs a contrast ratio of at least 4.5:1 against its background. Large text needs at least 3:1.
• Icons, form field borders and focus indicators need at least 3:1 against what is next to them.
• Information must not be conveyed by color alone, such as links that are only distinguished by color inside body text.

Automated tools catch many contrast failures, but they miss text over background images and gradients. Check those by hand.

Media and documents

• Prerecorded videos with audio need captions.
• Audio-only content, like a podcast, needs a transcript.
• Autoplaying sliders and videos need a way to pause them.
• Linked PDF files need to be tagged and readable, or offered in an accessible alternative format.

Step 6: Report and prioritize

An audit is only useful if it leads to fixes. For each issue, record:

Then group issues by template and component. On WordPress, one fix in the header, menu or form styles often clears the same issue across the whole site. Fix the blockers in key journeys first: navigation, contact forms, checkout and login.

Step 7: Keep it from coming back

Accessibility regresses quietly. A plugin update changes form markup, an editor adds a new landing page, or a redesign drops the focus styles. We treat accessibility errors as one of the metrics we use to measure WordPress technical debt, and we track them over time.

The most reliable way to keep the number down is to add automated accessibility checks to your test suite. With Playwright and the @axe-core/playwright package, a basic check looks like this:

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

test('contact page has no detectable WCAG A/AA violations', async ({ page }) => {
  await page.goto('/contact/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

Run it against staging before every update, alongside your other tests. It will not replace manual testing, but it catches regressions in minutes. Our guides to WordPress automated testing with Playwright and PHPUnit and safe WordPress updates with staging and tests show how to set this up.

What a professional audit adds

You can run a useful first pass yourself with the steps above. A professional audit adds experience with screen readers and assistive technology, knowledge of how WordPress themes, page builders and plugins generate their markup, and a report your developers can act on directly.

If you want an outside view of your site, our WordPress accessibility audit tests your templates and key journeys against WCAG 2.2 Level AA and gives you a prioritized report with specific fixes. Contact us and tell us which pages matter most to your business.

Frequently asked questions

Can I audit accessibility with an automated tool only?

No. Automated tools are a good first pass, but the W3C says they cannot check all accessibility aspects and human judgment is required. Keyboard, screen reader and form testing find many issues scanners miss.

How many pages should an accessibility audit cover?

Enough to cover every template and key user journey. For most WordPress sites that means the home page, each main template, the contact form, search, and any checkout or login flow, rather than every single post.

Which WCAG version should a WordPress audit use?

We recommend WCAG 2.2 Level AA. It is the current version, and content that meets it also meets WCAG 2.1 Level AA, which is the standard named in recent US federal rules.

How often should I audit my WordPress site for accessibility?

Run a full audit before and after a redesign, and at least once a year. Between audits, add automated checks to your update process and test any new template or form by hand before launch.