E-commerce accessibility: the EAA checklist for the purchase journey, screen by screen

Since 28 June 2025, e-commerce accessibility has no longer been a matter of good practice: the European Accessibility Act requires online shops and shopping apps to let a person with a disability search, choose, order and pay on their own. Most pages on the subject list general principles; this one follows the purchase journey screen by screen, from the home page to the invoice, setting out for each step the checks you can carry out yourself, the WCAG success criterion concerned and the defects most often found in audits. It ends with the evidence to keep, the questions to put to your payment providers and a 90-day compliance plan for an accessible online shop.

E-commerce accessibility: which online shops are covered

The European Accessibility Act, or Directive (EU) 2019/882 on the accessibility requirements for products and services, covers e-commerce services provided to consumers. The directive defines them 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. Three conditions must therefore be met together: a contract concluded online, with a consumer, through a website or an app.

The decisive test is not the business sector but what the page does. A brochure site that presents a brand without allowing anyone to order is not, on that basis, an e-commerce service. As soon as it lets visitors buy, book a service, take out a subscription or pay, it falls within scope, whether it sells shoes, concert tickets, yoga classes or parking spaces. Sector-specific details, notably for banking and transport, are covered in our article on what the authorities check under the European Accessibility Act.

In France, two regimes can overlap. A company whose turnover in France exceeds €250 million is also subject to article 47 of the law of 11 February 2005: an accessibility statement, a compliance notice on the home page, a multi-year plan and an assessment against the RGAA, the French accessibility framework. This dual obligation is explained in our article on digital accessibility obligations in France. For a small or medium-sized business, the first step is to check whether the exemption applies, which the page on digital accessibility for SMEs and mid-sized companies helps you to do.

What the EAA actually requires of an e-commerce site

Annex I of the directive does not cite any standard. It sets outcomes. For all services, it requires in particular that websites and apps be made perceivable, operable, understandable and robust, in a consistent and adequate way, and that information on how the service works and on its accessibility features be provided in an accessible form. For e-commerce, it adds three specific requirements, which the Luxembourg market surveillance office sets out, with example solutions, in its guide to the additional requirements for e-commerce services (in French):

• providing information on the accessibility of the products and services being sold, where that information is supplied by the responsible economic operator, for example the manufacturer;
• ensuring the accessibility of identification, security and payment functionality when it is delivered as part of the service;
• providing identification methods, electronic signatures, security and payment services that are perceivable, operable, understandable and robust.

The third requirement has the heaviest consequences. It targets precisely the building blocks that merchants do not develop themselves: the payment provider's page, strong customer authentication for the cardholder, the signing module for a rental or credit agreement. The Luxembourg office gives two examples of solutions: a payment interface that can be operated by voice, allowing a blind person to shop independently, and identification dialogue boxes that can be read by a screen reader.

In France, article D. 412-57 of the French Consumer Code (in French) turns these requirements into obligations of conduct for the service provider: design and provide the service in line with the requirements set by ministerial order; prepare and make public, in writing and orally, the information explaining how the service meets them, and keep that information for as long as the service is offered; put procedures in place so that the service remains compliant; take corrective action in the event of non-conformity and inform the authorities; and, finally, provide on reasoned request the material demonstrating compliance.

To show that a journey achieves these outcomes, auditors rely on the WCAG 2.2 guidelines, which became a W3C Recommendation on 5 October 2023, and on the European standard EN 301 549. No version of that standard yet confers a presumption of conformity under the EAA, as none has been cited in the Official Journal of the Union. In practice, WCAG 2.2 level AA is the safest target: it is the level to which version 4.1.1 of the standard is aligned, published on 2 September 2026 and not yet cited in the Official Journal. The correspondences between WCAG, EN 301 549, the RGAA and the Luxembourg RAWeb are detailed in our comparison of digital accessibility standards.

How to use this e-commerce accessibility checklist

The checklist that follows is organised like a customer's journey. For each screen, it states what to check, gives in brackets the number of the corresponding WCAG 2.2 success criterion, and describes the most frequent defect. It does not replace a full audit: it allows a product team to spot the major blockers in a single day, prioritise fixes and prepare for an audit in good conditions.

Four simple steps are enough for most of the checks, with no technical skills required:

1. Unplug the mouse. Move through the screen with the Tab key, go back with Shift + Tab, activate with Enter or Space and close with Esc. You must always be able to see where the focus is and be able to do everything.
2. Turn on a screen reader. VoiceOver on iPhone and Mac, TalkBack on Android, NVDA (free) on Windows. Listen to what is announced for each button, each field and each message: a name, a role and a state.
3. Zoom to 200%, then narrow the window to 320 pixels wide. The text must enlarge without being cut off, and the page must be readable without horizontal scrolling (criteria 1.4.4 and 1.4.10).
4. Test on a real phone. Most orders are placed on mobile: check the size of touch targets, complex gestures and screen orientation.

Record each defect with a screenshot, the page address, and the browser and tool used. This log becomes your first tracking document, and it will let the auditor check quickly whether the problems you found have been fixed. Keep it in a shared space rather than in someone's inbox: the people who fix the defects are rarely the people who found them.

Screen 1: home page, menu and banners

The home page rarely contains the most serious blockers, but it holds the components that cause trouble on every page: the cookie consent banner, the newsletter sign-up pop-up, the main menu and the promotional carousel. A defect here is repeated across the whole site.

• The cookie banner receives focus when it opens, can be read by a screen reader and can be closed with the keyboard; its “Accept” and “Reject” buttons have sufficient contrast (2.1.1, 1.4.3). Common defect: a banner that is invisible to the screen reader yet still blocks clicks.
• A skip link lets users go straight to the main content (2.4.1).
• The mega menu opens and closes with the keyboard, and every subcategory can be reached with Tab or the arrow keys; the button that opens it announces whether it is “expanded” or “collapsed” (2.1.1, 4.1.2).
• A carousel that scrolls automatically can be paused (2.2.2) and its arrows have an explicit name, not just an icon.
• The newsletter sign-up pop-up does not appear in the middle of data entry, receives focus, closes with Esc and returns focus to where it was.
• Sticky promotional banners do not entirely hide the element that has focus (2.4.11), a frequent defect with “free delivery” bars fixed to the bottom of the screen on mobile.
• The logo and the basket and account icons have an accessible name; the basket icon also announces the number of items (1.1.1, 4.1.2).

Text contrast is measured against criterion 1.4.3: 4.5:1 for body text, 3:1 for large text. Crossed-out prices in light grey, legal notices in small print and white “new” labels on pastel backgrounds often fail. Criterion 1.4.11 also requires a contrast of 3:1 for field borders when they are needed to identify the field, and for icons needed to understand the content.

Screen 2: search, product listings and filters

Search is often the first thing a screen reader user does, because browsing a catalogue page by page takes a long time. Results lists and filters are also where poorly conveyed dynamic components tend to accumulate.

• The search field has a label, not just placeholder text that disappears when typing starts (3.3.2).
• Suggestions that appear while typing are announced and can be browsed with the arrow keys; Enter launches the search without trapping the user.
• The number of results is announced after a search or after a filter is applied, without moving the focus: this is a status message (4.1.3).
• Each filter is a genuine checkbox or a genuine button whose “checked” or “applied” state is conveyed (4.1.2). Common defect: clickable colour swatches announced as “button, button, button”.
• The two-handle price slider has an alternative: two “minimum price” and “maximum price” fields, or handles that can be adjusted with the keyboard (2.1.1, 2.5.7).
• Changing the sort order or a filter does not reload the page without warning and does not send the focus back to the top of the page (3.2.2).
• In the listing, each product card has a single main link whose text includes the product name, rather than three identical “View” links (2.4.4).
• Infinite scrolling is supplemented by a “Show more products” button and does not make the footer unreachable, which is often where contact details and terms of sale are found.

One simple test sums up this screen: using a screen reader, search for “white trainers”, filter by your size and sort by price, lowest first. If at each step you do not know how many products are still displayed and which filters are active, the journey cannot be completed independently.

Screen 3: an accessible product page

The product page is the screen where the buying decision is made. It combines images, variant choices, prices, reviews and often a video. It is also where Annex I requires information on the accessibility of the product being sold, where the manufacturer supplies it.

Information on the accessibility of the product is a requirement specific to e-commerce, and it is often overlooked. It mainly concerns products that are themselves covered by the EAA or whose manufacturer documents their accessibility: a computer, an e-reader, a phone, a television. If the manufacturer provides this information, the product page must include it, in an accessible form. Plan a dedicated field in your product information management system and ask your suppliers for it when listing new products.

Writing matters as much as code. A well-written text alternative for a dress describes what a sighted person understands by looking at the photo: the cut, the length, the pattern. For a product content team, this is a skill that can be learned in a few hours, and it is often where our digital accessibility training for content teams begins. A short internal style guide, with three or four examples per product category, keeps descriptions consistent when several people write them.

Screen 4: basket and mini-basket

The basket is a highly dynamic screen: every change in quantity recalculates the totals, the delivery charges and sometimes the discounts. For someone who cannot see the screen, every unannounced change is lost information.

• The “+” and “−” quantity buttons have a full name (“increase quantity of white trainers”) and the new quantity is announced (4.1.2, 4.1.3).
• The remove button states which item it removes, and the removal is confirmed by a message (2.4.4, 4.1.3).
• The update to the total and to the delivery charges is announced, or at the very least the total stays in a predictable, readable place.
• The promo code field has a label; a rejected code produces a text error message linked to the field (3.3.1).
• A mini-basket that slides open as a drawer receives focus, closes with Esc and does not let the focus escape behind it into the page (2.4.3).
• A basket “reserved for 10 minutes” or a session that expires warns the user, gives them at least twenty seconds to extend the time limit with a simple action, and allows them to extend it at least ten times (2.2.1).
• Touch targets measure at least 24 by 24 CSS pixels or are sufficiently spaced (2.5.8): the small remove crosses on mobile are a frequent source of errors.

Cross-selling raises a particular problem. “You may also like” blocks inserted between the basket and the checkout button lengthen the journey for keyboard and screen reader users. Place them after the main button or in an area that can easily be skipped.

Screen 5: account creation, login and CAPTCHA

Account creation and login are the screens where defects become blocking. A blind person can work around a poorly described image on a product page; they cannot work around a CAPTCHA they cannot perceive. This is also where the Annex I requirement on identification methods applies.

1. Offer guest checkout. A guest journey reduces the number of screens and fields. It is not an obligation, but it is the simplest way of limiting risk.
2. Label every field and declare its purpose. Name, email address, phone number and postal address fields carry the appropriate autocomplete attribute, which allows the browser to fill them in automatically (1.3.5); instructions, such as the password format, are given before data entry (3.3.2).
3. Allow the password and the received code to be pasted. WCAG 2.2 criterion 3.3.8 prohibits requiring a cognitive function test, such as remembering or transcribing characters, without an alternative: copy and paste and password managers must work.
4. Replace the visual CAPTCHA. A CAPTCHA based on images or distorted characters must have an alternative that does not rely on the same ability. Solutions that analyse behaviour in the background, without any action from the user, or verification by email, cause fewer difficulties.
5. Display a button to show the password. It helps people with motor or memory impairments, and it must itself have a name and a state that are conveyed.
6. Write useful error messages. “Invalid email address: the @ character is missing” rather than “Input error”, placed next to the field and announced to the screen reader (3.3.1, 3.3.3).

The one-time code sent by text message deserves a specific test on mobile. Users must be able to leave the app, read the message and come back to enter the code before it expires. Automatic filling of the code by the operating system helps a great deal, provided that the field is declared correctly.

Screen 6: delivery, payment and strong authentication

The checkout is the part of the site that authorities and complainants examine first, because a defect there prevents the purchase itself. It mixes forms developed by the merchant with components supplied by third parties: the pick-up point map, the payment provider's page and the authentication window of the customer's bank.

Address and delivery method

• The billing address can reuse the delivery address through a checkbox, without re-entering it (3.3.7).
• The pick-up point can be chosen from a text list sorted by distance, in addition to the interactive map, which is rarely usable with a keyboard or a screen reader (1.1.1, 2.1.1).
• Delivery slots presented as a grid state in text the date, time, price and availability of each slot, and the chosen slot is conveyed as selected (1.3.1, 4.1.2).
• Delivery methods are genuine radio buttons grouped under a legend (1.3.1).

Payment and strong authentication

• The card fields, often embedded in a frame supplied by the payment provider, each have a conveyed label, including the expiry date and the security code (3.3.2, 4.1.2).
• The embedded frame has a title, and the focus moves into and out of it normally with the keyboard (2.4.3).
• Payment methods shown as logos have a text name (1.1.1).
• The strong authentication step, displayed by the customer's bank, does not time out while a screen reader user switches from one app to another; if it fails, a clear message allows the user to try again.
• Before confirmation, a summary allows the user to check and correct the items, the address and the amount (3.3.4).
• The checkbox for accepting the terms and conditions has a clickable label and the link to the terms is accessible; the final button says what it does, for example “Order with obligation to pay”, the wording French consumer law expects (“Commande avec obligation de paiement”, or an equally unambiguous phrase), and not just an arrow.

A reliable diagnostic approach is to place a real order, all the way to payment, with a screen reader on a computer and then on mobile, using a test card supplied by the payment provider. This is the scenario in which an EN 301 549 and WCAG compliance audit adds the most value: it lists the defects, but also identifies who must fix them, the merchant or the provider.

Screen 7: confirmation, emails, invoices and customer service

The journey does not end with the click on “Place order”. Buyers must be able to understand that the order has gone through, track the delivery, view their invoice, return an item and contact customer service. These screens are often produced by tools other than the website itself: email software, invoice generator, returns management tool, chatbot.

• The confirmation page clearly announces that the order was successful and gives its number, with an explicit page title (2.4.2).
• Confirmation and dispatch emails are readable as text, with headings, explicit links and images that have alternatives; parcel tracking does not rely on an image.
• Downloadable invoices and returns labels are tagged PDFs, or their content is available in HTML in the customer account.
• The returns form follows the same rules as the checkout: labels, explicit errors, no blocking CAPTCHA.
• The link to help and contact is in the same place on every page (3.2.6, introduced in WCAG 2.2).
• The chatbot, if there is one, can be used with a keyboard and a screen reader, and is not the only way to reach customer service: a form, an email address or a phone number remain available.

Annex I also covers, where applicable, support services: help desks, call centres, technical support, relay services and training services. They must provide information on the accessibility of the service and its compatibility with assistive technologies, through accessible means of communication. An adviser who knows how to guide a screen reader user to the right button, or who can take the order through another channel, is part of compliance.

Payment, reviews, chat, CAPTCHA: third-party components and who is responsible

An average online shop assembles around ten external components. Each of them can break the accessibility of a journey that is otherwise compliant. The directive does not provide for any transfer of responsibility to these suppliers: towards the consumer and the authority, it is the provider of the e-commerce service who is answerable. The only effective response lies in contracts and documentation.

Build these requirements into your contracts and your calls for tender: the expected level, the evidence to be supplied, the deadline for fixing reported defects and notification of any new version. For each release, an accessibility acceptance test checks that the new version of the component does not make the journey regress. When a supplier cannot keep up, document the alternative offered to customers and the replacement timetable.

The ten most common errors on an e-commerce site

These errors come up in audit after audit, whatever the platform used. They are rarely expensive to fix when they are dealt with in the theme or in shared components, once and for all pages.

1. Buttons with no name. Basket, wishlist and close icons, carousel arrows: the screen reader announces “button” and nothing more.
2. Silent variants. Colour and size swatches with no name or state, which prevent the customer from choosing the right item.
3. Silent additions to the basket. No confirmation is announced, so the user adds the same product three times to be sure.
4. Windows that trap the focus. A mini-basket, sign-up pop-up or size guide that cannot be closed with the keyboard.
5. Contrast that is too low. Crossed-out prices, delivery notices and text over photos below 4.5:1.
6. Forms without labels. Placeholder text used as the only label, which disappears when typing starts.
7. Vague error messages. “An error has occurred” in red at the top of the page, with no indication of the field concerned.
8. A CAPTCHA with no alternative. A visual test imposed at account creation or at payment.
9. An untested payment step. The provider's frame has never been tried with a screen reader or on mobile.
10. Accessibility that regresses. The site is fixed, then a promotional campaign or a new theme reintroduces the defects because nothing was checked before going live.

The first five are usually fixed in the theme's components: a well-built button, swatch or modal window solves the problem everywhere. This is the work our developers specialising in accessibility carry out alongside your teams, starting with the most widely used components.

Evidence to keep and the accessibility information page

On the day of an inspection or a formal notice, the question is not only “is the site accessible?”, but “what can you demonstrate?”. In France, the DGCCRF, the authority responsible for consumer protection, checks e-commerce services; its officers can order a business to bring its service into compliance, and breaches are fifth-class petty offences (contraventions de cinquième classe). In Belgium, e-commerce is checked by the Economic Inspectorate of the FPS Economy; in Luxembourg, by the Office de la surveillance de l'accessibilité des produits et services (OSAPS). Each country's regime is detailed in our articles on Belgium and Luxembourg.

The information page provided for in Annex V of the directive is not just another legal text. Linked from the footer, it describes the service and explains how it meets the requirements, in a format that is itself accessible. In Luxembourg, the market surveillance office provides a template information sheet for services covered by the law of 8 March 2023. For a French company that is also subject to article 47, this page can sit alongside the accessibility statement, provided that each meets its own requirements: the method is explained in our article on the accessibility statement and its common mistakes.

Exceptions must be documented before they are relied upon. In Luxembourg, an operator invoking an exemption on the grounds of a disproportionate burden or a fundamental alteration informs the office through an online procedure, with supporting documents. Remember that the directive expressly rules out lack of priority, time or knowledge as a justification.

For an online shop, the most concrete risk today is litigation. In France, on 4 June 2026, the Caen judicial court, hearing an urgent application by two associations, ordered a major retail chain to make its website and app accessible within six months, subject to a daily penalty, rejecting the argument of a 71% compliance rate. In Lille, on 5 May 2026, the judge hearing urgent applications had on the contrary dismissed the same associations' claim against the online retail subsidiary of another chain, on the grounds that its turnover was below the €250 million threshold of article 47, a reading of how this provision fits with the Consumer Code that some lawyers dispute. Consumers can also report an accessibility defect to the DGCCRF through SignalConso or the RéponseConso service, as stated in the DGCCRF consumer fact sheet on the accessibility of products and services (in French).

A 90-day EAA e-commerce compliance plan

An online shop is not made accessible in one go. The aim of the first three months is to remove the blockers that prevent people from buying, to document the approach and to put in place the checks that will prevent regressions. The timetable below suits a medium-sized site with a development team; it takes longer for a multi-country catalogue or for several mobile apps.

1. Weeks 1 and 2: set the scope. Check eligibility and the countries you sell to, list the critical journeys (search, product page, basket, account, payment, returns, contact) and the third-party components, then run the checklist in this article on each screen. For groups operating in several countries, the large enterprises page sets out an approach by brand and by market.
2. Weeks 3 to 5: audit. Have the critical journeys assessed against WCAG 2.2 level AA and the EN 301 549 standard, on desktop and on mobile. In our practice, an audit takes three weeks on average; the report should identify, for each defect, the component and the team responsible.
3. Weeks 4 to 10: fix what blocks first. Deal first with the defects that prevent an order from being completed, then those that affect every screen through shared components, and finally content defects. At the same time, open requests with third-party suppliers.
4. Weeks 8 to 11: test with users. Ask people who use a screen reader, voice control or a magnifier every day to place real orders. User testing with people with disabilities reveals blockers that no checklist measures, and provides strong evidence.
5. Weeks 10 to 12: publish and set up monitoring. Publish the information page, the remediation plan and an accessible means of contact. Add accessibility criteria to the definition of “done” for each feature and an acceptance test before each release, particularly before sales campaigns.

This approach fits into the broader framework presented in our guide to digital accessibility. For a company that also sells to public bodies in France, an RGAA audit carried out according to the official method can be conducted on the same sample, which avoids testing the same screens twice. A Swiss company selling in the Union will find the correspondences with the eCH-0059 standard on the page on digital accessibility in Switzerland.

Frequently asked questions