Keeping WCAG 2.1 AA compliance across multiple WordPress sites means treating accessibility as a fleet problem. You scan every site on a schedule and sort findings by where they live (theme, plugin, or content). Then you fix shared templates once, send people to check what scanners can't judge, and keep a dated record of each site's state.
What does WCAG compliance across multiple WordPress sites involve?
It involves four jobs a single-site audit never has to handle. You keep an inventory of every site and its theme version. You deduplicate findings so one template bug doesn't look like 40,000 separate errors. You re-check after every deploy. And you store proof per site. The WCAG criteria stay the same. The bookkeeping is what changes.
Here's the scenario we hear most often. A marketing director at a franchise brand runs 300 location sites on one parent theme. Local managers edit their own pages, upload their own photos, and occasionally paste in a booking widget a vendor sent them. Then legal forwards a demand letter aimed at a competitor and asks, "Are we AA compliant?"
The closest thing to an answer is a consultant's PDF from 14 months ago. It covered the corporate site and five locations. Since then the theme shipped two updates, a new forms plugin went in, and location managers uploaded a couple thousand images with filenames for alt text.
Agencies end up in the same spot with different paperwork. You might run 300 client sites built on two or three starter themes. You might work for a school district, a county, or a university that runs dozens of departmental sites. Either way, someone eventually asks for the state of the whole portfolio, and they want it as of a specific date.
For public entities the standard is fixed. The Department of Justice's 2024 ADA Title II rule adopted WCAG 2.1 AA as the technical requirement for state and local government websites. We cover the dates in our post on the ADA website deadline and the six failures that show up on nearly every public site in where government WordPress sites fail WCAG 2.1 AA. This post is about running that work across hundreds of sites at once.
Why one-page-at-a-time audits fail at 300 sites
Manual audits done site by site cost too much and take too long. A full pass on 300 sites can run past $190,000 and most of a year. By the time the auditor reaches site 300, site 1 has changed. The result is an expensive report that describes a portfolio which no longer exists.
Here is the arithmetic, using assumptions you can swap for your own numbers. The W3C's WCAG-EM methodology recommends testing a structured sample of pages plus a random selection for each site. Call that 6 hours of skilled manual testing per site at $110 an hour.
| Approach | Hours per pass | Cost at $110/hr | Calendar time (one auditor, 40 hrs/week) |
|---|---|---|---|
| Manual sampled audit, every site | 1,800 | $198,000 | About 45 weeks |
| Fleet model, year one (deep template review + scheduled scans + monthly content spot checks) | About 700 | About $77,000 | Templates in 4 weeks, then ongoing |
| Fleet model, later years (theme releases + spot checks) | About 450 | About $49,500 | Ongoing |
The fleet model assumes two themes with eight page templates each at 10 hours per template, which comes to 160 hours. On top of that, people spot-check content on 10% of sites each month at 1.5 hours per site, which adds about 540 hours a year. Your numbers will differ. The shape of the result holds anyway: deep work on the shared parts, light and frequent work on everything else.
There's also a staffing cost that never shows up on an invoice. Agencies that try to absorb accessibility checks into general maintenance hours tend to watch those hours vanish. We broke that pattern down in what DIY WordPress hosting costs an agency every month.
How to triage WCAG issues across sites that share a theme
Sort every finding by where its fix lives: the theme, a shared plugin, editor content, or a third-party embed. Theme and plugin issues get fixed once and ship everywhere. Content issues get fixed per site by whoever owns that site. This one sort turns an unmanageable error count into a short list of tickets.
Raw scanner output at fleet scale is useless until you group it. Say a footer link fails contrast on 25 pages per site across 300 sites. That's 7,500 errors in a report, but only one line in a theme stylesheet. Group findings by rule, CSS selector, and template, and that pile collapses into a single ticket for a developer.
| Where it lives | Typical WCAG failures | Fixed once or per site | Who fixes it |
|---|---|---|---|
| Theme templates | Low contrast in the palette (1.4.3), no visible focus (2.4.7), missing skip link (2.4.1), missing lang attribute (3.1.1), heading order in header and footer | Once, ships on next theme release | Theme developer |
| Shared plugins | Unlabeled form fields (1.3.1, 3.3.2), carousels with no pause (2.2.2), mega menus that trap the keyboard (2.1.2) | Once per plugin, sometimes means replacing it | Developer |
| Editor content | Missing or meaningless alt text (1.1.1), skipped heading levels, "click here" links, color used as the only signal | Per site, per page | Site editors, with training |
| Documents and embeds | Untagged PDFs, videos without captions (1.2.2), booking and map widgets | Per item, or by the vendor | Content team, vendor |
The theme row is where a shared codebase pays off. With a block theme, you can set "custom": false under color settings in theme.json, and editors on all 300 sites can only pick from your tested, contrast-checked palette. Page builders make that harder to enforce, which is one of the maintenance tradeoffs covered in Full Site Editing vs page builders.
The plugin row deserves its own review cycle. A slider or forms plugin running on 300 sites multiplies every accessibility defect it ships with. The process in our WordPress plugin audit guide works for accessibility too: list what's installed fleet-wide, test each plugin's output once, and replace the ones that can't be fixed.
The documents row is usually the biggest backlog by volume, and it can't be fixed from the theme. If your sites publish agendas, menus, or brochures as PDFs, start with fixing the PDFs before the rest of the site.
What to automate and what a person has to review
Automate anything a rule can measure: contrast ratios, missing alt attributes, form label associations, ARIA validity, duplicate IDs, page language, and empty links or buttons. Send people to anything that needs judgment: keyboard paths through real tasks, whether alt text means anything, focus order, reading order, and whether error messages tell users how to recover.
According to Deque's 2021 study of real-world audit data, automated testing identified 57% of accessibility issues by volume. That's a useful number in two directions. It means scanners pull their weight on the repetitive stuff, which is exactly what multiplies across a fleet. It also means close to half of what an auditor or a plaintiff's tester will find needs a human to spot it. Tool choices are covered in our accessibility testing tools guide, so we won't repeat them here.
At fleet scale, the automated work has three jobs:
- A scheduled scan of every site, weekly or more often, so new content problems surface within days
- A check in the deploy pipeline that blocks a theme release if it introduces new failures, before the release reaches 300 sites (the setup is in our WordPress CI/CD pipeline guide)
- A per-site trend line, so you can see which sites are drifting and which editors need a refresher
Human review goes where it has the most reach. Each page template gets a keyboard-only pass and a screen reader pass (NVDA on Windows, VoiceOver on Mac and iOS) on every theme release. Someone tabs through the tasks people come to your sites for: find a location, book an appointment, submit a contact form. On top of that, each month a tester spot-checks content on a rotating sample of sites, looking at alt text quality, heading structure, and link wording.
This split also keeps the ticket queue sane. If you already run a multi-site maintenance process like the one in our WordPress agency workflow guide, accessibility findings slot into the same queues: theme tickets go to the dev backlog, content tickets go to the site owner.
How to prove WCAG 2.1 AA status on a specific date
Proof is a dated record per site, stored somewhere it can't be edited afterward. It lists which pages were tested and how they were chosen, which tools and versions ran, what they found, what a person checked by hand, and which known issues have a remediation date. Without that record, "we're compliant" is an opinion.
You need this record for demand letters, procurement questionnaires, accessibility conformance reports, and the internal question that started all this. A record that holds up has these parts:
- The date, scope, and sample: the timestamp, every URL tested, and how the sample was selected (WCAG-EM's structured plus random method is a defensible choice).
- Versions of the theme, the plugins, and the scanner and ruleset, so the result can be reproduced or explained later.
- The full automated output, raw and unfiltered, alongside the grouped tickets you made from it.
- A manual checklist showing which success criteria a person tested, on which templates, with their name and the date.
- Known issues: open failures, who owns each one, and a target date. Auditors and courts tend to read a candid open-issues list better than a perfect score nobody believes.
- An accessibility statement, meaning a public page on each site with a working way to report a barrier.
Store the record in versioned object storage or a document system that keeps every revision. A spreadsheet that anyone can overwrite proves nothing about last March. And keep in mind that a record describes a moment. It shows what you knew, when, and what you did about it. It isn't a legal guarantee, and no vendor can sell you one.
Where overlays and AI alt text tools fit in a fleet
Overlays don't belong in a fleet compliance plan. AI alt text tools do, as a drafting step with a human approving the output. An overlay adds a script on top of each page and leaves the underlying code, which is what auditors and your own records examine, unchanged. Alt text tools can clear a backlog of thousands of images faster than editors can type.
We've covered overlays at length in why an accessibility overlay will not get you to WCAG 2.1 AA. The regulatory picture backs that up. In January 2025 the FTC announced a $1 million settlement with accessiBe over claims that its overlay could make websites compliant. At fleet scale an overlay also means a third-party script on 300 sites, 300 license lines, and a team that believes the problem is handled when the theme still ships a missing focus outline.
Alt text generators are different, because what they produce is the fix itself: text stored in the media library. The catch is context. A model can describe "a brick storefront with a blue awning." It can't know that the image is the Elm Street location, or that the photo exists to show the wheelchair ramp to the left of the door. Our working rule is that decorative images get an empty alt="", informative images get a generated draft that an editor approves or rewrites, and images inside links or buttons describe the destination. Run the generator across the backlog, then route the drafts to the person who knows each site.
How often to re-check a WordPress portfolio for accessibility
Run automated scans weekly and on every theme or plugin deploy. Do human template reviews on each theme release. Spot-check content on a rotating sample of sites monthly. Run a full sampled audit once a year. That cadence catches regressions within days and keeps the dated record current without paying for a full manual pass.
The weekly scan matters most on sites where non-developers publish content. Location managers, department staff, and client marketers add pages every week, and content is the one category no theme fix can prevent. The deploy check matters most for the shared code, because a single bad theme release can take every site from passing to failing on the same afternoon.
The annual sampled audit is the one place a full manual pass still earns its cost. Pick 15-20 sites that represent your templates, plugins, and editor habits, test them in depth, and use the results to calibrate how far you trust the automated layer for the rest of the year.
Running portfolio accessibility audits through your host
TopSyde's Claude-powered audit runs across every site in a portfolio on a schedule and produces a report per site, plus a portfolio view. It runs from the hosting side, so there's nothing to install on each site and nothing an editor can deactivate. It's included with managed hosting, which starts at $89/mo per site.
The design choice we care most about is that it's a hosting feature, not a plugin. A plugin on 300 sites is 300 more things to update, 300 more chances for a site owner to turn it off, and more code running on every page load. Running the audit from outside the site keeps the sites lighter and the schedule consistent. If you want to see how the audit engine was built and what Claude is good and bad at in this job, we wrote that up in how we built an AI website audit tool with Claude.
Scheduled reports cover the automated half of the work and give you the dated, per-site history the proof section above calls for. The human half still has to happen. Someone has to tab through your booking flow and decide whether the alt text on a location photo says something useful. We don't claim the audit makes a site compliant on its own. What it does is show you which sites drifted this week, which findings trace back to the theme, and what the record looked like on any past date.
This sits alongside everything else on the hosting side: monitoring, backups, updates, and security from TopSyde Sentinel. If you're weighing that whole bundle, what managed WordPress hosting covers in 2026 lays out the scope. Agencies running client portfolios should start at our agency hosting page. Organizations with hundreds of their own sites, such as franchises, districts, and universities, can look at enterprise plans. Support responds in under 2 hours during business hours, and every plan comes with a 30-day money-back guarantee. Run your portfolio through a month of scheduled reports, compare them to the PDF you have now, and decide. Pricing per site is on the pricing page.
Frequently Asked Questions
Can an automated scanner certify a WordPress site as WCAG 2.1 AA compliant?
No. Automated tools catch roughly half of issues by volume (57% in Deque's 2021 study), and they can't judge keyboard flow, alt text meaning, or reading order. A credible conformance claim needs automated results plus a documented manual review.
How many pages should we test on each site in a large portfolio?
Test every page template in depth once per theme release, since templates are shared. For each site, a scheduled automated scan of all reachable pages plus a small rotating manual sample of content pages is usually enough. The W3C's WCAG-EM methodology describes how to pick a structured and random sample.
Does fixing the shared theme make every site compliant?
Yes for theme-level issues like contrast, focus styles, skip links, and page language, but not for content. Alt text, heading structure, link wording, PDFs, and embedded widgets are added per site and have to be checked and fixed per site.
Do AI-generated alt text tools meet WCAG 1.1.1?
They can, if the text accurately conveys the purpose of each image. Generated text often describes what's visible but misses why the image is there. A person who knows the site should approve or rewrite each draft, and decorative images should get an empty alt attribute.
What does TopSyde's portfolio accessibility audit cost?
It's included with TopSyde managed hosting, which starts at $89/mo per site. The audit runs on a schedule across all your sites and reports per site, with no plugin to install, and every plan carries a 30-day money-back guarantee.
Topics
Founder & Lead Developer
20+ years full-stack development, WordPress, AI tools & agents
Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.
