If you sell to consumers in the EU, EAA e-commerce compliance stopped being a future concern on 28 June 2025 — that is the date the European Accessibility Act (Directive (EU) 2019/882) began to apply. For online retailers, the practical question is no longer "does this affect us?" but "which screens do we fix first?" This guide skips the legal theory and goes straight to scope, the deadline, and a priority order for your checkout, forms, and product pages.
The short version: your storefront must meet WCAG 2.2 Level A and AA, the baseline referenced through the European standard EN 301 549. Below, we translate that into the specific, recurring failures that block real shoppers — the ones that most often surface in complaints and audits.
Is your online store actually in scope?
The EAA names "e-commerce services" as a covered category, so a typical consumer-facing online shop selling physical or digital goods to EU customers is in scope. This holds regardless of where your company is headquartered: if you sell to consumers in the EU market, the obligation follows the sale, not your registered address.
There is one narrow exemption that retailers often misread. Microenterprises that provide services — fewer than 10 staff and under €2,000,000 in annual turnover — are largely exempt from the service obligations. Note the wording: it is fewer than 10 staff *and* below the turnover threshold, not either/or. Cross either limit and you are back in scope. A purely B2B platform with no consumer offering sits in a greyer area, but most stores that take consumer orders should plan to comply rather than hunt for an escape hatch.
For the full eligibility picture beyond e-commerce, see our overview of the European Accessibility Act.
The deadline and what "compliant" means
The requirements apply from 28 June 2025. There is no separate grace period for websites — unlike certain physical products and self-service terminals, which carry transition arrangements, a digital storefront is expected to be accessible now.
"Accessible" maps to WCAG 2.2 Level A and AA via EN 301 549. WCAG is organised around four principles — Perceivable, Operable, Understandable, and Robust — and every fix below traces back to one of them. You also need a published accessibility statement describing your conformance and giving shoppers a way to report barriers; our accessibility statement generator produces one in minutes.
Priority 1: Checkout — the highest-risk flow
Checkout is where inaccessibility costs you orders directly, so fix it first. The recurring failures are concrete:
- Keyboard traps in payment fields. Card-entry iframes and date pickers you cannot tab into or out of strand keyboard and screen-reader users mid-purchase. Every step must be operable without a mouse.
- Errors that aren't announced. A red border on "Invalid postcode" is invisible to screen readers. Tie each message to its field with aria-describedby and use role-based announcements so the error is heard, not just seen (WCAG 3.3.1, 4.1.3).
- Timeouts with no warning. Sessions that silently expire during a slow form completion fail WCAG 2.2.1. Warn the user and let them extend.
- Unlabelled controls. "Same as billing" checkboxes, CVV fields, and saved-card radio buttons need programmatic labels, not just visual placeholders.
Test the whole flow — cart, shipping, payment, confirmation — with the keyboard alone and with a screen reader before you touch anything cosmetic.
Priority 2: Forms everywhere else
After checkout, forms are the next concentration of risk: account registration, login, address books, search, newsletter sign-up, and returns. The fundamentals repeat: every input needs a persistent, programmatically associated <label>; placeholder text is not a label because it vanishes on focus and usually fails contrast. Group related fields with <fieldset> and <legend>, mark required fields in text rather than colour alone, and make focus order match visual order.
One e-commerce-specific trap: "floating label" and custom dropdown components from UI libraries frequently ship without correct ARIA roles or keyboard support. Audit any third-party widget before trusting it. Our accessible forms guide covers the patterns to use.
Priority 3: Product pages and imagery
Product pages are where Perceivable usually breaks. The big four:
- Alt text that sells. Decorative thumbnails can be empty (alt=""), but the primary product image needs descriptive alt text — colour, material, key visible detail — not the SKU.
- Colour contrast on price and sale tags. Light-grey "€" symbols, low-contrast strikethrough pricing, and pale "Add to cart" buttons commonly fail. The thresholds: 4.5:1 for normal text, 3:1 for large text (≥18pt, or 14pt bold) and for UI components and meaningful graphics (WCAG 1.4.3 and 1.4.11).
- Colour-only variant selection. A swatch picker that conveys the choice with colour alone excludes colour-blind users — add a text label or a visible selected state.
- Star ratings and stock badges as images. "4.5 stars" and "Only 2 left" must be available as text to assistive tech, not baked into a sprite with no alternative.
These are also the issues a scanner catches fastest, which is why automated detection is the cheapest first move.
A realistic path to compliance
Work in order rather than trying to fix everything at once: scan to surface machine-detectable issues, fix checkout, then forms, then product templates, then run a manual keyboard-and-screen-reader pass for what automation can't see.
Start by running a free scan of your store to get a ranked list mapped to WCAG 2.2 criteria, then work through the accessibility checklist for the manual checks automation misses.