E-commerce accessibility

E-Commerce and the EAA: A Journey-by-Journey WCAG 2.1 AA Checklist

Last updated · June 20, 2026

If you run an online store that ships to EU customers, the European Accessibility Act is not a future concern. The primary EAA deadline was 28 June 2025, when accessibility requirements became applicable to new products and newly published digital content. Enforcement is expected to intensify across EU countries during 2026 as monitoring authorities get up to speed, and individual EU Member States have transposed the EAA into their national legal frameworks.

This post is a practical guide for store owners, product managers, and developers. It maps the six key customer journeys - catalogue, product page, search and filters, cart, checkout, and account - to the specific WCAG 2.1 AA behaviours that matter most. No platitudes, no padding.

E-commerce is explicitly in scope - including your store

'E-commerce services' are one of the named in-scope services under the EAA. The Act applies to any provider that offers e-commerce services to consumers in the EU regardless of whether that provider is in the EU or not, and regardless of whether the services or products sold by the provider are otherwise within the scope of the EAA.

That last point is worth sitting with. Any organisation selling products or services to EU customers must comply, regardless of where the company is headquartered. A US-based e-commerce site serving European customers falls under EAA requirements. The same applies to UK, Australian, or Canadian merchants with EU buyers.

There is one meaningful exemption: micro-enterprises with fewer than 10 employees and an annual turnover rate below €2 million are not required to comply. If you are above that threshold, you are in scope.

The technical standard: WCAG 2.1 AA via EN 301 549

The presumed compliance standard for the EAA is EN 301 549, which incorporates WCAG 2.1 Level AA. The current harmonised version is EN 301 549 v3.2.1, referenced in the Official Journal of the European Union. While WCAG 2.2 exists, it is not yet incorporated into the harmonised standard, meaning WCAG 2.1 AA remains the operative benchmark for EAA compliance.

That said, a WCAG 2.2 update to EN 301 549 is expected in 2026. WCAG 2.2 AA is backwards-compatible with 2.1, so targeting it now creates no compliance conflict and future-proofs your work. Think of 2.1 AA as the legal floor and 2.2 AA as the sensible forward target.

WCAG 2.1 AA is the current legal floor under the EAA. EN 301 549 v3.2.1 is the harmonised standard. Targeting WCAG 2.2 AA is good practice and future-proofs your store, but 2.1 AA is what regulators are measuring against today.

Why it matters beyond compliance

The World Health Organization estimates that 1.3 billion people - about 16% of the world's population - live with a disability. That is a substantial share of any store's potential audience. The business case is direct: 71% of people with disabilities abandon a website they find difficult to use. According to AudioEye's 2026 Accessibility Advantage Report, 62% of business leaders believe customers have abandoned transactions due to accessibility issues, representing measurable revenue loss.

Compliance and conversion pull in the same direction. Fixing the checkout for a screen reader user also fixes it for someone on a slow mobile connection, someone using a keyboard because their mouse broke, and someone who simply finds cluttered forms confusing.

The journey-by-journey checklist

The following checklist is structured around the six stages a customer moves through in a typical online store. Work through them in order - the conversion path (product page -> cart -> checkout) is where inaccessibility costs you the most.

Isometric diagram of an e-commerce customer journey showing six connected stages: catalogue grid, product detail page, search and filter panel, shopping cart, checkout form, and account dashboard - each stage represented as a distinct platform tile with subtle accessibility icons

1. Catalogue and listing pages

The catalogue is often the first page a user lands on after a search. Failures here mean they never reach the product.

Keyboard-navigable grids. All functionality must be available via keyboard. Every interactive element - links, buttons, menus, dropdowns, modals, carousels, accordions - must be operable using only a keyboard (Tab, Enter, Space, Arrow keys, Escape).
Meaningful link text. "Click here" or "View" repeated across 48 product cards is useless to a screen reader user scanning by links. Each product link should include the product name: "View Blue Linen Shirt, £45".
Visible focus indicators. WCAG 2.4.7 requires that keyboard focus is always visible. Many themes suppress the browser's default outline with outline: none and replace it with nothing. Check this first - it is one of the most common failures.
Accessible filters and sort controls. Filter panels built as custom dropdowns or checkbox groups need correct ARIA roles, states (aria-checked, aria-expanded), and labels. A filter that works fine with a mouse but traps keyboard focus is a WCAG 2.1.2 failure.
Colour contrast. WCAG 2.1 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Sale badges, category labels, and "Out of stock" overlays are common failures. Use our colour contrast checker to verify any pairing in seconds.

2. Product pages

The product page is where purchase intent is formed. Accessibility failures here are conversion failures.

Descriptive alt text for product images. Alt text for a product image is not "image1.jpg" or even "blue shirt". It should describe what a buyer needs to know: "Blue linen shirt, relaxed fit, spread collar, chest pocket". For lifestyle images where the product is incidental, a brief description of the scene is fine.
Accessible image zoom and galleries. Lightboxes and zoom widgets are frequently keyboard traps. Ensure they can be opened, navigated, and closed with a keyboard, and that focus returns to the trigger element on close.
Variant selectors (size, colour). Custom <div>-based selectors for size or colour need role="radiogroup" / role="radio" with aria-checked states, or use native <fieldset> and <legend> with <input type="radio">. The programmatic name, role, and value must all be exposed (WCAG 4.1.2).
Price and stock in text, not colour alone. "In stock" shown only as a green dot fails WCAG 1.4.1 (Use of Colour). The text "In stock" or "Only 2 left" must be present alongside any colour indicator.
Accessible video. Product demo videos need captions (WCAG 1.2.2) and, where the visual content conveys information not in the audio, audio descriptions (WCAG 1.2.5).

3. Search and filters

Search is the fastest path to purchase for many users. Inaccessible search is a dead end.

Results announced to screen readers. When a search returns results, a live region (aria-live="polite") should announce the count: "24 results for 'linen shirt'". Without this, a screen reader user submits the form and hears nothing.
Error tolerance and suggestions. WCAG 3.3.3 (Error Suggestion) requires that if an input error is detected and suggestions are known, they are provided. A "No results" page that offers spelling suggestions or related categories satisfies this.
Filter state communicated programmatically. When a filter is applied, the change in results and the applied filter state must be communicated - not just visually. Use aria-live regions and ensure filter toggles expose their checked/unchecked state via ARIA.
Reflow at 400% zoom. WCAG 1.4.10 requires content to reflow without horizontal scrolling at 400% zoom (equivalent to a 320 CSS pixel viewport width). Filter sidebars that collapse into an accessible drawer on mobile often break at high zoom on desktop.

4. Cart

The cart is where users review their intent to buy. Friction here causes abandonment.

Clear, programmatic labels. Every input - quantity fields, gift message boxes, coupon codes - needs a visible <label> element associated via for/id. Placeholder text is not a label.
Quantity steppers. Increment/decrement buttons must have accessible names (not just "+" and "-"). Use aria-label="Increase quantity of Blue Linen Shirt". The current value must be readable by assistive technology.
Status messages announced. When a user updates a quantity or removes an item, the resulting status message ("Cart updated - 2 items") must be in an aria-live region. Without this, a screen reader user has no confirmation the action worked.
No colour-only error states. If a coupon code fails, the error must be conveyed in text, not just by turning the input border red.

5. Checkout

Checkout is the highest-stakes journey. 54% of the most popular e-commerce sites have critical form accessibility failures, including missing labels, unclear error messages, and inaccessible CAPTCHA. Every failure here is a lost sale.

Properly labelled form fields. Form accessibility failures are particularly high-stakes because they prevent users from completing transactions. According to AudioEye's research, 1 in 4 forms are missing descriptive labels for people with disabilities. Every field needs a <label>.
Autocomplete attributes. WCAG 1.3.5 (Identify Input Purpose) requires that fields collecting personal data - name, address, email, card number - carry the correct autocomplete attribute. This is not just about convenience; it is a legal requirement under the EAA's technical standard.
Errors identified in text and linked to fields. WCAG 3.3.1 requires that input errors are described in text. WCAG 3.3.3 requires that suggestions for correction are provided where possible. The error message must be programmatically associated with the field it describes - not just displayed somewhere on the page.
No reliance on timeouts, or adjustable ones. If your checkout session expires, WCAG 2.2.1 requires that users are warned and given the option to extend. A silent timeout that loses a filled form is both an accessibility failure and a conversion disaster.
Accessible payment widgets. Embedded payment iframes (Stripe, Adyen, Klarna) must themselves be accessible. Check your payment provider's accessibility conformance report. If the iframe is a keyboard trap, you own the problem even if you did not write the code.
Accessible CAPTCHAs. Image-only CAPTCHAs are a hard blocker for screen reader users. Use audio alternatives, or better, switch to a non-CAPTCHA bot-detection method.

Test checkout with a keyboard only, from start to finish. Unplug your mouse and try to complete a purchase. Most teams discover their first critical blocker within 60 seconds of trying this.

6. Account and post-purchase

Account creation, order history, and returns are often neglected in accessibility audits. They matter for repeat customers and for users who need to manage returns independently.

Registration and login forms. Same rules as checkout: labelled fields, autocomplete, text-described errors. WCAG 2.2's new criterion 3.3.8 (Accessible Authentication) - not yet in the legal floor but worth adopting - requires that login does not depend on a cognitive test if a simpler alternative exists. Support password manager paste.
Order history tables. Data tables need <th> elements with scope attributes so screen readers can associate header cells with data cells. A table that reads as a flat list of text is unusable.
Focus management in modals. Return/refund confirmation dialogs and address edit modals must trap focus inside the modal while open, and return focus to the trigger element on close. This is a very common failure in custom-built UI components.

A note on global requirements that cut across all journeys

A few criteria apply everywhere, not just to one stage:

Requirement	WCAG criterion	Common failure in e-commerce
Text contrast 4.5:1	1.4.3	Sale badges, muted helper text, ghost buttons
Responsive reflow	1.4.10	Sidebars, sticky headers at 400% zoom
Resize text to 200%	1.4.4	Fixed-height containers that clip text
Accessible cookie/consent banners	2.1.1, 4.1.2	Consent modals that trap focus or can't be dismissed by keyboard
Skip navigation link	2.4.1	Missing on most Shopify themes by default

Cookie and consent banners deserve a specific mention. They are the first interactive element most users encounter, and they are frequently inaccessible - keyboard traps, no visible focus, close buttons with no accessible name. An inaccessible consent banner is an EAA failure before the user has even seen your catalogue.

What about accessibility overlay plugins?

If you have been looking at overlay or widget plugins as a shortcut, the honest answer is in our post Do accessibility overlays make you compliant? - but the short version is: no. Automated tools catch roughly 30-40% of accessibility barriers. EN 301 549 conformance requires manual testing with assistive technologies across real user workflows. An overlay cannot fix missing alt text that was never written, broken keyboard navigation in a custom component, or an inaccessible payment iframe. It also cannot produce the accessibility statement the EAA requires.

Real conformance means fixing the underlying code and content. There is no shortcut.

Use this widget to prioritise your work

Not every store has the same starting point. Use the planner below to identify which journeys to tackle first based on your current situation.

What you actually need to do

Here is the practical close, in plain order:

1. Audit the conversion path first. Product page -> cart -> checkout. These are the highest-stakes journeys and the most common source of EAA complaints. Use a keyboard and a screen reader (NVDA on Windows, VoiceOver on Mac) - not just an automated scanner. Automated tools catch roughly 30-40% of accessibility barriers. The rest require human judgement.

2. Fix the blocking issues. Missing form labels, keyboard traps, inaccessible variant selectors, and colour-only error states are the most common critical failures. Fix these before anything else.

3. Publish an accessibility statement. Article 13 of the EAA Directive requires every covered economic operator to produce and publish an accessibility statement. The statement explains how your product or service meets the accessibility requirements, where it falls short, and what a user can do if they encounter a barrier. Most companies do not realise this is a separate obligation from 'be accessible.' You can build the most accessible app in Europe and still be in breach of the EAA if you do not publish the statement.

4. Keep testing. Meeting the June 2025 deadline was not a one-time event. The EAA requires organisations to maintain compliance on an ongoing basis - meaning accessibility obligations apply to new content, updated products, and any new digital services introduced after the deadline. Regular auditing and testing are necessary to sustain compliance as products and technology evolve.

Our free WCAG 2.1 AA checklist lists every Level A and AA criterion in plain English, with pass/fail tests you can run yourself. Start there, then bring in assistive technology testing for the conversion-critical flows.

help_outlineDoes the EAA apply to my Shopify store if I'm based outside the EU?expand_more

Yes. The EAA applies to any provider offering e-commerce services to consumers in the EU, regardless of where the provider is based. A store in the US, UK, Canada, or Australia that accepts orders from EU customers is in scope. The only exemption is for micro-enterprises with fewer than 10 employees and under €2 million annual turnover.

help_outlineWhat is the legal technical standard — WCAG 2.1 or 2.2?expand_more

WCAG 2.1 Level AA, via the harmonised standard EN 301 549 v3.2.1, is the current legal floor. WCAG 2.2 is not yet incorporated into the harmonised standard, though an update is expected in 2026. Targeting WCAG 2.2 AA now is sensible — it is backwards-compatible and future-proofs your store.

help_outlineWill an accessibility overlay plugin make my store compliant?expand_more

No. Automated tools — including overlay widgets — detect only around 30–40% of WCAG issues. The rest require manual testing with assistive technologies. An overlay cannot fix missing alt text, broken keyboard navigation, or an inaccessible payment iframe. It also cannot produce the accessibility statement the EAA requires.

help_outlineWhat is an accessibility statement and do I need one?expand_more

An accessibility statement is a published document explaining how your store meets the EAA's accessibility requirements, where it falls short, and how users can report barriers. Article 13 of the EAA Directive makes it a separate legal obligation — distinct from the requirement to be accessible. You need one even if your store is fully conformant.

help_outlineWhere should I start if I have limited time and budget?expand_more

Start with the conversion path: product page, cart, and checkout. Test with a keyboard only (no mouse) and with a screen reader. Fix missing form labels, keyboard traps, and colour-only error states first. Then publish an accessibility statement. These steps address the most common EAA complaints and the highest-impact conversion barriers simultaneously.