WCAG Coverage

WCAG 2.2 has 55 active Level A and AA success criteria. AllyProof runs automated rules that detect failure conditions for 25 of them. That is a statement about detection, not about conformance: a scan that finds nothing has ruled out the failure patterns its rules cover, and nothing more. This page explains what each category means and where the gap is.

What automated testing actually measures

The number quoted across the industry is 57%, and it is routinely misread. It comes from Deque's Automated Accessibility Coverage Report, which analysed roughly 2,000 audits covering 13,000+ pages and about 300,000 recorded issues. In that dataset, automated testing identified 57.38% of the total recorded accessibility issues.

That is a share of issue volume, not a share of success criteria. The same report is explicit that automated issues existed for only 16 of the 50 WCAG 2.1 Level A/AA success criteria it analysed. Automated rules cluster on the failures that occur most often — missing alt text, contrast, missing labels — which is why they catch a majority of issues while touching a minority of criteria.

So the honest statement is:

Automated accessibility testing identifies many common WCAG failure patterns, but it cannot establish WCAG conformance. In Deque's audit dataset, automated testing identified 57.38% of recorded accessibility issues — a share of issue volume, not the share of WCAG success criteria that can be fully evaluated automatically. Actual coverage varies by site.

AllyProof has not run its own published benchmark, so it does not quote a detection percentage of its own. What it does report is which criteria its rules cover and which they don't, criterion by criterion, in the tables below.

What a clean result means

A clean automated result means the scanner did not detect the failure patterns covered by its rules. It does not establish conformance with the success criterion as a whole.

This is why AllyProof never converts an absence of findings into a conformance claim. In a draft Accessibility Conformance Report, a criterion with no detected failure gets an evidence status ("Automated checks completed — no failure detected") and an empty Conformance Level for a human evaluator to fill in — not "Supports".

WCAG 2.2 — new in October 2023

WCAG 2.2 (W3C Recommendation, Oct 2023; ISO/IEC 40500:2025) added nine success criteria on top of WCAG 2.1 and removed one. Findings that map to one of the nine new criteria are tagged with a New in 2.2 pill on the issue detail page, so customers scoping against 2.2 can see at a glance which of their issues wouldn't have existed under the earlier standard.

• 2.4.11 Focus Not Obscured (Minimum) — AA
• 2.4.12 Focus Not Obscured (Enhanced) — AAA
• 2.4.13 Focus Appearance — AAA
• 2.5.7 Dragging Movements — AA
• 2.5.8 Target Size (Minimum) — AA
• 3.2.6 Consistent Help — A
• 3.3.7 Redundant Entry — A
• 3.3.8 Accessible Authentication (Minimum) — AA
• 3.3.9 Accessible Authentication (Enhanced) — AAA

4.1.1 Parsing is gone

SC 4.1.1 Parsing is obsolete and was removed in WCAG 2.2. It is not an active WCAG 2.2 requirement, and AllyProof does not report it as one.

The scanner still runs duplicate-ID and malformed-markup rules because they remain useful quality signals and can expose failures of other criteria. W3C now says 4.1.1 should be considered always satisfied for HTML and XML, and that the effects of duplicate IDs or malformed markup should be reported under the criterion they actually affect. Older-standard editions retain a clearly labelled legacy 4.1.1 row for structural completeness, but AllyProof does not automatically assign it a conformance level.

How AllyProof categorises criteria

The categories describe the evidence automation can produce, not how "automatable" a criterion is. Nothing here implies a clean result proves conformance.

Category	Meaning
Automated failure detection available	Rules reliably detect this criterion's common failure conditions. A detected failure is solid evidence of a problem; a clean result is not evidence of conformance.
Partially testable with automation	Rules catch some failure conditions. Substantial parts of the criterion are outside what any scanner can observe.
Manual evaluation required	No automated rule covers this criterion. It needs a human.

Rule catalog — difficulty & verification

Each issue detail page uses a static rule catalog that, where we've seen the rule often enough to calibrate, tells you:

• Difficulty band — easy (mechanical markup, under 5 min), medium (code + minor design decision, 5–20 min), hard (design review, content rewrite, or architectural change, over 20 min).
• Time estimate — rough median minutes to fix one occurrence, visible in the Effort row of the metadata strip.
• AT verification recipe — tool (NVDA, VoiceOver, JAWS, keyboard, DevTools) and numbered steps for confirming the fix. Rendered as a "Verify with NVDA" section beneath the AI fix suggestion, so QA who aren't full-time a11y specialists can complete the manual check.

The issue list also has a Quick wins chip that filters the current site's open issues down to the easy difficulty band — useful for answering "what can a junior pick off this afternoon?" without writing JQL.

Coverage by WCAG principle

Counts are derived from AllyProof's criteria catalog, which holds the 55 active WCAG 2.2 A/AA success criteria.

Principle	Active A/AA criteria	Automated failure detection	Partially testable	Manual evaluation required
1. Perceivable	20	4	8	8
2. Operable	20	5	3	12
3. Understandable	13	2	1	10
4. Robust	2	1	1	0
Total	55	12	13	30

Criteria with automated failure detection

Rules exist that reliably detect this criterion's common failure conditions. Read each line as what a failure looks like to the scanner — not as a checklist the criterion is satisfied by.

• 1.3.1 Info and Relationships — detects heading-structure, form-label and table-markup failures. It cannot confirm that every visual relationship is programmatically represented.
• 1.3.4 Orientation — detects orientation locks in CSS and viewport metadata.
• 1.4.3 Contrast (Minimum) — computes foreground/background contrast ratios where both are resolvable.
• 1.4.12 Text Spacing — detects declarations that prevent user text-spacing overrides.
• 2.4.1 Bypass Blocks — detects the absence of a skip link or landmark structure.
• 2.4.2 Page Titled — detects a missing or empty <title>. It cannot judge whether the title describes the page.
• 2.4.4 Link Purpose (In Context) — detects empty links and known non-descriptive link text. It cannot judge whether the purpose is clear from context.
• 2.5.3 Label in Name — detects visible labels not contained in the accessible name.
• 2.5.8 Target Size (Minimum) — measures rendered target dimensions against the 24×24 CSS-pixel minimum.
• 3.1.1 Language of Page — detects a missing or invalid lang attribute on <html>.
• 3.1.2 Language of Parts — detects invalid lang values on inline elements. It cannot detect unmarked passages in another language.
• 4.1.2 Name, Role, Value — validates ARIA roles, states and properties, and detects controls with no accessible name. It cannot confirm name, role and value are correct in every application state.

Partially testable with automation

Rules catch some failures and cannot see the rest. A clean result here is weaker evidence still.

• 1.1.1 Non-text Content — detects missing or empty alt. Cannot judge whether the text alternative is appropriate.
• 1.3.2 Meaningful Sequence — detects some CSS-reordering patterns. Cannot assess whether reading order is meaningful.
• 1.3.5 Identify Input Purpose — detects missing autocomplete on likely fields. Cannot verify the token is the correct one.
• 1.4.1 Use of Color — detects some colour-only link distinctions. Cannot find every information-by-colour case.
• 1.4.2 Audio Control — detects autoplaying media elements. Cannot assess whether a control is discoverable.
• 1.4.4 Resize Text — detects fixed font sizing. Cannot verify layout at 200% zoom.
• 1.4.10 Reflow — detects horizontal overflow at the reflow viewport. Cannot judge content loss.
• 1.4.11 Non-text Contrast — measures contrast on identifiable UI boundaries. Cannot evaluate every graphical object.
• 2.2.2 Pause, Stop, Hide — detects auto-updating and animated content. Cannot confirm a working pause mechanism.
• 2.4.3 Focus Order — detects positive tabindex and similar anti-patterns. Cannot assess whether the order preserves meaning.
• 2.4.6 Headings and Labels — detects empty headings and labels. Cannot assess whether they are descriptive.
• 3.3.2 Labels or Instructions — detects missing labels. Cannot assess whether instructions are adequate.
• 4.1.3 Status Messages — detects live-region markup. Cannot confirm status changes are actually announced.

Manual evaluation required

Thirty of the 55 criteria have no automated rule at all. They need human judgment, assistive-technology testing, or evaluation of meaning. Examples:

• 1.2.1–1.2.5 Time-based Media — require human evaluation of captions, audio description and transcripts
• 1.3.3 Sensory Characteristics — instructions relying on shape, colour, size or location
• 2.1.1 Keyboard and 2.1.2 No Keyboard Trap — require actually operating the interface without a mouse
• 2.2.1 Timing Adjustable — requires exercising session timeouts and timed interactions
• 2.4.5 Multiple Ways — requires assessing site-wide navigation alternatives
• 2.4.7 Focus Visible — requires judging indicator visibility in real states
• 3.2.3 Consistent Navigation — requires cross-page comparison
• 3.3.3 Error Suggestion and 3.3.4 Error Prevention — require exercising form validation and confirmation steps

The Manual AT Verification page has step-by-step recipes for verifying specific fixes by hand.

Why not 100%

Many WCAG criteria are about intent and meaning, which automated tools fundamentally cannot assess:

• Is this alt text accurate? (Tools can verify it exists, not that it is right.)
• Are these instructions clear? (Requires human comprehension.)
• Does the reading order make sense? (Requires understanding the content.)
• Are captions synchronised and accurate? (Requires watching the video.)
• Can a user complete a task using only a keyboard? (Requires interactive testing.)

This is an inherent limitation of every automated accessibility tool, not something specific to AllyProof. What AllyProof commits to is being explicit about which side of the line each criterion falls on, so a clean scan is never mistaken for a conformance result.