What We Check (and What We Don't)
An honest look at which WCAG checks WP Comply automates today, what still needs a manual audit, and what's coming in future updates.
Accessibility tools that promise “full compliance in one click” are selling a myth. No automated scanner can find every WCAG issue, and any vendor that claims otherwise isn’t being straight with you. We’d rather show you exactly where our line is.
This page explains what WP Comply detects automatically, what genuinely needs a human, and what we’re building next.
What WP Comply detects today
WP Comply scans the rendered HTML of every page and reports issues against these WCAG 2.1 Level AA criteria:
| Check | WCAG | What it catches |
|---|---|---|
| Image alt text | 1.1.1 | Images missing alt, non-decorative images with empty alt, image inputs without alt text |
| Heading hierarchy | 1.3.1 | Skipped heading levels (e.g. h1 → h3) |
| Form labels | 1.3.1 / 4.1.2 | Inputs with no associated <label> or accessible name |
| Link purpose | 2.4.4 | Generic link text (“click here”, “read more”) and ambiguous links |
| Page language | 3.1.1 | Missing lang attribute on <html> |
These rules run on every scan, in the free version. WP Comply Pro doesn’t add new detection rules — it acts on what the scanner already finds: generating alt text with AI, applying fixes server-side at render time, and producing compliance reports.
What automated scanning can’t fully catch
A scanner reads markup. It can’t experience your page the way a person using a screen reader or keyboard does. These areas need human review:
- Colour contrast (1.4.3). Reliable contrast checking means resolving the final, computed colours of text and its background — across stylesheets, gradients, background images, opacity, and overlapping elements. That can’t be determined accurately from server-side HTML parsing, so we don’t pretend to. (It’s on our roadmap below.)
- Keyboard operability & focus order (2.1.1, 2.4.3). Whether every control is reachable and the tab order makes sense requires actually operating the page.
- Dynamic ARIA states. Roles and states that JavaScript sets at runtime aren’t present in the static HTML we scan.
- Meaning, not just presence. We can tell you an image has alt text or a link has text — we can’t judge whether that text is genuinely meaningful to a human.
- Media alternatives (1.2.x). Captions, transcripts, and audio descriptions for video and audio.
- Cognitive & readability factors. Plain language, predictable behaviour, and clear instructions.
The honest bottom line: no automated tool — ours included — can verify full WCAG conformance. A significant share of success criteria require manual testing with assistive technology. Treat automated scanning as the fast first pass that clears the most common, highest-volume issues — not as a certificate of compliance.
What’s coming next
WP Comply is actively developed, and we expand the scanner with each release. Detection rules we’re working on for upcoming updates include:
- Colour contrast (1.4.3) from computed styles
- ARIA role and state validation (4.1.2)
- Focus-visibility and skip-navigation checks (2.4.1, 2.4.7)
- Additional link and keyboard checks
Want a specific check prioritised? Tell us — roadmap decisions are driven by what users actually run into.
Our recommendation
Use WP Comply to catch and fix the common issues quickly and to document your remediation efforts over time. For full WCAG conformance — especially when you’re addressing a legal requirement — pair it with a manual audit by an accessibility specialist.
WP Comply helps you do the work and keep a record of it. It does not constitute legal advice or guarantee protection from claims — see our Terms of Service for details.