The complete WordPress accessibility audit: from scanner output to remediated production code.

"Accessibility audit" means very different things to different vendors. Some run a Lighthouse scan, generate a 40-page PDF, and call the work done. Others spend a quarter hand-testing every interactive component on every template. A WordPress accessibility audit that actually reduces risk and improves the user experience is structured: it combines automated scanning, manual assistive-technology testing, remediation in the actual codebase, and post-remediation validation. Here's what each phase contributes, where each one falls short alone, and what the deliverable should look like.

The market for “accessibility audits” on WordPress is genuinely confused. The same word covers everything from a 10-minute browser-extension scan to a 3-month multi-disciplinary engagement that rewrites half the site’s components. Both end with a PDF; only one results in a site that’s actually more accessible. Telling them apart matters, because the price difference is significant and the legal risk if you bought the wrong one is real.

The accessibility audit that holds up under WCAG 2.2 AA scrutiny — and, importantly, under an ADA Title III demand letter or an EAA enforcement review — has four phases. Each phase catches a category of issue the previous one couldn’t, and each phase ends with code that’s measurably more accessible than it was before.

Phase 1: Automated and AI-assisted scanning.

Every audit starts with the scanner pass: Lighthouse, WebAIM’s WAVE, axe-core. Each one finds a real set of issues: missing alt attributes, contrast ratios below 4.5:1, form fields without labels, invalid ARIA usage, heading-level skips. These are bugs and they should be fixed. They’re also less than half the actual accessibility surface.

The recent addition to this phase is AI-assisted code review. Tools like Anthropic’s Claude or OpenAI’s GPT-4-class models can read component code and flag issues scanners miss: state mismatches between visible UI and ARIA, focus-management bugs in custom modal implementations, semantic-HTML antipatterns that don’t break a scanner check but break real usage. The AI pass doesn’t replace human review; it adds a layer that catches contextual problems the scanners can’t see.

The output of Phase 1 is a catalogued list of structural issues, plus an inventory of the templates and components that need deeper review in Phase 2. What automated WCAG scans catch — and the categories they fundamentally can’t covers the structural limits in detail.

Phase 2: Manual and assistive-technology testing.

This is the phase that distinguishes a real audit from a scanner-only one. The categories of issue that only surface in manual testing:

• Screen reader experience. Does the page read naturally in the order a user navigates it? Are dynamic content updates announced? Do interactive controls expose what they’re for? Does the focus order match the visual order? Why WordPress sites need real screen-reader testing covers what only this layer surfaces.
• Keyboard-only navigation. Can every interactive element be reached and activated with the keyboard alone? Is the focus visible on every focusable element? Are there keyboard traps (places where focus gets stuck)? Modal dialogs are the most common failure point; carousels and custom dropdowns are the next.
• Zoom and reflow. WCAG 2.2 AA requires the page to remain usable when zoomed to 400% or when text spacing is increased to specific thresholds. Most WordPress sites have at least one component (typically a navigation bar, a sidebar, or a fixed-position element) that breaks under these conditions. The fix is rarely small.
• Reduced motion and color-only signals. Components that rely on motion or color alone to convey information fail for users who’ve disabled motion or who can’t distinguish the color difference.

The realistic Phase 2 is half a day to two days of testing per major template, depending on complexity. The output is a deep list of issues that no scanner found.

Phase 3: Active remediation in the codebase.

The phase that turns the audit into accessibility. Reading a 40-page PDF doesn’t fix anything. The remediation work means going into the WordPress theme, the custom components, the ACF flexible content layouts, and changing the code that produced the broken experience.

What this looks like in practice on a typical WordPress site:

• Semantic HTML structure. Heading levels are reordered to match the page’s actual hierarchy. Lists become real <ul>/<ol> elements. Elements that trigger on-page actions become <button> tags; elements that navigate to new URLs become <a> tags, regardless of how they are visually styled.
• ARIA refinement. Landmarks (<main>, <nav>, <aside>, <footer>) are added where missing. aria-label, aria-labelledby, and aria-describedby are corrected where they reference wrong elements. ARIA role values are cleaned up where they conflict with the underlying semantic element.
• Focus management. Modal dialogs are wrapped in proper focus traps. Custom dropdowns expose the standard combobox pattern. Skip-to-content links are added where they’re missing.
• CSS for accessibility. Visible focus indicators are added where the design suppressed them. Contrast ratios are corrected to meet WCAG thresholds. Touch targets are sized to meet WCAG 2.2’s new 24×24 minimum.
• Dynamic content announcements. Form validation messages, search results, “added to cart” confirmations all get aria-live regions so screen readers announce them.

This is the phase where most “audits” stop without doing anything. They hand the client a list and expect the client’s developer to remediate. A serious audit includes the remediation in scope, because the issues are interconnected and only the team that found them has full context for the fix.

Phase 4: Post-remediation validation.

After the fixes ship, the full Phase 1 + Phase 2 testing runs again. The goal is two things:

• Confirm the fixes worked. Each identified issue is verified resolved against WCAG 2.2 AA criteria.
• Confirm the fixes didn’t break something else. Accessibility regressions during remediation are common; fixing one ARIA pattern can break a state announcement somewhere else. The re-test catches this.

The output of Phase 4 is a clean compliance summary: a “before and after” statement, the list of fixes applied, the verified WCAG status of each tested template. This is the document that holds up if the site is later challenged. “We ran a scanner and got 95” is not a defense; “we executed a documented four-phase audit, here are the resolved issues, here is the re-test confirming WCAG 2.2 AA” is.

The continuous-monitoring add-on.

A real audit produces a snapshot. Sites change. Content updates, new components ship, plugins update, themes get patched, and accessibility regressions creep back in. The realistic ongoing pattern:

• Monthly automated scans against the production site, with flagged issues triaged and the new ones fixed.
• Quarterly manual screen-reader testing on the highest-traffic templates.
• Annual full-audit cycle for high-stakes sites in regulated industries.

The audit is the foundation. The monitoring is what keeps the foundation from cracking. Together they’re the only sustainable answer to “is this site WCAG 2.2 AA compliant?” — an answer the scanner alone can’t give and the audit alone can only give about one point in time.

What this is worth.

The economics: a four-phase audit on a moderately complex WordPress site runs in the low five figures and takes two to four weeks. The alternative is the slow accumulation of legal exposure (ADA Title III lawsuits run six figures in settlement), the user-experience cost of an inaccessible site (which is invisible until it isn’t), and the reputational cost of being publicly cited for accessibility failures.

The math is straightforward. For any site where accessibility is a real concern — government, healthcare, education, financial services, any site of meaningful scale — the audit pays for itself the first time it would have otherwise been the subject of a demand letter.

See accessibility that holds up for what this looks like as a service.