How MakeWPCompliant Works
Seven steps from the site you have today to a site whose accessibility problems have been found, attributed, fixed, and demonstrably fixed.
-
Understand the site
We begin by understanding the WordPress implementation and the parts of the site that matter most. That may include important page templates, public service pages, forms, ecommerce, logged-in areas, mobile navigation, high-traffic content, third-party integrations, regulatory requirements, and any known complaints or audit findings.
The objective is to test a meaningful representation of the site rather than blindly crawl thousands of nearly identical URLs and call the resulting number a scope.
-
Establish a baseline
We run repeatable tests against representative pages and important user states. Findings are documented with stable identifiers so they can be compared as remediation progresses — which is what makes “we fixed it” a checkable claim rather than an assertion.
-
Attribute problems
Where possible, we determine whether an issue belongs to:
- The theme
- A page builder
- A plugin
- WooCommerce
- Custom code
- Page content
This matters because a theme problem appearing on 500 pages should be fixed once in the theme, not 500 times in the editor. Attribution is what turns a finding count into a work plan.
-
Remediate
We make the appropriate changes on a staging or development copy of the website — not by experimenting in production. That can include PHP, templates, CSS, JavaScript, WordPress configuration, plugin configuration, or content changes.
-
Retest
The same pages and workflows are tested again. This creates a clear before-and-after record, and it catches the failure mode nobody talks about: a fix that simply moved the problem somewhere else.
-
Review what automation cannot decide
Some findings require human judgment. Some WCAG criteria are not reliably automatable at all. We separate those items out and work through them, instead of pretending software answered a question it cannot answer.
-
Deliver and maintain Step 7 optional
We provide a summary of the work performed, the known remaining items, and our recommendations. Where it makes sense, ongoing regression testing can be added — but it is not a condition of the remediation work.
What you get at the end
- Baseline findings, grouped by the layer that owns them
- Before-and-after comparisons for the work performed
- Screenshots of the states that were tested
- Remaining manual-review items, listed rather than omitted
- Accepted exceptions, with the reason recorded
- A final remediation summary a non-developer can read
Fix the site, not just the score
Find out what is actually causing accessibility problems in your WordPress website — and what real remediation would involve.