Accessibility Statement for MakeWPCompliant.com

Conformance target

This site targets WCAG 2.2 Level AA. That is deliberately one version ahead of the WCAG 2.1 Level AA standard named by both the DOJ Title II rule and the HHS Section 504 rule.

We describe this as a target, not a certification. Nobody — including us — can prove full WCAG conformance with automated testing, and this page does not claim to.

What was tested, and how

Last audited August 15, 2026, using the same browser-driven harness we point at client sites: headless Chromium via Puppeteer 23.11.1, with axe-core 4.12.1 configured to the WCAG 2.2 AA ruleset, plus an independent keyboard-traversal pass.

• All 16 pages, at a 1920×1080 desktop viewport and as an iPhone 14 — 32 captures in total
• 3 scripted flows covering 9 interactive states a page-by-page scan cannot reach: the review form showing validation errors, the deadline finder across seven states including the hand-off into the request form, and the mobile navigation drawer open
• Content Security Policy violations, console errors and failed network requests, per page
• Every screenshot read by a person afterwards

Results

What automation could not decide

Automated accessibility tools have a third bucket besides pass and fail: results the tool could not resolve. It is where real failures hide, so we report it rather than rounding it to zero.

On this site that bucket contains 4 results, all in one state: the mobile navigation drawer open on the home page. The drawer covers the hero text, so the tool cannot determine what is behind that text. That is the drawer doing its job.

Each pair was then computed by hand against the navy the hero actually uses (#0c2340): the eyebrow at 7.4:1, the heading and bold text at 14.1:1, and the lead paragraph at 11.0:1 — against a 4.5:1 requirement. Those four results are recorded in our baseline as manually reviewed, with the reason and the date, so they stay visible instead of quietly disappearing.

What we did not test

Stating this plainly matters more than the numbers above.

• Screen readers. This site has not been through formal testing with NVDA, JAWS or VoiceOver. Automated browser testing is not a substitute for that, and we say the same thing to clients.
• Cognitive and language accessibility beyond ordinary editing care.
• Every browser and assistive-technology combination. Testing ran in one browser engine.
• Anything WCAG cannot express. A page can satisfy every success criterion and still be hard to use.

Choices we made to get here

Some of these are worth stealing.

• No gradient, image or translucent layer sits behind any text. Those are exactly what makes a contrast result undecidable, which is why this site has no manual-review queue to work through.
• Native elements before ARIA. The FAQ is <details>/<summary>, the deadline reference is a real <table>, and the select keeps its platform arrow.
• Everything works without JavaScript. The deadline finder is hidden until scripting is available, and the full reference table is always rendered underneath it. The review form validates on the server.
• Form control borders meet the 3:1 non-text contrast bar, which the decorative borders elsewhere on the site do not need to.
• Self-hosted fonts and no inline styles or scripts, so the Content Security Policy needs no unsafe-inline.
• Reduced motion is respected, and the one animation on the site is additive.

Found a problem?

Tell us and we will fix it. Accessibility problems on an accessibility company's website are embarrassing, which is a strong incentive — but the honest reason is that this is the same feedback loop we ask clients to use.

Use the review request form, or email mudmin@gmail.com. Please include the page, what you were trying to do, and the browser or assistive technology you were using.