An EAA ecommerce checklist for 2026 starts with a legal fact: the European Accessibility Act has applied to covered services since 28 June 2025. If your online store, mobile app, or marketplace service lets consumers choose products and complete a purchase, accessibility work is already a business requirement.
Many teams still treat accessibility as a visual audit of the homepage. That misses the parts that determine whether a shopper can search, select a variant, recover from an error, pay, and receive an order confirmation. Use the checklist below to set priorities, assign owners, and document progress after the deadline.
What the European Accessibility Act requires in 2026
The compliance date has already passed
Directive (EU) 2019/882, commonly called the European Accessibility Act, harmonises accessibility requirements for selected products and services across the EU. Member States had to apply their national measures from 28 June 2025.
That makes 2026 a post-deadline remediation period. A store that has unresolved accessibility barriers should record them, rank their impact, and set dated fixes. Waiting for a complaint before testing is a weak compliance strategy because shoppers may already be unable to complete essential tasks.
The European Commission’s EAA overview provides the EU-level context. Enforcement, complaints, penalties, and competent authorities are handled through national systems, so check the countries where you sell.
What counts as an ecommerce service
The directive defines an e-commerce service as a service provided at a distance through websites or mobile-device-based services, by electronic means, at the individual request of a consumer, with the goal of concluding a consumer contract.
In practical terms, scope can include:
- A consumer-facing online shop that sells physical products.
- A mobile shopping application that supports orders and payment.
- A site that sells subscriptions, tickets, downloads, or other services.
- A marketplace feature that lets a consumer conclude a contract.
- Account, delivery, payment, and order-management steps connected to the purchase.
The obligation applies to the online sale of any product or service, even where the product or service has separate accessibility rules. The EUR-Lex summary of accessibility legislation is a useful starting point for the covered categories.
A purely B2B portal may need a different scope analysis because the EAA definition focuses on consumer contracts. However, a business serving both B2B and B2C buyers shouldn’t assume that account labels remove its consumer obligations.
EAA ecommerce checklist: confirm scope before fixing screens
Map markets, storefronts, and responsible entities
Create a scope register for every customer-facing buying journey. Include country domains, languages, mobile apps, guest checkout, logged-in purchasing, marketplace pages, and embedded payment experiences.
Then record:
- The legal entity selling to the customer.
- The countries where the service is offered.
- The products and services sold online.
- The platform, agency, and vendors that control each component.
- The consumer tasks that form part of the contract journey.
- The national accessibility authority or contact point for each key market.
Don’t limit the review to the main domain. A retailer may have a separate mobile app, a regional checkout, a customer portal, or a campaign microsite that uses a different template. A payment provider may also host part of the journey outside the store’s primary domain.
National transposition can affect terminology, procedures, documentation, and enforcement. Confirm the result with the relevant national authority or qualified counsel before relying on an exemption or making a public compliance claim.
Apply exemptions and transition rules narrowly
The EAA includes an exemption for microenterprises providing services. The EU microenterprise definition generally covers a business with fewer than 10 employees and annual turnover or a balance-sheet total of no more than EUR 2 million.
That exemption has limits. It concerns service providers, not every product obligation that might apply to a manufacturer, importer, distributor, or retailer. It also doesn’t remove duties under national disability law, consumer law, public procurement rules, or another applicable regulation. Confirm how your national legislation defines and documents the exemption.
The directive also allows a five-year transition, ending 28 June 2030, for certain products used to deliver services when those products were placed on the market before 28 June 2025. That rule doesn’t give ecommerce websites and apps until 2030 to become accessible. Existing self-service terminals have separate lifespan rules, with a maximum period of 20 years in the relevant circumstances.
A retailer can compare interpretations in this EAA guide for online retailers, then obtain advice for its own structure and markets.
Provide accessible information and usable customer support
Publish service information in an accessible format
The EAA requires service providers to make information about their service available in an accessible form. That information should describe the service, explain how customers use it, and show how it meets the applicable accessibility requirements.
National laws may use different labels, such as an accessibility statement, service accessibility information, or compliance information. The label matters less than the content and its accessibility. Publish the information where customers can find it, such as the footer, help centre, or account support area.
A useful statement or equivalent page should include:
- The storefronts, apps, and buying journeys covered.
- The accessibility standard or technical reference used for testing.
- Known limitations, with a clear explanation of affected tasks.
- Contact options for reporting a barrier.
- A practical alternative route for completing an order.
- The date of the latest review and a planned review interval.
Don’t describe a site as fully compliant if your tests found an inaccessible payment step. State the current position accurately and update the page as fixes ship. A legal overview from Arthur Cox on the EAA can help teams compare information duties, but national advice still takes priority.
Make support accessible when self-service fails
Customer support is part of the shopping experience. A customer who can’t activate a discount, complete identity verification, or use a payment form needs a workable way to get help.
Offer more than one contact method where possible. Email, phone, chat, and accessible contact forms should not send customers through the same blocked journey. A support form needs a label, keyboard access, clear errors, and a confirmation that the request was received.
Train agents to handle accessibility reports without asking customers to repeat every step. Give them a process for placing an order, correcting an address, explaining payment alternatives, and escalating a third-party barrier. Keep the customer’s preferred communication method and any requested accommodation in the support record, subject to data protection rules.
Build an accessible product and account journey
Fix structure, controls, and content first
The legal baseline depends on the requirements adopted in each country and the technical references that apply. For product work, EN 301 549 is a key European reference for ICT accessibility. WCAG 2.2 Level AA is a practical internal target because it covers current web patterns, but a WCAG score alone isn’t an automatic EAA certificate.
Start with the interface elements that affect every shopping task:
- Use real headings, landmarks, lists, buttons, and form controls.
- Give product images useful alternative text, or mark decorative images appropriately.
- Expose product names, prices, stock, sizes, colours, and selected states to assistive technology.
- Make filters, sort controls, carousels, dialogs, cookie panels, and menus usable without a mouse.
- Keep labels and instructions visible instead of relying on placeholder text.
- Provide captions and accessible controls for product videos.
- Preserve focus when a dialog opens and return it to a sensible control when the dialog closes.
Your ecommerce accessibility checklist can sit beside the team’s issue tracker while designers and developers review templates.
Test keyboard, zoom, and mobile screen readers
A keyboard user must be able to reach every interactive control in a logical order. Focus should remain visible against the background, and no component should trap the user inside a menu, gallery, filter, or checkout dialog.
Test browser zoom to at least 200 percent, responsive reflow, text spacing, orientation changes, and high-contrast conditions. A page can look correct at default size yet hide the purchase button after zooming or force horizontal scrolling through a form.
For screen readers, test the shopping path rather than isolated components. Use combinations such as NVDA with a desktop browser, VoiceOver on iOS, and TalkBack on Android. Check whether the screen reader announces the product option that changed, the updated price, the quantity, the availability message, and the result of an add-to-cart action.
A page that has correct alt text but an inaccessible size selector still blocks a purchase. Test the task from search through order confirmation.
EAA ecommerce checklist for checkout and payment
Make forms recoverable
Checkout forms often contain the most serious barriers because one missing label or unclear error can stop an order. Every input needs a programmatic label, a useful autocomplete value, and instructions that remain available while the customer types.
When a form fails, identify the affected field in text, explain how to fix it, and keep valid information in place. Don’t rely on a red border or an icon alone. A message such as “Enter a valid postal code for France” helps more than “Invalid field.”
After submission, move focus to an error summary or the first invalid field. Link each summary item to its field, and announce important updates to screen-reader users. These accessible checkout error summaries cover the focus and announcement patterns teams often miss.
Checkout should also avoid unnecessary repetition. If the customer entered a shipping address, don’t make them type the same address again for billing when the system can offer a usable choice. If authentication uses a one-time code, give the user enough time, preserve their input, and provide an accessible recovery path.
Treat payment as part of the same service
A store isn’t accessible if customers can browse but can’t pay. Review every payment route, including card fields, digital wallets, buy-now-pay-later services, bank authentication, 3-D Secure screens, fraud checks, and hosted payment pages.
Payment options need visible text labels, logical keyboard order, clear selected states, and usable error messages. Icons alone don’t identify a payment method for every shopper. If a provider opens an iframe or redirects to another domain, test the complete interaction and the return to checkout.
Announce changes to the order total, shipping cost, discount, payment status, and processing errors. Don’t erase the basket or reset the form after a failed attempt. A customer should know whether the order was placed before trying again.
Review these accessible payment method selectors alongside the payment provider’s own documentation. The retailer still owns the customer experience even when another company supplies the field.
Manage third-party tools and vendor responsibilities
Inventory every external component
Third-party code can create barriers after your team has tested the main storefront. Record each tool that changes the shopping journey, including:
- Payment fields and authentication.
- Consent management platforms.
- Chat and callback widgets.
- Product reviews and user-generated content.
- Product recommendation tools.
- CAPTCHA and fraud detection.
- Customer account, returns, and invoice portals.
- Embedded video, maps, social feeds, and delivery tracking.
For every component, record the vendor, version, owner, affected tasks, loading conditions, fallback route, and last test date. Test keyboard access, focus handling, names and states, mobile screen-reader output, contrast, timeout behavior, and error recovery.
An accessibility overlay or automated toolbar doesn’t repair an unlabeled checkout control, a broken focus order, or an inaccessible payment redirect. Automated scans can help find defects, but they don’t transfer responsibility or prove that a service meets the EAA.
Put accessibility into procurement
Add accessibility requirements before a vendor is selected. Ask for a recent accessibility conformance report that identifies the tested product version, standard, test methods, known defects, and remediation plans. A generic statement that a product is “accessible” provides little evidence.
Your contract should cover:
- The accessibility standard and scope of the supplier’s promise.
- Testing access for your QA team and an independent tester.
- Defect severity definitions and repair times.
- Notice of material interface or component changes.
- Support for complaints and regulatory information requests.
- A fallback or replacement plan for persistent barriers.
- Evidence delivery after major releases.
Assign an internal owner for each vendor. Procurement can require evidence, but product and engineering teams still need to test the combined service. A payment widget may pass its own test while failing inside your modal, language version, or mobile checkout.
Test against WCAG and real shopping tasks
Use automation as a first pass
Automated tools such as axe, Lighthouse, and browser accessibility inspectors can find missing labels, duplicate IDs, some contrast failures, invalid ARIA, and certain structural problems. Run them against templates and key states, including open menus, validation errors, empty carts, discount failures, and confirmation pages.
Automation can’t judge whether alternative text makes sense, whether a product variant is understandable, or whether a screen-reader user knows that a price changed. It also misses many keyboard traps and confusing recovery paths.
Treat a clean scan as a starting point. Map each finding to the relevant WCAG criterion and the applicable EN 301 549 requirement. Record the tested URL, state, browser, tool version, date, and responsible owner.
Add manual and assistive technology testing
Run a manual pass for keyboard-only use. Start at the homepage and complete a real purchase without a mouse. Check skip links, tab order, focus visibility, menus, filters, product options, cart editing, checkout, payment, and confirmation.
Then repeat key tasks with screen readers and browser zoom. Include:
- Product search and filtering.
- Variant selection and quantity changes.
- Cart updates and stock messages.
- Address entry and error correction.
- Shipping and payment selection.
- Authentication and order confirmation.
- Account history, invoices, returns, and support.
Include people who use assistive technology in usability research when you can. Your ecommerce usability testing process should capture task completion, errors, confusion, time, and the user’s chosen technology. A specialist review can find technical defects, while a real shopper shows whether the journey works in practice.
Repeat testing after releases that affect templates, JavaScript components, payment providers, authentication, localization, or content models. Accessibility regressions often arrive through ordinary conversion work.
Prioritize fixes by shopping risk
Fix purchase blockers before cosmetic issues
Use task impact to rank the backlog. A missing decorative image description is different from a payment button that keyboard users can’t reach. Both matter, but they don’t carry the same immediate shopping risk.
A sensible order is:
- Remove barriers that prevent search, product selection, cart access, checkout, payment, or order confirmation.
- Fix form labels, error recovery, focus loss, inaccessible dialogs, and screen-reader status updates.
- Repair mobile zoom, reflow, touch target, contrast, and orientation problems.
- Improve product content, account history, returns, invoices, and support journeys.
- Address lower-risk defects that don’t block a task but still reduce clarity or independence.
Use customer complaints, failed tasks, analytics, assistive technology feedback, and legal scope to adjust priority. A high-traffic checkout defect usually deserves attention before a low-use marketing component.
Document evidence and exceptions
For each issue, record the affected journey, users, environment, WCAG criterion, EAA or national requirement, severity, owner, fix, retest result, and release date. Screenshots alone won’t show whether a keyboard sequence or screen-reader announcement worked, so retain test steps and recordings where appropriate.
If your business relies on a disproportionate-burden or fundamental-alteration exception, document the assessment. Include the service affected, technical barrier, expected cost, available resources, user impact, alternatives considered, and review date. A general claim that a fix is expensive isn’t enough.
Keep evidence for vendor assessments, customer reports, audits, published accessibility information, and completed remediation. Update it when the service, provider, or national rules change.
Copyable EAA ecommerce checklist for a 2026 tracker
Legal baseline to verify
Assign an owner, due date, status, and evidence link to each item:
- Record every EU market, storefront, mobile app, marketplace flow, and consumer checkout.
- Identify the legal entity, service provider, platform owner, and third-party vendors for each journey.
- Verify whether the service is covered under the applicable national transposition of Directive (EU) 2019/882.
- Check whether a microenterprise service exemption applies, and document why.
- Confirm that any 2030 transition rule concerns a qualifying legacy product, not the website or app.
- Publish required service accessibility information in an accessible format.
- Provide an accessible route for reporting barriers and requesting help.
- Test the complete consumer journey, including payment, authentication, redirects, and order confirmation.
- Record any disproportionate-burden assessment and its review date.
- Check the relevant national authority’s complaint, enforcement, and penalty process.
Recommended quality gates
- Set WCAG 2.2 Level AA as the internal product target, while mapping legal claims to applicable national requirements and EN 301 549.
- Run automated tests on templates and important interactive states.
- Complete keyboard-only, zoom, mobile, and screen-reader testing before release.
- Test with NVDA, VoiceOver, or TalkBack on the devices your customers use.
- Include people with disabilities in usability research for high-value journeys.
- Require accessibility evidence and defect obligations in vendor contracts.
- Review payment widgets, CAPTCHA, consent tools, chat, reviews, and account portals after vendor updates.
- Keep valid form data after errors and announce changes to totals, stock, and payment status.
- Monitor accessibility complaints as product signals, not only legal incidents.
- Retest the journey after checkout, design-system, authentication, or payment changes.
Conclusion
The strongest EAA ecommerce checklist begins with scope, then follows the customer’s actual route to purchase. In 2026, teams should focus first on keyboard access, screen-reader output, form recovery, payment, customer support, and third-party dependencies.
The EAA provides the EU framework, but national implementation controls important enforcement details. Verify your position with the relevant authority or qualified counsel, document decisions, and keep accessibility in the same release process as conversion and performance work. A store passes its most meaningful test when a customer can complete the order independently.
