Skip to content
wcagc
←Back to blog
EAAe-commerceWCAGcheckout

Checkout accessibility under the EAA: where stores fail

What the EAA requires of a checkout, which WCAG criteria bite at the payment step, and how to test a flow a crawler never reaches.

P

Pavel Charkasau

Checkout accessibility under the European Accessibility Act rests on one clause in the law and one rule in WCAG. The clause is Annex I Section IV(g) of Directive (EU) 2019/882, which has applied to e-commerce services since 28 June 2025 and requires that identification, security and payment functionality be perceivable, operable, understandable and robust. The rule is WCAG's conformance requirement for complete processes: a checkout is a series of pages ending in a contract, so either every page in it conforms or none of them can be claimed as conforming for that purchase (W3C). Those two together are why a clean scan of your product pages settles almost nothing. The working technical bar is WCAG 2.1 Level AA, through EN 301 549 v3.2.1, though the legal route to it is less tidy than most guides admit. What follows is what the law asks of a checkout, the failures that keep showing up in real carts and payment steps, and how to test a flow that starts behind a login.

Why does the EAA name payment specifically?

Because a service can pass a general accessibility review and still be impossible to buy from.

Annex I Section III sets the general requirements for every covered service. Section IV adds sector-specific duties, and point (g) is the e-commerce one. It has three parts (Directive (EU) 2019/882, Annex I, as reproduced by Accessible.org):

  • provide information about the accessibility of the products and services being sold, where the responsible economic operator provides it;
  • ensure the accessibility of the functionality for identification, security and payment when it is delivered as part of a service rather than a product, by making it perceivable, operable, understandable and robust;
  • provide identification methods, electronic signatures and payment services that are perceivable, operable, understandable and robust.

Read the second and third points as a pair. They cover the steps a general web audit tends to skip because they are somebody else's code: the 3-D Secure challenge, the one-time-code screen, the hosted card form. If a screen reader user can fill the cart, then hits a bank-hosted verification page they cannot operate, the service obligation is unmet. Your payment provider wrote that page, but the EAA puts the duty on the service you offer the consumer. Our EAA overview covers who counts as a service provider and which exemptions exist.

Which standard does a checkout have to meet?

In practice EN 301 549, and therefore WCAG 2.1 Level AA on the web. The legal mechanism behind that is worth getting right, because plenty of guidance states it wrongly.

Article 15 of the EAA grants a presumption of conformity only to standards whose references have been published in the Official Journal in support of that directive. EN 301 549 v3.2.1 is cited in the Official Journal, but under the Web Accessibility Directive, by Commission Implementing Decision (EU) 2018/2048 as amended by (EU) 2021/1339, which covers public sector bodies. No harmonised standard had been cited in support of the EAA itself as of 7 September 2026 (Legalithm).

So EAA conformity is assessed against Annex I directly today, and passing EN 301 549 is not yet a legal shortcut to it. That does not change what you build. The standard is still the only detailed technical expression of those requirements, and every auditor I have dealt with tests against it. Build to WCAG 2.1 AA, then read Section IV(g) as a separate list.

What does "complete process" mean for a checkout?

WCAG defines conformance for whole pages and whole processes. Requirement 5.2.3 says that when a page is one of a series presenting a process, all pages in that process must conform at the stated level or better (W3C). Requirement 5.2.2 rules out partial conformance for a page, so you cannot carve out the embedded payment widget and claim the rest.

Apply that to cart, address, shipping, payment, confirmation. If the payment step fails a single Level AA criterion, the cart page is not conforming at AA as part of that process either, however clean it tests alone. Conformance is not an average across your URLs.

This is the part I find people genuinely have not read. A team will show me an audit covering fifteen templates, all green, and the checkout is not among them because testing it needed a card.

Where do checkouts actually fail?

The honest state of the evidence first. WebAIM's February 2026 study found 33.1% of form inputs lacked a proper label, across pages averaging 6.9 inputs each (WebAIM). But WebAIM tested one million home pages, and says so plainly. A checkout carries far more inputs and no public dataset measures those, so treat that figure as a floor, not a checkout statistic.

The failures below are the ones I keep finding in real stores, each tied to the criterion it breaks.

Fields labelled only by a placeholder. The grey text vanishes the moment someone types, and a screen reader may announce nothing. <label for="card-name"> or an aria-label fixes it. Fails 3.3.2 Labels or Instructions (Level A).

Errors that appear on screen but are never announced. "Invalid entry" gets injected above the postcode field with no role="alert" and no live region. A sighted user sees the problem instantly; a screen reader user hears silence and a form that will not submit. That is 4.1.3 Status Messages (AA), usually alongside 3.3.1 Error Identification (A) (W3C).

Errors that name the problem but not the fix. "Invalid date" on an expiry field that wanted MM/YY and got MM/YYYY. 3.3.3 Error Suggestion (AA) asks for the correction when you know it.

No review before the charge. 3.3.4 Error Prevention (Legal, Financial, Data) is Level AA and applies squarely to purchases: submissions are reversible, or input is checked for errors, or a mechanism exists to review, confirm and correct before finalising (W3C). A one-tap "Pay now" on a page that never restates the order fails all three.

Focus dropped after a cart update. Remove an item, the list re-renders, focus lands on <body>. A keyboard user is back at the top of the document with no idea what happened, and the "2 items" counter update goes unannounced.

Card fields inside a third-party iframe. The labels, error text and tab order live in code you did not write. Check the iframe has a title, that the inputs inside carry accessible names, and that validation errors are announced. Under Section IV(g), that is still your service.

A checkout session that expires without warning. 2.2.1 Timing Adjustable (Level A) requires a way to turn off, adjust or extend a time limit, with narrow exceptions. Reserving stock for ten minutes is a business rule; ending the session silently is a failure.

Missing autocomplete attributes. 1.3.5 Identify Input Purpose (AA) wants the purpose of user-data fields programmatically determinable, which means autocomplete="cc-number", "postal-code", "email" and the rest of the defined token list. A few minutes of work, skipped constantly.

If I had one day of manual testing to spend on a store, I would spend all of it after "proceed to checkout". Not because the catalogue is fine, but because the catalogue is the part a scanner already covers and the payment step is the part it structurally cannot reach.

Does WCAG 2.2 change what a checkout has to do?

Not legally, not yet, and two of its criteria are aimed straight at checkout anyway.

EN 301 549 V4.1.1 was published in September 2026 and moves the web clauses to WCAG 2.2, adding clause 9.3.3.7 (3.3.7 Redundant Entry, Level A) and clause 9.3.3.8 (3.3.8 Accessible Authentication (Minimum), Level AA) (ETSI). It has no Official Journal citation either, so v3.2.1 and WCAG 2.1 AA remain the practical yardstick.

Test both anyway. Redundant Entry is what your billing address form breaks when it makes someone retype the shipping address they gave four steps earlier. Accessible Authentication is broken by onpaste="return false" on the card field or the one-time code input, which blocks password managers and anyone who cannot hold six digits in working memory. Even under WCAG 2.1, a puzzle CAPTCHA at the payment step is a problem under Section IV(g) directly, because security functionality has to be operable.

How do you test a checkout a crawler never reaches?

Scan what a crawler can see, then walk the rest by hand. There is no version of this where the second half is optional. Deque's analysis of more than 2,000 audits put automated detection at about 57% of issues by volume, and estimates based on how many WCAG success criteria a tool can evaluate at all land closer to 30% (Deque). A scanner is good at the machine-detectable failures listed above: missing labels, absent autocomplete tokens, contrast on the disabled "Pay" button.

The manual pass is short and specific. Put a real item in the cart, disconnect the mouse, and complete a purchase with a test card using only the keyboard. Then repeat with a screen reader running. Watch where focus goes after every DOM update, and whether each error is actually spoken. Most stores fail this in under ten minutes, which is the good news: the failures are cheap to fix once you have seen them.

Write down what you tested and when. That record is the backbone of an accessibility statement describing real efforts rather than a hope, and it is what a market surveillance authority asks for. Our WCAG checklist separates the checks a tool can make from the ones needing a person, and the e-commerce page covers scanning flows behind a login.

A scan result is not a conformance verdict, whoever sells it to you. Claiming otherwise is what led the US Federal Trade Commission to a $1 million order against the overlay vendor accessiBe over its WCAG claims (FTC). Automation finds issues. A person confirms the flow works.

Frequently asked questions

Does the EAA require my checkout to meet WCAG?

Not by name. The EAA states outcomes in Annex I, and no harmonised standard has yet been cited in the Official Journal in support of it, so conformity is assessed against Annex I directly. EN 301 549 is the technical benchmark everyone tests against in practice, and for the web its v3.2.1 edition incorporates WCAG 2.1 Level A and AA.

Am I responsible if my payment provider's page is inaccessible?

For the service you offer, yes. Annex I Section IV(g) requires identification, security and payment functionality to be perceivable, operable, understandable and robust when delivered as part of your service. Test the hosted card form, and raise defects with the provider.

Can a scan tell me whether my checkout is accessible?

No. A scan finds the machine-detectable failures, roughly 30–57% of issues depending on how you count. Whether focus order makes sense and whether a person can finish the purchase need manual testing with a keyboard and a screen reader.

Does one failing step really affect the rest of the checkout?

Yes, for the purpose of a conformance claim about that process. WCAG conformance requirement 5.2.3 requires every page in a process to conform at the stated level, so a payment page failing at AA means the cart page cannot be claimed as AA within that purchase flow.

Do I need to meet WCAG 2.2 in my checkout now?

No. EN 301 549 V4.1.1 moves the web clauses to WCAG 2.2, but it has no Official Journal citation yet, so v3.2.1 and WCAG 2.1 AA remain the practical benchmark. Redundant Entry and Accessible Authentication are still worth doing early, because both target failures that live in checkout and login.

Test the flow, not just the templates

Measure the pages a crawler can reach, then take the purchase flow through by hand. Run a free scan to clear the machine-detectable failures across your templates, then spend an afternoon in your own checkout with a keyboard and a screen reader. You will finish with a real defect list and a record you can put in your accessibility statement.

Pavel Charkasau, founder, wcagc.com. Last updated 7 September 2026.

Sources