Store Accessibility in 2026: WCAG 2.2, the EAA, and Why Overlays Are a Trap
What the European Accessibility Act requires of an online shop, which WCAG version applies where, and why 1,031 practitioners signed against overlay widgets.
If you sell online to consumers in the EU, accessibility stopped being a nice-to-have on 28 June 2025. That's the date the European Accessibility Act started applying to services, and ecommerce is named in the directive explicitly[1]. Not "digital services" in the abstract. The online sale of any product or service, to a consumer, at a distance.
Most of the coverage you'll find on this is either a law firm being careful or a vendor being scary. Both leave out the practical bit: which standard actually binds you, what a real audit looks like, and why the widget in the corner of your homepage that promises compliance in one line of JavaScript is the worst money you'll spend this year.
Here's the number that frames everything else. WebAIM tested a million home pages in February 2026 and found detectable WCAG failures on 95.9% of them, averaging 56.1 errors per page, up from 51 the year before[2]. Automated testing only catches a fraction of real barriers, so that's a floor, not a ceiling. The web is getting less accessible while the law gets stricter.
What actually changed, and what did not
Three things get conflated constantly. They're different, they apply to different people, and they name different standards.
The European Accessibility Act
Directive (EU) 2019/882. Applies to both public and private sector. Covers ecommerce as "services provided at a distance, through websites and mobile device-based services by electronic means and at the individual request of a consumer with a view to concluding a consumer contract"[1]. Products and services placed on the market after 28 June 2025 are in scope[1]. Enforcement is national, so the penalties and the appetite vary by member state.
The Web Accessibility Directive
2016/2102. Public sector only. Older, narrower, and the reason a lot of accessibility guidance you find online is written for government sites and doesn't quite fit a shop[3].
The US position, which is not what people think
The Department of Justice published a web accessibility rule in 2024 that mandates WCAG 2.1 Level AA. It applies to state and local governments only, under ADA Title II, with deadlines of April 2027 for larger entities and April 2028 for smaller ones[4]. Private businesses are not covered by that rule.
Which does not mean US retailers are safe. It means there's no technical standard to hide behind, and the exposure comes through Title III litigation instead. UsableNet's analysis of actual court filings found more than 5,000 digital accessibility lawsuits in 2025, with ecommerce accounting for nearly 70% of them[5]. UsableNet sells accessibility services, so read the framing sceptically. But they're counting complaints filed in federal and state courts rather than estimating, and that count is checkable.
Which WCAG version binds you
This is where the guidance goes soft, so here it is plainly.
The harmonised European standard is EN 301 549[19]. Its current published version incorporates WCAG 2.1 Level AA[15] verbatim for web content[3]. A version incorporating WCAG 2.2 is in progress. So conformance with 2.1 AA is what gives you presumption of conformity today, and the Commission's own EAA pages are the place to check where enforcement sits in your member state[20].
WCAG 2.2 became a W3C Recommendation on 12 December 2024[6]. It adds nine success criteria and removes one. The AA-level additions are the ones that matter for a shop[7]:
| Criterion | Level | What it means for a store |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky headers and cookie bars must not hide the focused element |
| 2.5.7 Dragging Movements | AA | Image zoom, sliders and reorder controls need a non-drag alternative |
| 2.5.8 Target Size (Minimum) | AA | 24 by 24 CSS pixels minimum for controls, with spacing exceptions[16] |
| 3.2.6 Consistent Help | A | Contact and help links appear in the same relative order across pages |
| 3.3.7 Redundant Entry | A | Don't make people retype the delivery address as the billing address |
| 3.3.8 Accessible Authentication | AA | No cognitive function test unless there's an alternative. Puzzle CAPTCHAs fail[17] |
Success Criterion 4.1.1 Parsing was removed in 2.2, because browsers now recover from the markup errors it was written to catch[6]. If a vendor's audit still flags parsing errors as WCAG failures, they're running an old rule set.
The practical call: build to 2.2 AA, document conformance against 2.1 AA. 2.2 is a superset in everything except 4.1.1, so you get both.
Does this actually impact you?
Four questions. If you answer yes to the first and yes to any other, you're in scope somewhere.
- Do you sell to consumers, as opposed to businesses only?
- Do any of those consumers live in an EU member state?
- Do you have 10 or more employees, or turnover above EUR 2 million? The microenterprise exemption for service providers is fewer than 10 people and turnover or balance sheet total under EUR 2 million[1]. That's a genuine exemption for service providers and a lot of small merchants qualify.
- Do you sell into the US, where Title III litigation runs at 5,000 filings a year and ecommerce is the biggest single target[5]?
One more thing worth knowing about that litigation: of the 5,000-plus 2025 filings, 1,427 targeted companies that had already faced an accessibility claim, and in federal court 46% of cases involved repeat defendants[5]. Settling doesn't fix it. Fixing fixes it.
What we found: the six errors that are almost all of the problem
We went through WebAIM's 2026 dataset alongside the four platforms' own theme documentation, and the thing that stands out is how boring the failures are.
WebAIM reports that 96% of all detected errors fall into six categories[2]:
| Failure | Share of home pages | Typical ecommerce cause |
|---|---|---|
| Low contrast text | 83.9% | Grey-on-white price and sale copy, brand palette applied without checking |
| Missing image alt text | 53.1% | Product images imported from a feed with no alt field |
| Missing form input labels | 51.0% | Newsletter signup, search box, filter controls using placeholder text as label |
| Empty links | 46.3% | Icon-only links: cart, wishlist, social |
| Empty buttons | 30.6% | Icon-only buttons: quantity steppers, carousel arrows, close |
| Missing document language | 13.5% | A theme edit that dropped the lang attribute |
None of that needs a specialist. Four of the six are ten-minute fixes in a theme file. Contrast is a design decision somebody made once and nobody re-checked. Alt text on a large catalogue is a data problem, which is a good argument for having your product data in decent shape before you start. See the PIM piece for why that keeps coming up.
The honest caveat: automated tools detect roughly a third of WCAG issues. Keyboard traps, focus order, meaningful heading structure, whether your error messages actually tell a screen reader user what went wrong. None of that shows up in a scan. W3C's own evaluation guidance is clear that automated testing supplements manual testing rather than replacing it[8], and the ACT rules exist precisely to make explicit which checks a machine can and cannot decide[18].
Why overlay widgets are a trap
You will be sold one. The pitch is a single script tag, a monthly fee, and an accessibility statement generated for you. It's compelling because the alternative is real work.
1,031 accessibility practitioners have signed a public statement against these products, including people who work on accessibility at Google, Microsoft and Apple, disability rights lawyers, and disabled users themselves[9]. Their central claim, quoted directly: "No overlay product on the market can cause a website to become fully compliant with any existing accessibility standard and therefore cannot eliminate legal risk."[9]
The specific failures they document are worth knowing because they're technical rather than ideological[9]:
- Automated repair can't reliably generate meaningful alt text, associate form labels, or fix keyboard access in a React or Angular app that re-renders.
- Overlays can't touch content inside PDFs, canvas, SVG or media files.
- Some detect assistive technology use, which reveals disability status, and persist settings across sites. That's a GDPR problem sitting on top of an accessibility problem.
- Disabled users report that overlays interfere with the screen readers and magnifiers they already use.
And the empirical bit. UsableNet's filing analysis shows lawsuits against companies that had a widget installed running steadily through 2025, peaking above 150 in a single month, with the conclusion that "widgets do not materially reduce legal risk"[5].
Stance you can argue with: installing an overlay is worse than doing nothing, because it converts a fixable engineering backlog into a recurring cost, gives your team the impression the job is done, and adds a new failure surface. I'd rather see a store with honest accessibility debt and a plan than a store with a widget and a false statement.
If you are on Shopify
What the platform gives you
Shopify publishes accessibility best practices for theme developers and its reference themes are built against them[10]. If you're on an unmodified current Dawn-lineage theme, your baseline is decent. Checkout is Shopify's responsibility and it's the part of your store you least need to worry about.
Where Shopify stores fail anyway
Apps. Every app that injects UI into your storefront brings its own markup and nobody checks it. Popups are the worst offender: focus doesn't move into them, escape doesn't close them, and the close button is an empty button with an icon inside it, which is 30.6% of the web's problem right there[2].
Second failure: alt text at catalogue scale. Shopify lets you set alt text per image, and almost nobody does it for a 4,000-SKU catalogue imported from a supplier feed. That's a bulk data job, not an accessibility job.
Third: colour. Sale prices in a light red on white are a contrast failure and they're on nearly every store I look at.
Not on Shopify? The other platforms
WooCommerce
WordPress has an accessibility team with a published handbook and coding standards, and core is held to WCAG 2.0 AA at minimum[11]. That covers core. It says nothing about your theme, your page builder, or the twelve plugins you installed.
The Woo-specific risk is the block editor plus a third-party theme. Blocks generate markup you didn't write, and a page builder can nest headings in an order that makes no sense to a screen reader while looking fine visually. Run a manual heading-order check on your product template, your cart and your checkout. It takes twenty minutes.
Magento and Adobe Commerce
Adobe publishes accessibility conformance reports for Commerce and the admin, and the storefront themes are a reasonable starting point[12]. The problem on Magento is almost always the custom theme built five years ago by an agency that no longer exists.
There's a second Magento-specific issue: layered navigation. Faceted filter panels are one of the hardest things to get right for keyboard and screen reader users, because state changes without a page load and nothing announces the result. If you have layered navigation, test it with a screen reader before anything else.
BigCommerce
Stencil themes give you full template control, which is the same double-edged thing as everywhere else[13]. BigCommerce's own checkout is generally sound. Custom-built checkouts on the Checkouts API are not automatically anything, and that's where an accessibility failure costs you an order rather than a reputation.
Headless and custom builds
Client-side rendering makes accessibility harder in a specific way: route changes don't move focus and don't announce, so a screen reader user clicks a product and hears nothing change. Fix focus management on route change first. It's the single highest-value thing in a headless build, and it's also the thing that gets skipped because it looks fine to a sighted developer.
The accessibility audit checklist
Manual. One person, one afternoon, no tools you have to buy.
| # | Test | How | Pass |
|---|---|---|---|
| 1 | Keyboard-only purchase | Unplug the mouse. Browse, add to cart, check out | Order placed |
| 2 | Visible focus | Tab through the header, PDP and checkout | You can always see where you are |
| 3 | Focus not obscured (2.4.11) | Tab with a sticky header and a cookie bar present | Focused element never hidden |
| 4 | Zoom to 200% | Browser zoom, then reflow at 320px width | No horizontal scrolling, nothing clipped |
| 5 | Contrast | Check body text, prices, sale badges, placeholder text | 4.5:1 for normal text |
| 6 | Images have alt text | Spot check 20 product images | Describes the product, not "product image" |
| 7 | Form labels | Click each label, see if focus moves to the field | Focus moves |
| 8 | Icon-only controls | Inspect the cart, search, wishlist, close buttons | Accessible name present |
| 9 | Error messages | Submit checkout with a bad postcode | Specific, inline, announced |
| 10 | Target size (2.5.8) | Measure quantity steppers and carousel arrows | 24 by 24 CSS pixels or spaced |
| 11 | Dragging alternative (2.5.7) | Try any slider or image zoom without dragging | Works with taps or keys |
| 12 | Authentication (3.3.8) | Attempt login with a password manager | Paste allowed, no puzzle CAPTCHA |
| 13 | Page language | View source, check the html lang attribute | Present and correct |
| 14 | Screen reader on the PDP | VoiceOver or NVDA, read the page top to bottom | Price, variant and stock state all announced |
Rows 3, 10, 11 and 12 are the WCAG 2.2 additions[7]. If your last audit predates December 2024, it didn't test them. The quick reference is the working document to keep open while you go through this[21].
Accessibility statements, and why to publish an honest one
The EAA expects information about how a service meets accessibility requirements to be available[1]. W3C publishes a generator and a structure for these[14].
Most statements are copy-paste fiction claiming full WCAG 2.1 AA conformance on a site that has 56 detectable errors on the homepage. A statement that says "we conform to WCAG 2.1 AA with the following known exceptions, here they are, here's the fix date, here's how to reach a human" is both more useful and safer. Overclaiming conformance is the thing a plaintiff's lawyer screenshots.
What AI agents change here
Almost everything a screen reader needs, an AI agent also needs. Semantic markup, real headings, labelled controls, text that isn't locked inside an image, state changes announced in the DOM rather than painted with CSS.
The overlap isn't perfect. An agent doesn't care about colour contrast. But the structural half of accessibility is the same work as making your store readable by machines, which is the same work as not shipping a page that only exists after JavaScript runs. Three separate business cases, one engineering backlog. That's rare enough to be worth pointing out.
What to do this week
- Decide your scope. EU consumers plus 10 or more staff means the EAA applies. Under the microenterprise threshold and you have breathing room, though not forever[1].
- Do the keyboard test. Twenty minutes. It will find more than any scanner.
- Run one automated scan on your homepage, a collection page, a product page and the cart. Fix the contrast and label errors immediately.
- Audit your popups. Every app that opens a modal. Focus in, escape out, close button named.
- Bulk-fix alt text on your top 200 products by revenue. Not all 4,000. The top 200.
- If you have an overlay installed, read the fact sheet before your next renewal[9], and price the same money as developer time instead.
- Write an honest accessibility statement with named exceptions and a contact route[14].
The takeaway
Accessibility on an online shop is not a specialist discipline. It's contrast, alt text, labels, focus and error messages, and six categories account for 96% of what tools detect[2]. The law caught up in June 2025 and the standard moved in December 2024. The widget doesn't help.
I'll admit something. For years I treated this as a compliance chore and put it at the bottom of every sprint. What changed my mind wasn't the directive. It was watching somebody try to buy from a store I'd worked on using only a keyboard, and getting stuck in a newsletter popup with no way out. That took four seconds to observe and about an hour to fix, and it had been live for two years.
Go and unplug your mouse.
Sources
- European Union, Directive (EU) 2019/882 on the accessibility requirements for products and services (European Accessibility Act), EUR-Lex. Accessed 22 July 2026.
- WebAIM, "The WebAIM Million: an annual accessibility analysis of the top 1,000,000 home pages", February 2026.
- W3C Web Accessibility Initiative, "Web Accessibility Laws & Policies: European Union". Accessed 22 July 2026.
- US Department of Justice, "Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments", ada.gov, 2024.
- UsableNet, "ADA Web Lawsuit Trends for 2026: What 2025 Filings Reveal", 8 January 2026. (UsableNet sells accessibility services; the figures are counts of filed complaints.)
- W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", W3C Recommendation, 12 December 2024.
- W3C Web Accessibility Initiative, "What's New in WCAG 2.2". Accessed 22 July 2026.
- W3C Web Accessibility Initiative, "Evaluating Web Accessibility Overview". Accessed 22 July 2026.
- Overlay Fact Sheet, "Web accessibility overlays: a fact sheet", 1,031 signatories. Accessed 22 July 2026.
- Shopify, "Accessibility best practices for Shopify themes". Accessed 22 July 2026.
- WordPress, "Accessibility Handbook", make.wordpress.org. Accessed 22 July 2026.
- Adobe, "Adobe Commerce Admin Guide". Accessed 22 July 2026.
- BigCommerce, "Stencil Themes". Accessed 22 July 2026.
- W3C Web Accessibility Initiative, "Developing an Accessibility Statement". Accessed 22 July 2026.
- W3C, "Web Content Accessibility Guidelines (WCAG) 2.1". Accessed 22 July 2026.
- W3C, "Understanding SC 2.5.8: Target Size (Minimum)". Accessed 22 July 2026.
- W3C, "Understanding SC 3.3.8: Accessible Authentication (Minimum)". Accessed 22 July 2026.
- W3C Web Accessibility Initiative, "Accessibility Conformance Testing (ACT) Rules". Accessed 22 July 2026.
- ETSI, EN 301 549 V3.2.1, "Accessibility requirements for ICT products and services" (PDF), March 2021.
- European Commission, "European accessibility act". Accessed 22 July 2026.
- W3C, "How to Meet WCAG 2.2 (Quick Reference)". Accessed 22 July 2026.