The 20 Most Common WCAG 2.1 Failures We Found Across 2,481 Real Usability Test Findings

Key data points

• Across 15 independently tested digital products, 2,481 synthesized usability findings were tagged against a specific WCAG 2.1 success criterion, roughly one in three of all findings generated.
• One criterion, 4.1.2 (Name, Role, Value), was tagged more often than any other: 427 times, or roughly 17% of all WCAG-tagged findings.
• 1.3.1 (Info and Relationships) was second at 393 occurrences, followed by 2.4.6 (Headings and Labels) at 240 and 1.4.3 (Contrast Minimum) at 222.
• Of 531 findings rated “severe” across the whole dataset, 440 (83%) carried a WCAG tag, and 4.1.2 alone accounted for 178 of those, 40% of all severe, WCAG-tagged findings.
• 48% of all synthesized findings (regardless of WCAG tag) were flagged as “quick wins” (fixable without a major redesign), but that rate is not evenly spread across criteria, as the breakdown below shows.

Why a frequency-ranked list is more useful than a checklist

WCAG has 78 success criteria across three conformance levels, and most manual conformance checklists treat them as equally weighted line items. Real usability testing data tells a different story: a small number of criteria account for a disproportionate share of both the volume and the severity of what actually breaks for real users. Ranking failures by how often they were independently rediscovered across 15 different products (built by different teams, in different sectors, using different tech stacks) is a more useful prioritisation signal than treating a WCAG audit as a flat list, because it reflects which mistakes development teams make repeatedly rather than which criteria happen to be easiest to test for. One note on how to read the counts below. The occurrence figures are counts of WCAG tags, not of findings, and a single finding can be tagged against more than one criterion: the 20 criteria listed here carry 2,963 tags between them, against 2,481 WCAG-tagged findings, and any tags carried by the remaining 58 success criteria are additional to that. A percentage quoted against the 2,481 total therefore describes the share of WCAG-tagged findings carrying that tag, and those percentages overlap rather than summing to 100%.

The top 20 WCAG 2.1 criteria, ranked by frequency

Rank	Criterion	Name	What it means, in plain English	Occurrences	Level
1	4.1.2	Name, Role, Value	Every control must tell assistive technology what it is, what it does and what state it’s in. Example: a custom “Show more” toggle that a screen reader announces only as “clickable”, with no indication it’s a button or that it is now expanded.	427	A
2	1.3.1	Info and Relationships	Structure you can see on screen must also exist in the underlying code. Example: a heading that is only big bold text, so a screen reader reads it as ordinary body copy and users can’t jump between sections.	393	A
3	2.4.6	Headings and Labels	Headings and form labels must actually describe what follows them. Example: five sections on one page all headed “Overview”, so the heading list is useless for navigation.	240	AA
4	1.4.3	Contrast (Minimum)	Text must stand out enough from its background to be readable. Example: light grey helper text on a white form, which disappears for anyone with reduced vision or on a bright screen.	222	AA
5	3.3.2	Labels or Instructions	Form fields need a visible label, plus any formatting rules stated up front. Example: a date box with no label and no hint as to whether it wants DD/MM/YYYY or MM/DD/YYYY.	188	A
6*	1.1.1	Non-text Content	Images, icons and charts need a text description of what they convey. Example: a results chart saved as an image with no alt text, so a screen reader announces only “image”.	129	A
6*	2.4.4	Link Purpose (In Context)	Link text should make sense on its own, not just next to surrounding text. Example: a page where every link reads “Click here”, so a list of links gives no clue where any of them go.	129	A
8	2.4.3	Focus Order	Pressing Tab should move through the page in a sensible order. Example: Tab jumps from the first form field straight down to the footer, then back up to the middle of the page.	124	A
9	2.4.1	Bypass Blocks	There must be a way to skip past content repeated on every page, such as navigation. Example: no “Skip to main content” link, so keyboard users tab through 30 menu items before reaching the page itself.	120	A
10	3.3.1	Error Identification	When something goes wrong, say clearly what is wrong and where. Example: a red border appears around a field but no message explains what needs changing.	116	A
11	3.1.3	Unusual Words	Jargon, acronyms and technical terms should be explained where they appear. Example: “Enter your UTR” with nothing telling the user what a UTR is or where to find it.	111	AAA
12	4.1.3	Status Messages	Updates that appear without moving the cursor still need to be announced. Example: “3 items added to basket” flashes up on screen, but a screen reader user hears nothing and doesn’t know it worked.	108	AA
13	1.4.8	Visual Presentation	Long passages of text should be comfortable to read: line length, spacing, and user control over colours. Example: dense full-width paragraphs with cramped line spacing and no way to adjust them.	102	AAA
14	1.4.4	Resize Text	The page must still work when text is enlarged to 200%. Example: zoom in and the navigation overlaps the content, hiding the “Continue” button.	99	AA
15	2.1.1	Keyboard	Everything must be operable without a mouse. Example: a date picker that only opens on click, leaving keyboard users unable to enter a date at all.	95	A
16	3.1.5	Reading Level	Write plainly, or provide a simpler version alongside. Example: eligibility rules written in legal language that most readers would need to reread several times.	82	AAA
17	3.3.3	Error Suggestion	Don’t just flag an error: say how to fix it. Example: “Invalid password”, rather than “Password must be at least 8 characters and include a number”.	78	AA
18	2.4.5	Multiple Ways	People should have more than one route to find a page. Example: a form reachable only by clicking through four menu levels, with no search box and no sitemap.	77	AA
19	3.2.4	Consistent Identification	The same thing should be named and shown the same way throughout. Example: “Basket” on one page, “Cart” on the next and “Your order” on a third, all meaning the same thing.	62	AA
20	1.4.6	Contrast (Enhanced)	A stricter contrast standard (7:1) aimed at people with low vision. Example: mid-grey body text that scrapes past the basic AA check but is still tiring to read for long.	61	AAA

* 1.1.1 and 2.4.4 are tied on 129 occurrences and therefore share rank 6. Rank 7 is intentionally skipped, following standard competition ranking; the next criterion takes rank 8.

A striking feature of this ranking is how many high-frequency criteria are Level A, the baseline conformance level that most legal and procurement frameworks treat as non-negotiable. Eight of the top ten most-cited failures (4.1.2, 1.3.1, 3.3.2, 1.1.1, 2.4.4, 2.4.3, 2.4.1, and 3.3.1) are Level A, meaning teams are still shipping basic conformance failures at scale, well before AA or AAA considerations come into play.

What each of the top five actually looks like in practice

4.1.2, Name, Role, Value (427 occurrences). This is almost always a symptom of custom-built interactive components (dropdowns, tabs, sliders, modals, accordions) implemented with generic elements and JavaScript rather than native HTML controls or complete ARIA attributes. Assistive technology cannot announce what the control is or whether it changed state, so users report needing “trial and error” to operate it. Because this failure clusters in shared components rather than page content, it is one of the highest-leverage fixes available: correcting it once in a design system component resolves it everywhere that component is reused.

1.3.1, Info and Relationships (393 occurrences). Visual structure (headings, tables, form groupings, lists) that exists only as CSS styling rather than semantic markup. A sighted user perceives hierarchy from font size and spacing; a screen reader user hears a flat stream of text with no way to skip between sections or understand which label belongs to which field.

2.4.6, Headings and Labels (240 occurrences). Headings and form labels that exist but are vague, duplicated, or uninformative out of context: for example, five headings on a page all reading “Overview,” or a form label reading “Details” that doesn’t specify what type of details are required.

1.4.3, Contrast Minimum (222 occurrences). Text-to-background contrast below the 4.5:1 ratio required for normal-size text (3:1 for large text). This is the one criterion in the top five that automated scanners reliably catch, and yet it is still the fourth most common failure across 15 independently designed products, indicating that design review, not tooling, is the gap.

3.3.2, Labels or Instructions (188 occurrences). Form fields with no visible label, a placeholder used as a label (which disappears once the user starts typing), or missing instructions for required formatting (e.g., date format, password rules), a pattern that surfaces repeatedly in the findings tagged against forms specifically.

Severity is not evenly distributed either

Filtering to only the 531 findings rated “severe,” the ranking shifts slightly but the top criterion doesn’t change. As with the table above, these are counts of WCAG tags rather than of findings: 440 of the 531 severe findings carried a WCAG tag, and the ten criteria below carry 582 tags between them, because a single severe finding can be tagged against more than one criterion.

* 4.1.3 and 1.4.3 are tied on 38 occurrences and therefore share rank 6. Rank 7 is intentionally skipped, following standard competition ranking; the next criterion takes rank 8.

Two criteria, 2.4.3 (Focus Order) and 2.1.1 (Keyboard), jump up the ranking when filtering for severe findings specifically, despite ranking lower for overall frequency. Both concern whether a user can operate an interface at all using a keyboard alone, and both are consistent with why these findings are rated severe rather than moderate: unlike a missing label, which slows a user down, a keyboard trap or an illogical focus order can stop a task entirely.

What this means for engineering prioritisation

The data supports a simple prioritisation heuristic for teams that don’t have the resources to remediate every WCAG criterion at once: fix 4.1.2 and 1.3.1 in shared components first. Together these two criteria account for 33% of all WCAG-tagged findings and 65% of severe, WCAG-tagged findings in this dataset. Because both are structural (they concern how components are built, not what content says), remediating them in a design system or component library produces compounding returns across every page that reuses those components, a materially better return on engineering time than a page-by-page content audit, based on how concentrated these two failures are across 15 unrelated codebases.

Frequently asked questions

What is the most common WCAG failure found in real usability testing?

Across 2,481 WCAG-tagged findings from 15 independently tested digital products, WCAG 4.1.2 (Name, Role, Value) was the most common, appearing 427 times, roughly 17% of all WCAG-tagged findings and 40% of severe, WCAG-tagged findings.

Are Level A (basic) WCAG failures still common in production products?

Yes. Eight of the ten most frequently cited WCAG criteria in this dataset (4.1.2, 1.3.1, 3.3.2, 1.1.1, 2.4.4, 2.4.3, 2.4.1, and 3.3.1) are Level A, the entry-level conformance tier, indicating that basic conformance gaps remain widespread even in professionally built, tested digital products.

Which WCAG criteria are most associated with severe usability failures rather than minor ones?

Name, Role, Value (4.1.2), Info and Relationships (1.3.1), Focus Order (2.4.3), and Keyboard (2.1.1) accounted for the largest share of findings rated “severe” in this dataset: all four concern whether a user can operate an interface at all, rather than how efficiently they can do so.

About this analysis

Figures in this article are drawn from an anonymised aggregation of 15 independent usability testing projects conducted by See Me Please between late 2025 and mid-2026, covering government, financial services, healthcare, higher-education, and consumer digital products in Australia and the United Kingdom. WCAG tags were applied during test synthesis by reviewers assessing real task-based sessions, not automated scanning. All client and participant identities have been removed.