WCAG Audit Service for WordPress Websites

Most people who ask us for an audit already have a list of problems from somewhere. A free scanner flagged two hundred contrast errors, a vendor email warned about ADA exposure, or a customer wrote in to say the booking form would not work with a keyboard. What they do not have is a clear picture: which of those problems are real, which matter most, and how much of the site is affected. That picture is what a WCAG audit service is supposed to produce. This page explains how we run ours on WordPress sites, what you get at the end, and how to tell a useful audit from a long PDF that nobody can act on.

What our WCAG audit service covers

An audit is a structured review of your site against a named standard. We audit against WCAG 2.2 at Level AA, the W3C guideline that serves as the benchmark most US demand letters, settlements and accessibility reviews refer to. If you are not sure what WCAG is, our short explainer on what the WCAG standard actually is covers the background, and the guide to what WCAG 2.2 AA asks of a business site groups the criteria by what an owner sees on screen.

The audit itself is a diagnosis. We look, we record, we explain. We do not change anything on your site during the audit, which means you can read the findings, decide what to do and choose who does it. If you want us to take on the fixes that follow the audit findings as well, we can, but the report is written so any competent WordPress developer can work from it.

A typical engagement covers:

• An agreed sample of page templates and key user journeys (more on choosing these below).
• Automated scanning of every page in the sample, with results checked by a person rather than pasted in.
• A keyboard-only pass through each template and journey.
• Screen reader checks with NVDA on Windows and VoiceOver on Mac or iPhone.
• Zoom, reflow and text spacing checks on each template.
• An editorial read of the sampled pages: heading outline, link wording, alt text, color cues and embedded media.
• A written report mapping every issue to a WCAG success criterion, with severity and a suggested fix.
• A walkthrough call to go through the findings and the order we would tackle them in.

Scoping: sampling templates instead of every URL

A WordPress site with four hundred blog posts does not have four hundred different designs. It usually has a handful of templates: the home page, a standard page, a blog post, an archive or category listing, a contact page, maybe a landing page built in Elementor or Divi, and on a store the product, cart, checkout and account pages. Auditing one good example of each template, plus every page that behaves differently, finds nearly every pattern-level problem on the site. A broken focus style in the header shows up on every page; you only need to find it once.

So the first step is an inventory. We crawl the site, group URLs by template and by the plugins that render them, and propose a sample. The sample always includes:

• One page per distinct template, chosen because it has the most components on it.
• Every form that matters to the business: contact, quote request, booking, donation, job application, newsletter signup.
• Complete journeys, not just pages: search to product to cart to checkout, or service page to booking confirmation.
• Pages with unusual content: a pricing table, an embedded map, a video gallery, a page full of downloadable PDFs.
• Anything a complaint or demand letter mentioned by URL.

We send you the proposed sample before testing starts. You know which pages earn revenue or bring in calls, and you can tell us if we picked the wrong ones. Documents such as PDFs are listed separately, because checking them is a different job and they can easily outnumber the web pages.

The audit method: four passes on every sampled page

Each template goes through the same four passes, in the same order, so findings are consistent across the report.

Pass one: automated scan, then a human review of it

We run axe DevTools and WAVE on each page in the sample. Scanners are fast and good at certain things: missing form labels, empty buttons, missing alt attributes, many contrast failures, duplicate IDs. They are also noisy. They flag things that are fine and miss things that are badly broken. Every automated result is reviewed before it goes into the report, and false positives are removed rather than left for you to puzzle over. Why machines and people catch different things is explained in our post comparing automated and manual accessibility testing.

Pass two: keyboard

We put the mouse away and work through the page using only the keys a keyboard user relies on: Tab forward, Shift+Tab back, Enter and Space to activate, arrows inside widgets, Escape to close. We are watching where focus goes, whether it is visible, whether menus and popups can be opened and closed, and whether anything traps the keyboard. This is where hover-only dropdown menus and cookie banners that cannot be dismissed usually turn up.

Pass three: screen reader

We listen to the page with NVDA and VoiceOver: the heading outline, the landmarks, the link list, form fields and what happens after a form is submitted. A page can look perfect and still announce “button, button, link, graphic” with no names attached.

Pass four: zoom, reflow and content

We zoom the browser, narrow the viewport and apply text spacing overrides to see whether content overlaps, gets cut off or forces sideways scrolling. Then we read the content as an editor would: are headings real headings, do links make sense out of context, do informative images have useful alt text, is color the only signal anywhere. The hands-on parts of passes two to four are the same work we sell on its own as manual accessibility testing with keyboard and screen readers, when a client already has an audit and only needs a human check.

How WCAG 2.2 Level AA criteria are checked

An audit should say which criteria were tested and how. Ours lists every Level A and AA success criterion in WCAG 2.2 with one of four results for the sampled pages: passes, fails, not applicable, or needs your input (for example, whether a video has an approved caption file somewhere we cannot see). That table is part of the report, so you can see coverage at a glance rather than trusting a summary.

Criteria added in WCAG 2.2 get specific attention because older themes and plugins were built before they existed. Four that regularly fail on WordPress sites:

• 2.4.11 Focus Not Obscured (Minimum): a sticky header or a chat button sits on top of the element that has keyboard focus, so you cannot see where you are.
• 2.5.8 Target Size (Minimum): social icons, pagination numbers and close buttons smaller than 24 by 24 CSS pixels, with no spacing to compensate.
• 3.3.7 Redundant Entry: a multi-step form asks for the same address twice without filling it in or offering to.
• 3.3.8 Accessible Authentication (Minimum): a login or account page that relies on a puzzle CAPTCHA with no alternative.

WCAG 2.2 also removed 4.1.1 Parsing. Broken markup is no longer a failure in itself, so we only report it when it causes a real problem elsewhere, for example a duplicate ID that makes a screen reader read the wrong label for a field. That keeps the report focused on what people actually run into.

The audit report: what you receive

The report is the deliverable, so it has to be usable by three people: the owner who needs to decide, the developer who needs to fix, and, if there is a legal matter, the lawyer who needs to understand what was found and when. Our report has these parts:

1. Summary. Two pages in plain English: the scope, the overall state of the site, the barriers that block tasks outright, and our recommended order of work.
2. Scope and method. The exact URLs tested, the date, the browsers, the screen readers and versions, and the tools used.
3. Issue list. Each issue has a title, the WCAG criterion it fails, severity, the templates and URLs where it appears, steps to reproduce it, what a user experiences, and a suggested fix written for WordPress (which template file, block, plugin setting or content change is likely involved).
4. Criteria table. The pass, fail and not applicable result for every A and AA criterion.
5. Third-party list. Components we found problems in that you probably cannot edit directly: a payment iframe, an embedded booking widget, a chat vendor. These need a vendor conversation or a replacement decision.
6. Spreadsheet export. The same issue list as a sheet, so it can be loaded into whatever task tracker your team uses.

If you want to know what separates a good report from a weak one in general, including red flags, the post explaining how to read an accessibility audit report is written for exactly that.

Prioritizing findings so the fix list makes sense

A flat list of seventy issues is not a plan. Every finding gets a severity based on what it does to a real person trying to use the site, not on which tool raised it:

Severity	What it means	Example on a WordPress site
Blocker	A user cannot complete a key task at all	The checkout “Place order” button cannot be reached by keyboard
High	A task is possible but very hard or confusing	Form errors appear only as red borders with no text
Medium	Content or navigation is degraded but usable	Heading levels jump from H2 to H5 on service pages
Low	Minor friction or an isolated content issue	One decorative image has alt text that repeats the caption

Within each severity we then sort by reach. A blocker in the site header affects every page and comes first; a blocker on a rarely used archive page comes later. We also flag quick wins: issues that take minutes to fix in a theme setting or the block editor but remove a real barrier. Clearing those early builds momentum and shrinks the list before the harder template work starts.

What we need from you before testing starts

An audit goes faster and finds more when we can see the site the way your customers and staff do. Please have these ready:

• A list of key pages and forms. The pages that bring in leads or sales, and every form people submit.
• Test accounts. If there is a login, a member area, or a customer account on a store, a test account at each relevant role.
• A way to test checkout or booking without real charges. A staging copy, a test payment mode, or a coupon that zeroes an order, agreed with whoever runs the store.
• Admin or editor access, read-only if you prefer. Not strictly required for testing, but it lets us name the exact theme template, block or plugin behind each issue, which makes the suggested fixes far more precise.
• Anything you have already received. A previous audit, a customer complaint, scan results, or, if there is one, the technical list attached to a demand letter. If a lawyer is involved, they decide what is shared; we are not lawyers and the audit is not legal advice.

If you have a staging site, we test there when it matches production. If it is months out of date, we test the live site, carefully, without submitting forms that would trigger real emails to customers.

How to judge whether an audit was worth it

When the report arrives, a few checks tell you whether the work was real:

• Can you reproduce an issue yourself? Pick three findings and follow the steps. If the steps are vague or the issue is not there, ask why.
• Are there findings no scanner could have produced? Keyboard order problems, confusing screen reader announcements, focus hidden behind a sticky header. If every finding reads like scanner output, the manual passes were thin.
• Does it name your actual components? “The Mega Menu dropdown in the header template” is useful. “Ensure interactive elements are accessible” is not.
• Is the language careful? A responsible audit describes conformance against WCAG for the pages tested on the dates tested. It does not certify a site, and it does not say the site is now legally safe. Anyone claiming that is overselling. Our own reports never use the words compliant or certified about your site, and we do not say what a court or a plaintiff’s lawyer would make of the findings.

The honest outcome of a first audit on most sites is a substantial list. That is normal, and it is the point: you now know what to fix.

Common audit mistakes owners make

• Auditing only the home page. The home page is often the most polished template. The contact form and checkout are where people actually get stuck.
• Treating a scan score as an audit. A clean Lighthouse or scanner result means the automated rules passed. It cannot tell you if someone using NVDA could get through your appointment form.
• Auditing during a redesign. If a new theme launches next month, audit the new build on staging instead of the site that is about to disappear. If the current site is beyond repair, the page on rebuilding with accessibility designed in covers that route.
• Installing an overlay widget while waiting. It does not change the underlying markup the audit is measuring, and it can add its own keyboard and focus problems that then show up as findings.
• Filing the report and moving on. An audit is a snapshot. Plugins update, editors add pages, and the findings slowly stop matching the site.

Doing your own review or hiring an auditor

You can learn a lot on your own. Our small business accessibility checklist and a free scan from the WAVE checker from WebAIM will surface obvious problems in an afternoon, and if you only want a quick outside opinion first, there is a free accessibility check of a few key pages that is clearly smaller than an audit.

A self-review gets harder when the site has custom components, a store, several form plugins, or when someone outside the business will read the result. At that point you need consistent method, criteria mapping and reproducible steps, and you need someone who tests with screen readers routinely and can tell a real barrier from a tool’s guess. A rough guide:

• Small brochure site, no forms beyond a simple contact form, no complaint: a careful self-review is a reasonable start.
• Any store, booking system, member area or donation flow: a full audit is worth it, because those journeys are where barriers cost you customers.
• A complaint, demand letter or contract requirement: get an independent audit with a dated report, and let your lawyer handle the legal side.

Questions to ask before you buy a WCAG audit service

Put these to us or to any other firm offering website accessibility audit services. The answers quickly show who does real testing:

1. Is the benchmark WCAG 2.2 AA, and does every finding in the report point to a specific success criterion?
2. How do you choose the pages in scope, and will I approve the sample first?
3. Which screen readers and browsers do you test with, and are those passes done by a person?
4. Can I see a redacted sample report?
5. Do your suggested fixes refer to WordPress specifics, or are they generic?
6. Do you remove false positives from automated results before they reach me?
7. What wording do you use about the outcome? (Walk away from anyone who promises a compliant or lawsuit-free site.)
8. If I hire someone else for the fixes, will your report still make sense to them?

After the audit: fixes, retesting and keeping the site clean

A WCAG audit service is only step one of three. Step two is the fix work, ideally in severity order with each fix retested. Step three is keeping it that way: WordPress sites change every month through plugin updates, new content and new forms, and each change can reintroduce something the audit already caught. That is why we offer monthly accessibility monitoring after the audit, and why accessibility checks belong in the same routine as ongoing WordPress maintenance rather than in a separate yearly panic.

If you want to see how the audit fits into the wider sequence of audit, fix and monitor, the overview of our accessibility work for US businesses lays out all the services side by side. And if you later need a public page describing your commitment and how people can report problems, the audit gives you the facts to write an honest website accessibility statement.

WCAG in practice: Guides

Step-by-step guides on the individual tasks behind this service:

• WCAG 2.2 AA Requirements: A Plain Guide for Owners
• WCAG 2.2 vs 2.1: What Changed and Which to Target
• WCAG Levels A, AA and AAA: What Each One Means
• The POUR Principles of WCAG, With Everyday Examples
• WCAG Color Contrast: Ratios, Tools and Brand Fixes
• WCAG Focus Indicator: Visible Focus That Works
• WCAG Target Size: The 24 by 24 Pixel Rule in Plain Words
• Skip Link Accessibility: Test and Fix Skip to Content
• ARIA Labels Explained: When They Help and When They Hurt
• Heading Structure for Accessibility: Get the Levels Right
• Descriptive Link Text: Fixing Read More and Click Here
• WCAG Reflow and Resize Text: Testing With Browser Zoom