WCAG 2.1 AA Accessibility: What Every Website Owner Must Know (2026)
Accessibility is no longer optional. The European Accessibility Act (EAA) mandates WCAG 2.1 AA compliance for most commercial websites in the EU from June 2025. The ADA in the US is being enforced more aggressively every year. This guide covers what WCAG 2.1 AA requires, the 8 most-failed criteria, and how to audit your site today for free.
What is WCAG 2.1 AA?
WCAG stands for Web Content Accessibility Guidelines, published by the W3C. Version 2.1 added 17 new success criteria (mostly for mobile and cognitive accessibility) on top of the 2.0 baseline. “Level AA” is the internationally accepted minimum standard for legal compliance — it includes all Level A criteria plus additional requirements.
The four principles of WCAG are:
The Legal Landscape in 2026
The EAA (Directive 2019/882) requires WCAG 2.1 AA compliance for e-commerce, banking, e-books, transport, and telecom websites from June 2025. Member states can extend enforcement to other sectors. Penalties are set by national law — fines similar to GDPR scale are already being discussed.
The Department of Justice confirmed in 2023 that the ADA applies to websites. Federal courts have largely adopted WCAG 2.1 AA as the de-facto standard. Over 4,600 ADA website lawsuits were filed in 2023 alone, mostly targeting e-commerce, hospitality, and healthcare.
The Public Sector Bodies Accessibility Regulations require WCAG 2.1 AA for all UK public sector websites and apps. The Equality Act creates duties for private businesses. Ofcom enforces additional rules for broadcasters and telecoms.
Ontario's AODA required WCAG 2.0 Level AA for large organisations from 2021. The Accessible Canada Act is being phased in federally. Government procurement now routinely requires WCAG 2.1 AA.
The 8 Most-Failed WCAG 2.1 AA Criteria
According to the WebAIM Million report, these criteria fail on over 95% of homepages. Each one has a concrete fix.
1. Images must have alt text
Every <img> element needs an alt attribute describing what the image shows. Screen readers announce the filename or "image" when alt is missing — giving blind users no information. Decorative images should use alt="" (empty, not missing).
Fix: Add meaningful alt text to every image. For decorative images, use alt="" so screen readers skip them. For images inside links, describe the destination.
<img src="chart.png">
<img src="chart.png" alt="Bar chart showing 40% revenue growth in Q4 2024">
2. Form inputs must have labels
Every form input needs a programmatically-associated label. Without it, screen reader users hear "edit text" with no idea what to fill in. Placeholder text alone does not count as a label — it disappears when the user starts typing.
Fix: Use <label for="input-id"> linked to the input id, or wrap the input inside a <label>. As a fallback, use aria-label or aria-labelledby.
<input type="email" placeholder="Your email">
<label for="email">Email address</label> <input id="email" type="email">
3. Buttons and links must have names
Interactive elements without accessible names are announced as "button" or "link" with no description. Icon-only buttons (close, hamburger menu, social share) are the most common offenders.
Fix: Add aria-label to icon buttons: <button aria-label="Close dialog">. Alternatively, add a visually-hidden text span inside the button.
<button><svg>...</svg></button>
<button aria-label="Close dialog"><svg aria-hidden="true">...</svg></button>
4. Text must have sufficient colour contrast
Normal text (under 18pt/14pt bold) needs a contrast ratio of at least 4.5:1 against its background. Large text needs 3:1. This is one of the most-failed WCAG criteria — grey-on-white body text often fails.
Fix: Use a contrast checker (e.g. WebAIM Contrast Checker) to verify all text/background combinations. Deepen text colours or lighten backgrounds to meet the threshold.
color: #9ca3af on background: #ffffff (ratio: 2.85:1 ✗)
color: #4b5563 on background: #ffffff (ratio: 5.74:1 ✓)
5. Keyboard focus must be visible
Keyboard users navigate with Tab. Every focusable element needs a visible focus indicator so users know where they are. CSS that removes the default outline (outline: none or outline: 0) without providing a replacement is a WCAG failure.
Fix: Never use outline: none without providing a custom :focus-visible style. A 2px solid outline with a contrasting colour is sufficient.
a:focus { outline: none; }a:focus-visible { outline: 3px solid #2563eb; outline-offset: 2px; }6. Page must have a language attribute
The <html> element must have a lang attribute declaring the page language. Screen readers use it to select the correct text-to-speech voice and pronunciation rules. Without it, content may be read with the wrong accent or mispronounced entirely.
Fix: Add lang="en" (or the appropriate BCP 47 language code) to your <html> tag.
<html>
<html lang="en">
7. Provide a skip navigation link
Keyboard users must tab through every navigation link on every page before reaching the main content — unless you provide a skip link. Many screen reader users navigate page-by-page and find repetitive navigation extremely frustrating.
Fix: Add a "Skip to main content" link as the first focusable element on each page. Use CSS to position it off-screen and reveal it on focus.
<!-- no skip link — users must tab through all 40 nav items -->
<a href="#main" class="skip-link">Skip to main content</a> ... <main id="main">...</main>
8. Data tables need headers
Data tables without column or row headers are read as a stream of disconnected values. Screen reader users cannot tell which value belongs to which column. Layout tables (used for visual arrangement) should be marked with role="presentation".
Fix: Add <th scope="col"> for column headers and <th scope="row"> for row headers. Add a <caption> to describe the table's purpose.
<table><tr><td>Name</td><td>Score</td></tr></table>
<table><caption>Scores</caption><tr><th scope="col">Name</th><th scope="col">Score</th></tr></table>
GDPR and Accessibility: The Overlap
GDPR and WCAG are both user-rights frameworks — they overlap in important ways:
Your consent banner must be keyboard-operable, have sufficient colour contrast, and work with screen readers. An inaccessible cookie banner is simultaneously a GDPR violation (invalid consent) and a WCAG failure.
Data Subject Access Request forms must be accessible. If a screen reader user cannot submit a DSAR, you may be blocking them from exercising their GDPR rights.
WCAG 3.1.5 (Level AAA) calls for reading ease. GDPR Article 12 requires information be provided "in a concise, transparent, intelligible and easily accessible form." Plain language is both a legal and accessibility requirement.
How to Audit Your Site for WCAG 2.1 AA
Tools like fixGDPR, axe DevTools, WAVE, and Lighthouse can catch a large proportion of WCAG failures automatically — especially missing alt text, labels, contrast violations, and missing landmarks. Run an automated scan first to find quick wins.
Run a free accessibility scan →Open your site, put your mouse aside, and try to complete key tasks using only Tab, Shift+Tab, Enter, and Space. Can you reach the main content? Can you submit forms? Can you close dialogs? Every place you get stuck is a failure.
Use NVDA + Firefox (free, Windows) or VoiceOver + Safari (built into macOS/iOS). Navigate with the screen reader off-screen to simulate the experience of a blind user. Check that every image, form, and interactive element is announced meaningfully.
Increase your browser zoom to 200% and check that content doesn't overflow, text doesn't become unreadable, and no information disappears. WCAG 1.4.4 requires text to remain functional at 200% zoom.
Check your accessibility score now
fixGDPR runs 17 WCAG 2.1 AA checks alongside GDPR — alt text, colour contrast, keyboard focus, form labels, and more. Free, no sign-up required.
♿ Scan for accessibility issues →This article is for informational purposes only and does not constitute legal advice. Consult a qualified lawyer for your specific situation.