FAQEuropean Accessibility Act

EAA FAQ Accessible e-commerce checkout

Q: Does the EAA require accessible identification, security, and payment in online checkout?

Yes, for e-commerce services the Directive adds specific requirements for identification, electronic signatures, security, and payment functionality when those functions are delivered as part of the service. They must be perceivable, operable, understandable, and robust, so test login, one-time passcode screens, fraud checks, wallet redirects, card fields, payment confirmation, and failure recovery as part of the checkout path.

The European Accessibility Act covers e-commerce services provided to consumers, including websites and mobile services used to conclude consumer contracts.

This FAQ helps test the complete checkout journey, keep service information and evidence together, and avoid overstating what standards evidence proves.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 24, 2026

Questions

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated Jul 24, 2026

Overview

For provided to consumers after 28 June 2025, an EAA checkout review should test whether a consumer can complete the online purchase journey with accessibility support intact. Cover product and service information, cart and account steps, identification, electronic signature where used, security prompts, payment, error recovery, confirmation, and customer support information. Apply the national law that transposes Directive (EU) 2019/882 in each market where the service is provided.

Search this module

Find a question or answer quickly

4 of 4 questions

Question 1

What does the EAA cover in an e-commerce checkout?

Directive (EU) 2019/882 defines as services provided at a distance, through websites or mobile device-based services, by electronic means and at the individual request of a consumer, with a view to concluding a consumer contract.

For checkout testing, that means the relevant scope is the consumer journey used to buy the product or service online. The review should not stop at a home page or product page audit if the consumer still needs to sign in, choose delivery, accept terms, authenticate, pay, or receive confirmation.

Confirm that the tested flow is consumer-facing and is used to conclude a consumer contract.
Include website and mobile app checkout variants when both are offered to consumers.
Include accessibility information about the products or services being sold when the responsible economic operator provides that information.
Do not treat physical point-of-sale payment terminals as the same fact pattern as online checkout; the Directive defines payment terminals as physical point-of-sale devices, not virtual environments.
Check Article 2 website and mobile-content exclusions separately. They can exclude qualifying old media, old office files, accessible-map cases, uncontrolled third-party content, or unchanged archives, but they do not remove the remaining checkout journey from scope.

How should an e-commerce checkout be tested for European Accessibility Act compliance?

Test the complete consumer contract journey, not isolated pages. A useful EAA checkout test covers product or service accessibility information, cart changes, account creation or guest checkout, identification, electronic signature where used, security checks, payment, error messages, order confirmation, and support contact paths. Record which website or mobile app version was tested, which assistive technologies or accessibility checks were used, the defects found, fixes made, retest results, and who approved release.

Does the EAA require accessible identification, security, and payment in online checkout?

Yes, for the Directive adds specific requirements for identification, electronic signatures, security, and payment functionality when those functions are delivered as part of the service. They must be perceivable, operable, understandable, and robust, so test login, one-time passcode screens, fraud checks, wallet redirects, card fields, payment confirmation, and failure recovery as part of the checkout path.

Citations

Directive (EU) 2019/882 (European Accessibility Act)

Defines e-commerce services, lists e-commerce in Article 2 scope, and separates physical payment terminals from virtual payment environments.

European Commission - European Accessibility Act policy page

Commission policy page used for the public EAA context and covered-products-and-services framing.

Recommended next step

Review the checkout evidence before release

Map your checkout journey to EAA service scope, identification, security, payment, service information, standards evidence, and release records.

Research workflow

Open Research Copilot

Check EAA scope and cited evidence before release.

Explore next step

Talk to Sorena

Talk through implementation

Review checkout flows, payment evidence, service information, and open risks.

Explore next step

Question 2

What should the checkout test cover?

Use the EAA service requirements as the control map. Annex I requires service information to be provided through accessible channels, websites and mobile services to be perceivable, operable, understandable, and robust, and available support services to provide accessibility and assistive-technology compatibility information in accessible communication modes.

For a checkout, the practical evidence should show that the user can understand the offer, move through each step, enter and review data, recover from mistakes, authenticate where required, complete payment, and receive confirmation without losing accessibility support.

Product and service information: names, prices, variants, delivery choices, accessibility information supplied by the responsible operator, and terms needed before purchase.
Third-party steps: record redirects, hosted payment fields, identity checks, wallet screens, and authentication hand-offs as part of the tested journey. A supplier report can support the evidence, but it does not by itself show that the integrated consumer journey is accessible.
Controls and navigation: keyboard path, focus order, labels, headings, state changes, modals, cart updates, and status messages.
Forms and errors: required fields, input purpose, validation messages, error suggestions, address lookup, coupon fields, and order review.
Identification and security: sign-in, account creation, password reset, multi-factor prompts, biometric alternatives where relevant, session timeout, and fraud checks.
Payment and confirmation: card fields, hosted payment frames or redirects, wallet flows, electronic signatures where used, failure messages, receipts, and order-status pages.

Can a checkout team rely on WCAG or EN 301 549 evidence alone?

No single standards label should be treated as the whole EAA answer. EN 301 549 and WCAG-based results are useful technical evidence for web, mobile, software, document, and assistive-technology behaviour, but the EAA record should also map the checkout to the Directive's service scope, e-commerce-specific identification, security and payment requirements, service information, support information, fixes, and release decision. A presumption of conformity based on a harmonised standard depends on its reference being published in the Official Journal and applies only to the requirements that the standard or part covers.

Citations

Directive (EU) 2019/882 (European Accessibility Act)

Annex I sets the general service accessibility requirements and the specific e-commerce requirements for accessibility information, identification, security, and payment.

ETSI - EN 301 549 accessibility standard overview

Official ETSI overview for EN 301 549, the ICT accessibility standard useful for mapping web, mobile, software, and assistive-technology test evidence.

Question 3

What evidence should be kept for an EAA checkout review?

Service providers must prepare information explaining how covered services meet applicable accessibility requirements, make that information publicly available in written and oral format including accessible formats, and keep it for as long as the service is in operation.

The checkout evidence pack should therefore connect public service information with release evidence. It should be clear which checkout was tested, which EAA requirements were mapped, what standards or test methods were used, what defects remain, and how changes in the service or applicable standards will be reviewed.

Scope record: consumer-facing checkout URL or app screen set, countries or markets covered, service provider owner, and whether the flow concludes a consumer contract.
Requirement map: Annex I general service requirements, e-commerce-specific identification, security and payment requirements, and any standards clauses used as technical evidence.
Test evidence: automated findings, manual keyboard and screen-reader notes, mobile app checks where relevant, payment-provider test evidence, screenshots or recordings, defect tickets, fixes, and retests.
Service information: general description of the service in accessible formats, explanation of checkout operation, accessibility statement or equivalent terms content, and support-service accessibility information.
Change control: review trigger for checkout redesigns, payment provider changes, new authentication methods, mobile app releases, harmonised-standard updates, complaints, incidents, or authority requests.

What if full checkout accessibility would require a fundamental alteration or disproportionate burden?

Do not bury that conclusion in a test report. Article 14 requires a requirement-specific assessment before relying on fundamental alteration or disproportionate burden, and relevant results must be kept for five years after the service was last provided and supplied to authorities on request. Notify the relevant service-compliance authorities when Article 14 is relied on unless the operator is a microenterprise. A service disproportionate-burden assessment must be renewed when the service changes, when an authority asks, and at least every five years. An operator that receives public or private funding from outside its own resources for the purpose of improving accessibility cannot rely on disproportionate burden, and every unaffected requirement still applies.

Citations

Directive (EU) 2019/882 (European Accessibility Act)

Article 13 and Annex V support the service-provider evidence model for public information, service-operation descriptions, monitoring, and authority response.

European Commission - accessibility standardisation

Commission source for the role of common European accessibility standards in ICT and internal-market accessibility implementation.

Question 4

Common checkout documentation mistakes

The main risk is producing a generic accessibility statement that does not prove the checkout can actually be completed. Evidence is stronger when it follows the money path and the account path from start to finish.

Do not cite EN 301 549 or WCAG as a standalone EAA conclusion without mapping the checkout to EAA service and e-commerce requirements.
Do not exclude payment-provider frames, redirects, authentication prompts, fraud checks, or wallet flows if they are necessary to complete the purchase.
Do not remove accessibility support during security steps; if security requirements constrain assistive-technology access, record the constraint and the accessible alternative tested.
Do not publish product or service accessibility information only in an inaccessible PDF, image, modal, or account-only area if consumers need it before purchase.
Do not let release evidence go stale after checkout redesigns, new payment providers, mobile app changes, or updates to the standards used in the conformance claim.

Citations

Directive (EU) 2019/882 (European Accessibility Act)

Supports the need to keep services conforming after changes and to make service information accessible.

ETSI - EN 301 549 accessibility standard overview

Supports treating EN 301 549 as ICT accessibility test evidence across web pages, mobile applications, software, hardware, and combinations.

Primary sources