Most websites that fail an accessibility audit fail it on the same short list of WCAG 2.2 success criteria, and knowing which ones those are tells you where to start. If you own a website, run an online shop, or answer for accessibility compliance before the European Accessibility Act or a procurement review, you don’t need to start with all 86 success criteria. Fixing the handful that fail most often removes most of the risk, and many of those fixes take an afternoon.
This article covers the WCAG 2.2 success criteria that fail most often in real audits, why they keep failing, and how to fix them so they stay fixed after the next redesign.
What the Large-Scale Data Shows
The best public dataset is the WebAIM Million, an annual automated scan of the top one million homepages. In the 2024 and 2025 editions, roughly 95% of homepages had at least one detectable WCAG failure, with an average of more than 50 errors per page. The same six problems top the list every year.
Low-contrast text was found on close to 80% of homepages. Missing alternative text for images appeared on more than half. Missing form input labels came next at just under half, followed by empty links, empty buttons, and a missing document language attribute.
Mapped to WCAG, those failures are 1.4.3 Contrast (Minimum), 1.1.1 Non-text Content, 1.3.1 Info and Relationships together with 3.3.2 Labels or Instructions, 2.4.4 Link Purpose (In Context), 4.1.2 Name, Role, Value, and 3.1.1 Language of Page. None of these are new in WCAG 2.2. They have been in the standard since WCAG 2.0 in 2008. They still fail because they slip back in with every content update, theme change, and new plugin.
The Classic Failures and Why They Persist
1.4.3 Contrast (Minimum) requires a ratio of 4.5:1 for normal text and 3:1 for large text, meaning 18pt or 14pt bold. The usual culprit is a brand palette chosen before anyone checked contrast: light grey placeholder text, white text on a mid-tone brand color, or a disabled-looking secondary button. Its companion 1.4.11 Non-text Contrast requires 3:1 for input borders and focus indicators, and it fails just as often but gets checked far less.
1.1.1 Non-text Content fails in two directions. Images have no alt attribute at all, or the alt text is the file name, such as “IMG_4471-final-v2.jpg”. The reverse mistake is just as common: decorative images described at length, so screen reader users have to listen through noise. Decorative images need alt=””, not a missing attribute.
4.1.2 Name, Role, Value is where icon-only buttons fail. A hamburger menu, a search magnifier, or a social icon made with an SVG and no accessible name is read out as “button” and nothing more. An experienced accessibility auditor first tabs through the header and footer with NVDA or VoiceOver running, because that is where most unnamed controls sit.
WCAG 2.2 Criteria That Catch Updated Sites Off Guard
WCAG 2.2 became a W3C Recommendation on 5 October 2023. It added nine success criteria, six of them at Level A or AA, and removed 4.1.1 Parsing. The new criteria that fail most often in audits are these:
2.4.11 Focus Not Obscured (Minimum), AA fails when a sticky header, chat widget, or cookie banner completely covers the element that has keyboard focus. 2.5.8 Target Size (Minimum), AA requires interactive targets of at least 24 by 24 CSS pixels, or enough spacing around them. Small pagination links, close icons, and inline footer links often fail it.
3.3.8 Accessible Authentication (Minimum), AA fails when login requires a cognitive function test, such as a puzzle CAPTCHA, or when a password field blocks paste and so breaks password managers. 3.3.7 Redundant Entry, A fails in checkouts that ask for the same address twice without a “same as billing” option. 3.2.6 Consistent Help, A fails when the contact link or chat button moves around from template to template.
Here is a scenario many web teams will recognize. A webshop passes an external audit in spring. In autumn, marketing adds a consent banner fixed to the bottom of the viewport and a chat bubble in the corner. Keyboard users tabbing through the footer now lose sight of focus behind both. Nothing in the code base “broke”, no deploy failed, and the site now fails 2.4.11. If nobody re-tests, the team finds out from a complaint, not a report.
Myth: An Automated Scan or Overlay Makes You Compliant
This is the most expensive misconception in the field. Automated engines such as axe-core, WAVE, and Lighthouse reliably catch missing alt attributes, contrast ratios on plain backgrounds, and missing labels. Accessibility specialists commonly estimate that automated tools find about 30-40% of WCAG issues. Whether alt text is meaningful, whether focus order makes sense, and whether an error message helps the user all take human judgment.
Overlay widgets that add a toolbar and promise instant compliance don’t change the underlying markup that screen readers depend on. They have not protected site owners in US ADA lawsuits, and some complaints have named the overlay itself as a barrier. A clean automated score is where testing starts. It is not proof of compliance, which is why an accessibility compliance approach that goes beyond the checkbox combines automated checks with manual testing.
Common Mistakes When Fixing Failed Criteria
Fixing the page instead of the template. A team patches contrast on the 20 pages listed in the audit report, while the problem lives in a shared CSS variable. The next landing page brings it straight back. Fix the issue at the component or design-token level.
Removing focus outlines for aesthetics. The rule outline: none; on :focus is still shipped in themes and resets. Use :focus-visible instead, so mouse users don’t see the ring and keyboard users always do.
Testing only the desktop homepage. Target size and obscured focus problems show up most on mobile layouts and in checkout flows, which audits sample least.
A Practical Remediation Order
A seasoned accessibility lead works through the failures in roughly this order:
1. Run axe DevTools or WAVE on your 5-10 highest-traffic templates, not individual pages.
2. Fix design tokens first: text colors, focus ring styles, and minimum button sizes.
3. Add accessible names to icon-only controls and labels to every form field.
4. Tab through login, checkout, and contact flows by keyboard, with the cookie banner and chat widget active.
5. Re-test after every theme, plugin, or CMS update, and record the results in your accessibility statement.
For a mid-sized site, steps 1-3 usually take 2-5 developer days. Step 5 is ongoing, and it is where most organizations lose ground.
Exceptions and Edge Cases
Not every rule applies everywhere. Logos and brand names are exempt from contrast requirements. Target size has exceptions for inline links within sentences and for controls whose size is set by the browser. Under the EAA, which has applied since 28 June 2025, microenterprises with fewer than 10 employees and annual turnover or balance sheet under €2 million are exempt from the service requirements. The harmonized standard EN 301 549 v3.2.1 still references WCAG 2.1 AA, so in the EU the 2.2 additions are best practice rather than a strict legal baseline for now. Online shops can find more in the European Accessibility Act obligations for online shops.
FAQ
Which WCAG 2.2 success criterion fails most often?
Year after year, the most common failure is 1.4.3 Contrast (Minimum). Large-scale scans find low-contrast text on roughly four out of five homepages.
Do I need to meet WCAG 2.2 or is WCAG 2.1 enough?
Most current laws, including EN 301 549 under the EAA, reference WCAG 2.1 AA. WCAG 2.2 is backward compatible, so meeting 2.2 AA also covers 2.1 AA and prepares you for future updates to the standards.
Does my accessibility statement need to list known failures?
Yes. Where a statement is required, it should name the parts that are not yet accessible and give a way to report problems. See the accessibility statement requirements for details.
Summary
The WCAG failures that show up most often haven’t changed much in fifteen years: contrast, alt text, form labels, and unnamed links and buttons. WCAG 2.2 adds new ones around obscured focus, target size, and authentication. Fix these at the template level, test with a keyboard and a screen reader, and re-check after every change. Most accessibility regressions come from routine updates rather than the original build.