
WCAG 2.2 Compliance After the June 2025 Deadline: What UK Businesses Need to Know
The European Accessibility Act became enforceable on 28 June 2025. Four months on, most UK businesses selling to EU customers still aren't compliant—and penalties up to €3 million are now live.
The European Accessibility Act became enforceable on 28 June 2025. That was four months ago. If you're a UK business serving EU customers and your website isn't WCAG 2.2 Level AA compliant, you're operating outside the law in those jurisdictions.
Many UK businesses still aren't compliant. Some don't know the requirement exists. A few assume that being outside the EU means the rules don't apply to them. They're wrong.
One in four adults in the EU has a disability—101 million people with money to spend and services to buy. Your website either serves them or it doesn't. If it doesn't, you're facing penalties up to €3 million in some countries, and you're voluntarily excluding 15% of the global population from becoming customers.
Here's the bit most people miss: 73% of websites that fix accessibility issues see organic traffic growth. Google's crawlers can't see your site—they rely on the same structural cues screen readers do. Improve accessibility, improve rankings. Not a bad trade-off for avoiding massive fines.
What the June Deadline Actually Meant
The European Accessibility Act had been coming for years—plenty of warning—but June 2025 is when it became legally enforceable. E-commerce, travel booking, banking websites, mobile apps. If you sell to EU customers, you're in scope. Location of your business is irrelevant.
The technical requirement is WCAG 2.2 Level AA compliance. The W3C published WCAG 2.2 back in October 2023, and it became an ISO/IEC international standard (ISO/IEC 40500:2025) in January this year. Not a recommendation. Not a best practice. A legally enforceable standard.
UK businesses got caught out because they misunderstood extraterritoriality. "We're not in the EU" doesn't protect you if EU residents can buy from your site. That's the entire point of the EAA—protecting EU consumers regardless of where the business is registered.
The public sector had the same June deadline, though enforcement mechanisms differ slightly. Small businesses—fewer than 10 employees, less than €2 million turnover—have partial exemptions, but "partial" means you still need core accessibility features. You can't just ignore this.
WCAG 2.2 added nine new success criteria to 2.1. The important ones: better keyboard navigation (focus indicators that don't vanish when you need them), cognitive accessibility improvements (consistent help mechanisms), and mobile-specific requirements like larger tap targets.
If you were already WCAG 2.1 Level AA compliant back in June, the jump to 2.2 wasn't massive. Most sites we audit aren't even close to 2.1 compliance, let alone 2.2.
What Enforcement Actually Looks Like
Each EU member state handles enforcement differently, but the penalties are real:
Germany will fine you up to €500,000. France ranges from €5,000 to €250,000. Spain sits between €5,000 and €300,000. Ireland goes up to €60,000 and adds potential imprisonment—18 months if you're particularly egregious about it. Some jurisdictions can hit you with up to €3 million, plus they can force you to stop trading in that market entirely.
The US is no better. A single ADA violation can cost you $75,000 in civil penalties. If you don't fix it and get caught again? $150,000.
77% of ADA lawsuits in 2023 targeted companies with under £20 million in revenue. This isn't just corporate compliance theatre—it's hitting small and mid-size businesses. 4,605 accessibility lawsuits were filed in 2023, up from 2,314 in 2018. That's nearly doubled in five years.
Target Corporation paid $6 million back in 2006 after the National Federation of the Blind sued over their inaccessible website. Target's defence was that websites weren't physical "places of public accommodation" under the ADA. They lost that argument comprehensively.
Domino's Pizza tried the same defence in 2019. A blind customer couldn't order pizza through their site or app. The Ninth Circuit Court of Appeals ruled against them. ADA protections explicitly cover digital properties. That's settled law now, and courts worldwide cite it.
Why Bother Beyond Avoiding Fines
Legal compliance is one thing. Actually benefiting from accessibility is another.
101 million people with disabilities live in the EU. Globally, that's 1 billion—15% of the world's population. They've got mortgages, they buy products, they book services. Most websites still can't serve them properly, which means most of your competitors are voluntarily walking away from that market.
Research from AudioEye and Netguru tracking businesses that fixed accessibility issues found 73% saw organic traffic growth afterwards. Not because they suddenly attracted millions of disabled users, but because accessible websites use semantic HTML, proper heading structure, descriptive link text—all the things search engines actually want.
Google's crawlers can't see your site. They read structure the same way screen readers do. Make your site work for screen readers, and you've simultaneously made it work better for Google. That's not even the main point of accessibility, but it's a nice side effect.
Accessibility improvements often benefit everyone. Larger tap targets help everyone on mobile, not just people with motor disabilities. Keyboard navigation helps power users who hate using mice. Captions on videos help people in noisy offices and non-native English speakers. Clear error messages reduce support tickets.
Research shows that fixing colour contrast issues improves conversion rates across all users, not just those with vision impairments. When your text is readable in bright sunlight on mobile, everyone benefits. The legal compliance is almost secondary.
What's Actually Failing on Most Sites
Common accessibility failures appear across most websites:
Missing alt text on images is the most common (WCAG 1.1.1, Level A). Not alt="image123.jpg" or alt="click here"—actual descriptions like alt="Graph showing 40% increase in mobile traffic from Q1 to Q2 2025". Decorative images need empty alt attributes (alt="") so screen readers skip them entirely.
Colour contrast failures are almost as common (WCAG 1.4.3, Level AA). Text needs at least a 4.5 to 1 contrast ratio against background. Large text requires a minimum of 3 to 1. That trendy light grey on white everyone's using? Fails. Check it with Chrome DevTools or WebAIM's contrast checker before your designer convinces you it looks better.
Keyboard navigation breaks on nearly every site with custom JavaScript widgets (WCAG 2.1.1, Level A). Tab through your site. Can you reach every interactive element? See where focus is? Activate buttons with Enter or Space? That dropdown menu that works perfectly with a mouse often becomes completely unusable with just a keyboard. Custom widgets rarely get this right.
Forms without proper labels are everywhere (WCAG 3.3.2, Level A). Every input needs a <label> element explicitly associated with it—<label for="email"> linked to <input id="email">. Placeholder text isn't a replacement. It vanishes when users start typing, which confuses everyone, not just screen reader users.
Heading structures are usually a mess (WCAG 1.3.1, Level A). H1 → H2 → H3 isn't complicated, but sites skip levels constantly. Using <h1> for visual styling when it's not the main heading breaks screen reader navigation entirely. If your structure goes H1, H3, H2, H4, you've made the page unnavigable for assistive tech users.
Focus indicators vanish or never existed in the first place (WCAG 2.4.7, Level AA). Users tabbing through your site need to see where focus currently is. Developers love removing the outline with outline: none; for aesthetic reasons, then forget to replace it with anything visible. WCAG 2.2's criterion 2.4.11 (Focus Not Obscured) now explicitly requires focus indicators stay at least partially visible—not hidden behind sticky headers or modal overlays.
Videos without captions show up constantly (WCAG 1.2.2, Level A). Pre-recorded content needs captions. Live content needs live captions. This isn't just for deaf users—it helps people in noisy offices, non-native speakers, anyone with audio processing difficulties. YouTube's auto-generated captions don't count unless you've reviewed and corrected them. They butcher technical terminology.
Dynamic content updates that screen readers can't detect are endemic to JavaScript-heavy sites (WCAG 4.1.3, Level AA). Load new items, show error messages, reveal hidden sections—screen readers miss all of it unless you use ARIA live regions (<div role="alert" aria-live="assertive">) to announce changes.
Touch targets below 44 by 44 CSS pixels are everywhere on mobile (WCAG 2.5.8, Level AA in WCAG 2.2). Those icon buttons crammed into 30px squares next to each other? Everyone mis-taps them, not just users with motor disabilities or large fingers.
Session timeouts without warnings catch people constantly (WCAG 2.2.1, Level A). If your site times out, users need warning with an extension option. Twenty seconds before expiry: "Your session will expire in 20 seconds. Extend session?" Users who read slowly or use assistive tech need this. So do people who got distracted making tea.
What to Do If You're Not Compliant
The June deadline has passed. If you're not compliant and you serve EU customers, you're exposed to enforcement action now. Doesn't mean you'll be hit immediately, but the risk exists.
Start with automated checking—WAVE, axe DevTools, or Lighthouse built into Chrome. These catch maybe 30–40% of issues: missing alt text, colour contrast failures, form labels, heading structure problems. Run them now. You'll have a list of concrete failures within minutes.
The other 60–70% requires manual testing. Navigate your site using only keyboard—no mouse. Can you reach everything? Activate every button? Use a screen reader (NVDA is free on Windows, VoiceOver comes with macOS). Zoom to 200% and check nothing breaks. Test touch targets on actual mobile devices.
Prioritise Level A violations first—those are critical failures. Then Level AA violations, which are required for legal compliance. Focus on high-traffic pages and conversion paths: login, checkout, account management, whatever drives your revenue.
Quick wins buy you time. Alt text on images? Bulk edit if you've got hundreds. Colour contrast? Usually a CSS change across your design system. Form labels, heading hierarchy, keyboard navigation—none of these require architectural rewrites. Custom JavaScript widgets are harder. Chat widgets, payment forms, third-party embeds—those take actual development time.
If you've got a component library or design system, fix problems there. Changes cascade to every page using those components. Much faster than fixing individual pages.
Test with actual disabled users once you've fixed the obvious stuff. UserTesting and Fable connect you with people who use assistive technology daily. They'll find problems automated tools miss. Alternatively, commission an audit from specialists like AbilityNet or Level Access—they provide documentation that helps if you ever face enforcement.
Make accessibility part of your normal workflow going forward. Design briefs should include accessibility requirements. Developers should test with keyboards and screen readers during development, not after. Run automated checks in CI/CD so builds fail if you introduce regressions. Add accessibility criteria to QA checklists. Review third-party integrations for accessibility before adding them.
Train your team. Developers need to understand semantic HTML and ARIA. Designers need to think about colour contrast and focus indicators from day one. Content authors need to know how to write descriptive alt text. This isn't a one-time project—it's how you work now.
Where We Come In
At Numen Technology, accessibility is built into every project from day one. WCAG 2.2 compliance gets assessed during discovery, prioritising fixes based on legal risk and conversion impact.
Our development work treats accessibility as foundational, not something bolted on after launch. Semantic HTML from the start, screen reader testing throughout the build, WCAG 2.2 validation before going live.
Ongoing support includes monitoring for accessibility regressions—plugin updates and template changes can break compliance without anyone noticing until enforcement shows up.
The Deadline Has Already Passed
The June deadline came and went. If you're not compliant now, you're operating with legal risk every day. The penalties—up to €3 million in some jurisdictions—are enforceable. Whether enforcement happens tomorrow or next year is unpredictable, but the exposure exists.
Then there's the 101 million potential customers in the EU with disabilities who your competitors are still ignoring. The legal compliance is one thing. The market opportunity is another.
Making your site accessible also makes it better for everyone—higher engagement, better conversions, improved SEO. That's not the main reason to do it, but it's a useful consequence.
Book a strategy session and we'll audit where your site currently stands. You'll know exactly what's failing, what needs fixing, and how long it'll realistically take.