A large retailer you supply has added a question to its supplier onboarding form: “Does your website and online shop meet current accessibility requirements?” You forward it to the agency that built your site, and the answer comes back: “Don’t worry, the site is fully responsive.” Those are not the same thing. If someone using a screen reader reaches your checkout and the “Continue” button is just an arrow icon with no text, the site is closed to them, however good it looks.
Below we cover what WCAG 2.2 is and what it added, the European Accessibility Act in force since 28 June 2025, the position in Germany, the UK, the US and Canada, common failures and fixes, testing, accessibility statements, and why plugins promising “compliance with one line of code” don’t deliver it.
Who is accessibility for, and why now?
An accessible website is one that people with visual, hearing, motor or cognitive disabilities can use too. A blind customer using a screen reader, someone who navigates by keyboard because they can’t use a mouse, a deaf visitor watching your product video, an older customer struggling with small grey text: all part of your audience. So, for a while, is anyone with an arm in plaster.
For years this sat in the “nice to have” column. Now it has dates attached. In the EU, the European Accessibility Act has applied since 28 June 2025 and covers consumer e-commerce. In the UK, the Equality Act 2010 already expects service providers to anticipate the adjustments disabled customers need. In the US, website accessibility claims under the ADA are a steady part of litigation. If you sell across borders, more than one of these may apply to you at once.
WCAG 2.2: what it is, which level and what’s new
The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the technical standard behind almost every accessibility law in the world. The current version, WCAG 2.2, became a W3C Recommendation on 5 October 2023 and was approved as the international standard ISO/IEC 40500:2025 in October 2025.
WCAG is organised around four principles, each broken down into success criteria, and every criterion sits at level A, AA or AAA. Laws and contracts almost always ask for AA, which means meeting all the A and AA criteria together. AAA is the highest level, and the W3C doesn’t recommend requiring it for entire sites.
WCAG 2.2 added nine success criteria to 2.1. These are the ones up to level AA, which is what you need for conformance:
- 2.4.11 Focus Not Obscured (Minimum), AA: when an element receives keyboard focus, it mustn’t be completely hidden by your own content, such as a sticky header or cookie banner.
- 2.5.7 Dragging Movements, AA: anything done by dragging (sliders, reordering, maps) must also be possible with a single click or tap.
- 2.5.8 Target Size (Minimum), AA: clickable targets must be at least 24 by 24 CSS pixels or have enough space around them, with exceptions such as links inside a sentence.
- 3.2.6 Consistent Help, A: if help mechanisms such as contact details, chat or a help link appear on several pages, they must appear in the same relative order.
- 3.3.7 Redundant Entry, A: information the user has already entered in the same process must be filled in automatically or be available to select. A “billing address same as delivery address” checkbox is the classic fix.
- 3.3.8 Accessible Authentication (Minimum), AA: a cognitive test, such as recalling a password or solving a puzzle, mustn’t be the only way to log in. Fields that password managers can fill and that allow pasting, or a login link sent by email, meet the criterion.
The other three new criteria, Focus Not Obscured (Enhanced), Focus Appearance and Accessible Authentication (Enhanced), are AAA. WCAG 2.2 also removed 4.1.1 Parsing as obsolete. A site that meets WCAG 2.2 also meets 2.1 and 2.0.
The European Accessibility Act: scope, dates and exemptions
The European Accessibility Act is not actually an act but a directive, Directive (EU) 2019/882. Member states transposed it into their own laws, and the rules have applied since 28 June 2025. It covers specific products and services:
- Products: consumer computers and operating systems, smartphones, payment terminals, ATMs, ticketing and check-in machines, e-readers.
- Services: electronic communications, access to audiovisual media services, the websites, apps and e-tickets of air, bus, rail and waterborne passenger transport, consumer banking, e-books and e-commerce.
The last item is the one that matters to most businesses. The directive defines e-commerce services as services provided at a distance, through websites and mobile apps, at the individual request of a consumer with a view to concluding a consumer contract. An online shop selling to consumers, a hotel website taking bookings or an app selling subscriptions is in scope. A B2B portal that sells only to businesses generally falls outside that definition.
The details that catch people out:
- The microenterprise exemption applies to services only. The directive defines a microenterprise as one employing fewer than 10 people with annual turnover or balance sheet total below the threshold it sets. Microenterprises placing covered products on the market get lighter documentation duties, not an exemption.
- There are transition periods. Service contracts agreed before 28 June 2025 can continue unchanged until they expire, for no more than five years, and service providers can keep using products they lawfully used before that date until 28 June 2030.
- If meeting a requirement would fundamentally alter the product or service, or impose a disproportionate burden, an exception is possible, but the assessment has to be documented and kept. Lack of time or knowledge doesn’t count.
- Service providers must explain how their service meets the accessibility requirements, in their general terms and conditions or an equivalent document, in an accessible format.
On the technical side, the directive relies on the harmonised standard EN 301 549 for presumption of conformity. The version currently cited, 3.2.1, is based on WCAG 2.1 AA. Version 4.1.1, published on 2 September 2026, moves web content to WCAG 2.2 AA and becomes the reference once it is cited in the EU’s Official Journal. The practical conclusion: if you are building a new site today, aim for WCAG 2.2 AA.
Country by country: Germany, the UK, the US and Canada
Germany: the BFSG
Germany transposed the directive through the Barrierefreiheitsstärkungsgesetz (BFSG) of 16 July 2021, which has applied since 28 June 2025. Market surveillance is carried out by the MLBF, a joint authority of the German states based in Magdeburg. Microenterprises providing services are exempt. Service providers must make the information listed in the act’s annex publicly available in an accessible form and keep it for as long as they offer the service.
The UK: the Equality Act
The UK did not transpose the directive after Brexit, but UK businesses selling to consumers in the EU can still fall within it. At home, the framework is the Equality Act 2010: service providers have a duty to make reasonable adjustments for disabled customers, and the EHRC describes that duty as anticipatory, meaning you have to think ahead rather than wait for a complaint. Public sector websites are covered by separate regulations requiring WCAG 2.2 AA and a published accessibility statement.
The US: the ADA
There is no federal technical standard for private businesses’ websites in the US, but courts apply Title III of the ADA to websites and the volume of claims is high. For state and local governments, the Department of Justice adopted a rule in 2024 based on WCAG 2.1 AA; an interim final rule published in April 2026 moved the compliance dates to 26 April 2027 for larger governments and 26 April 2028 for smaller ones.
Canada: Ontario’s AODA
In Ontario, businesses and non-profits with 50 or more employees have had to make their public websites conform to WCAG 2.0 Level AA since 1 January 2021, with exceptions for live captions and pre-recorded audio descriptions.
Common failures and how to fix them
Most audit findings fall into a handful of categories, nearly all easy to prevent at design stage.
Alternative text
Every image that carries information needs alternative text for screen readers. For a product photo, write “Navy linen shirt with button-down collar, long sleeves”, not “product image”. Purely decorative images should have empty alternative text (alt=""), otherwise a screen reader announces every divider and flourish.
Colour contrast
WCAG AA requires a contrast ratio of at least 4.5:1 between normal text and its background, and 3:1 for large text (roughly 24 pixels, or about 18.7 pixels in bold). Button outlines, form field borders and meaningful icons need 3:1 as well. Pale grey text on white is the failure we see most often. And don’t rely on colour alone: marking required fields only in red means nothing to someone who is colour-blind.
Keyboard and focus
Everything on the site must work with the keyboard alone: menus, pop-ups, tabs, sliders, checkout. Keyboard users must be able to see where they are, so the focus indicator has to be visible. A designer removing the focus outline because it “looks ugly” is switching the lights off for keyboard users. A dialog that opens should take focus inside it, return focus to where it came from when it closes, and nobody should get trapped inside a component.
Form labels and error messages
Every form field needs a visible label that is programmatically linked to it; placeholder text alone isn’t enough. Error messages must say which field is wrong, what is wrong and how to fix it. Mark required fields both visually and in the code.
Video and audio
Pre-recorded video needs captions at level A and audio description at level AA. Automatic captions are a start, but correct names and technical terms before publishing. Add a transcript for podcasts and other audio-only content.
Structure and language
Use headings for hierarchy, not for visual size; screen reader users navigate by jumping from heading to heading. Replace “click here” with link text that says where the link goes. Declare the page language with the lang attribute, or a screen reader will read your German page with English pronunciation.
Testing: tools, screen readers and one-minute checks
Automated tools are a good starting point: axe DevTools and WebAIM’s WAVE as browser extensions, and Lighthouse in Chrome’s developer tools. They find missing alternative text, unlabelled fields and contrast problems in seconds. What they can’t tell you is whether alternative text makes sense, whether the focus order is logical or whether an error message is understandable. A Lighthouse score of 100 does not mean the site is accessible.
Manual testing is therefore essential. Try your key user flows with at least one screen reader: NVDA, which is open source, on Windows; VoiceOver, built into Macs and iPhones; TalkBack on Android. The table below gives you checks that take about a minute each:
| Criterion | What it means | One-minute test |
|---|---|---|
| 1.1.1 Non-text Content (A) | Images that carry information need a text alternative | Run WAVE and look for missing or meaningless alt text such as “image” |
| 1.4.3 Contrast Minimum (AA) | At least 4.5:1 for normal text, 3:1 for large text | Measure pale grey text with a contrast checker |
| 1.4.10 Reflow (AA) | Content readable at 320 CSS pixels wide without horizontal scrolling | Zoom the browser to 400 per cent and check for sideways scrolling |
| 2.1.1 Keyboard (A) | Every function works from the keyboard | Put the mouse away and add a product to the basket with Tab and Enter |
| 2.4.7 Focus Visible (AA) | Keyboard focus is visible at all times | Tab through the page and note any moment you lose track of focus |
| 2.4.11 Focus Not Obscured (AA) | Focused elements aren’t hidden under sticky content | Tab towards the bottom of the page and see whether the cookie banner covers focus |
| 2.5.7 Dragging Movements (AA) | Dragging has a single-pointer alternative | Try changing a price slider or a sort order without dragging |
| 2.5.8 Target Size (AA) | Targets at least 24 by 24 CSS pixels or well spaced | Tap small icons and links on your phone with your thumb |
| 3.3.7 Redundant Entry (A) | The same information isn’t requested twice in one process | Check whether checkout makes you type your address a second time |
| 3.3.8 Accessible Authentication (AA) | Memory or puzzles aren’t the only way to log in | Check that you can paste into the password field and a password manager can fill it |
The accessibility statement
An accessibility statement explains which standard your site follows and to what extent, lists known issues and tells users how to report problems. In the EU, the information the directive requires from service providers can sit on this page or in your terms and conditions. Germany’s BFSG lists it in an annex, and in the UK it is mandatory for public sector bodies.
A good statement includes the target standard (WCAG 2.2 AA), the current conformance status, known gaps and the plan for fixing them, an email address and phone number for feedback, and the date it was last reviewed. For EU users, name the relevant enforcement authority too. An untested claim like “our site is fully accessible” is worse than no statement at all.
Why accessibility overlays won’t make you compliant
Tools that promise “instant compliance” from a single line of code, often called overlays, are everywhere.
The problem is that they don’t fix your source code. The unlabelled form field, the menu that won’t open with a keyboard and the meaningless alternative text all stay exactly where they were. Screen reader users already have assistive technology set up their way, and some overlays interfere with it. In the US, the Federal Trade Commission found that accessiBe’s claims that its automated product could make any website WCAG-compliant were unsupported, and finalised a settlement that included a payment in April 2025. Buying an overlay doesn’t discharge your obligations; it just papers over the problem.
Where to start
- Establish your scope: do you sell to consumers in the EU, the UK, the US or Canada? Get the answer in writing with your legal adviser.
- Pick your five most important user flows: homepage, product or service page, contact form, checkout, login.
- Run an automated scan with axe or WAVE on those flows and list what it finds.
- Run the one-minute checks from the table on the same flows, and go through at least one of them end to end with a screen reader.
- Rank the issues by impact. Anything that blocks a task completely, such as a checkout you can’t finish with a keyboard, comes first.
- Fix things in your design system rather than page by page: colour palette, focus style, form components, button sizes.
- Write your accessibility statement and make sure the feedback channel actually works.
- Give your content team a short checklist: alternative text, heading order, link text, captions. Accessibility is a habit, not a one-off project.
At AYTE Digital we treat accessibility as part of the work from the first sketch, and for existing sites we start with an assessment of the flows described here before prioritising fixes with you. If you’re not sure where to begin, the page that brings in the most revenue is a good first candidate.
