Accessible checkout & forms: the how-to guide for e-commerce
In short — the till is where accessibility pays off
Filling in a shipping address, entering a card, creating an account, typing a one-time code: these forms are where an online sale is won or lost. When they are badly built — a label that vanishes, an error only shown as a red border, a password you can't paste — a disabled customer simply can't complete the purchase, and the basket is abandoned. The European Accessibility Act (EN 301 549 / WCAG 2.1 AA), in force for e-commerce since 28 June 2025, requires in particular:
- A clear, persistent label on every field — not just placeholder text that disappears (3.3.2, level A);
- The purpose of each field declared so browsers and password managers can autofill it (1.3.5, level AA);
- Input errors identified, tied to the field and announced to screen readers (3.3.1, level A · 4.1.3, level AA);
- A review-and-correct step before a legal or financial order is confirmed (3.3.4, level AA).
One boundary worth knowing: accessible authentication — being able to paste your password or code, no cognitive puzzle — is criteria 3.3.8 and 3.3.7 of WCAG 2.2. The EAA currently aligns on WCAG 2.1 via EN 301 549, so these two are strongly recommended but not yet formally required. Applying them is still one of the most profitable fixes — it's usually where abandons cluster.
A store is judged at its till. If the queue is confusing, the form asks the impossible, or a field silently rejects you, some customers give up with a full basket. Online, that till is your checkout and account forms: shipping, payment, sign-in, one-time codes. It's one of the places where accessibility barriers do the most damage, because they are blocking: no valid form, no order. Here are the WCAG rules to apply so everyone can get through, what the EAA precisely requires, and where the line sits with the newer WCAG 2.2 good practices.
Why the checkout excludes so often
A checkout concentrates almost every accessibility trap at once: many fields, constraints (card format, postcode), error messages, sometimes an anti-robot test and a one-time code. For someone using a screen reader, a field with no announced label is just an anonymous "edit box". For someone with a motor disability, a password or address you can't paste means slow, error-prone typing. For someone with a cognitive impairment, a hard time limit or a CAPTCHA of distorted letters is an impassable wall. And because the form is the last step before payment, every one of these barriers turns straight into an abandoned basket.
The EAA relies on EN 301 549, built on WCAG 2.1 level AA. For forms, the key criteria are level-A and AA foundations: 3.3.2 (Labels or Instructions), 1.3.1 (Info and Relationships), 1.3.5 (Identify Input Purpose), 3.3.1 (Error Identification), 3.3.3 (Error Suggestion), 3.3.4 (Error Prevention), 4.1.3 (Status Messages), 2.1.1 (Keyboard) and 2.2.1 (Timing Adjustable). WCAG 2.2 added two checkout-friendly criteria in 2023 — 3.3.7 and 3.3.8 — which are not yet part of the EAA baseline, but which we cover here because they settle the most frequent abandons.
The 6 rules for an accessible checkout & forms
Placeholder text is not a label
Every field — email, address, card number, postcode — must have a label associated in code (<label for> or aria-label) that stays visible while typing. The placeholder (grey text inside the field) is not enough: it disappears as soon as you type, isn't reliably announced by screen readers, and its contrast is often too low. Put useful instructions (accepted card types, expected format) before the field and tie them to it with aria-describedby.
<label for="postcode">Postcode</label> above the field; the accepted format shown and linked via aria-describedby.→ See also the full EAA compliance checklist.
Autofill and password managers are assistive technology
On fields that collect user information, add the autocomplete attribute with the right value: email, name, street-address, postal-code, cc-number for payment, current-password for sign-in, one-time-code for a code. This is criterion 1.3.5: it lets browsers, password managers and assistive tech recognise and pre-fill fields — a real gain for people with motor or cognitive disabilities, and fewer typos for everyone. Never disable pasting "for security": it forces painful manual entry and breaks password managers.
<input autocomplete="postal-code"> on the postcode, autocomplete="cc-number" on the card field; pasting stays allowed everywhere.→ See also does the EAA apply to my online store?
Say what's wrong, where, and announce it
When a field is invalid or payment fails, the message must be in text (not just a red border), tied to the right field, and suggest a correction where possible (3.3.1, 3.3.3): "The postcode must be 5 digits." Crucially, since the message appears after submission without a full page reload, it must be announced dynamically to screen readers via a live region (role="alert" or aria-live) — otherwise a blind user never learns their order failed (4.1.3). Move focus to the first field in error so keyboard users land on it.
role="alert" "Your card was declined — check the number and expiry" announced immediately; focus returned to the card field.No irreversible order without a check step
For any order that involves a payment or a legal commitment, the user must be able to review, correct or cancel their details before final confirmation (criterion 3.3.4): an order summary, an explicit "Confirm and pay" step, or the ability to go back a step without losing what was entered. This protects everyone from a costly slip, and is especially decisive for people with cognitive disabilities. Don't demand information already given earlier in the same process (WCAG 2.2's 3.3.7, Redundant Entry) — re-typing the same address between steps excludes more than it protects.
Give people time — carts, sessions and one-time codes
A cart that empties, a session that ends, or a payment step that times out is criterion 2.2.1 (Timing Adjustable): a hard limit must be able to be turned off, adjusted or extended, unless it's essential. For a one-time code, let the user paste it and add autocomplete="one-time-code" so the system offers it automatically; leave a comfortable window and a "Resend code" button. Splitting a code across boxes is fine only if it stays pasteable in one go and usable with the keyboard.
autocomplete="one-time-code" and a "Resend" button.Tab without traps, see the focus, no impossible widgets
The whole form must be reachable and usable with the keyboard alone, in a logical order, with no focus trap and a visible focus (2.1.1, 2.1.2, 2.4.7). Custom widgets are the usual culprits: a date picker that won't open with the keyboard, a "country" dropdown you can't operate, a card-entry iframe that swallows focus. Each must expose a real, labelled control. And keep an accessible authentication: allow pasting the password or code, avoid a cognitive puzzle (WCAG 2.2's 3.3.8) — recommended rather than strictly required today, but one of the cheapest, highest-return fixes.
Required vs recommended: what the EAA asks today
| Point to check | Level | EAA status |
|---|---|---|
| Persistent label & instructions — 3.3.2 / 1.3.1 | A | Required |
| Field purpose (autocomplete) — 1.3.5 | AA | Required |
| Errors identified, suggested & announced — 3.3.1 / 3.3.3 / 4.1.3 | A · AA | Required |
| Review & correct before an order — 3.3.4 | AA | Required |
| No un-extendable time limit — 2.2.1 | A | Required |
| Keyboard-usable, focus visible — 2.1.1 / 2.4.7 | A · AA | Required |
| Accessible authentication — paste the code, no puzzle (3.3.8) | AA (2.2) | Recommended |
| No redundant entry — don't make people re-type (3.3.7) | A (2.2) | Recommended |
How to check your own checkout
A few concrete tests to run on the cart, shipping, payment, sign-in and one-time-code steps:
- Click each label: does focus land in the matching field? (proof of a correct association)
- Try autofill and your password manager: are the address and card fields recognised? Does pasting work?
- Force an error (wrong card, empty postcode) and listen with a screen reader: is the message announced and tied to the field?
- Do the whole checkout with the keyboard: can you reach and operate every control, with focus always visible, up to "Pay"?
- Look for the review step: can you check and correct the order before it's charged?
Some of this is detectable automatically: a scanner flags a field with no label, a missing autocomplete, insufficient contrast, a structure problem. Whether an error is announced out loud, whether pasting is blocked, or whether a review step exists needs a real keyboard-and-screen-reader run. Our report flags the detectable breaches on the page analysed and lists the points to verify by hand.
Run the automated scan of your store
DeclareAccess scans one page of your site against WCAG 2.1 AA, sends you a quantified report of the non-conformities (form labels, autocomplete, contrast, structure…), then generates the ready-to-publish accessibility statement in the applicable template — English, French (RGAA), Italian, Spanish or German (BFSG). Free audit, no credit card.
WCAG report by email within 1 business day.
Got it. Your audit request is recorded — you'll receive your WCAG report by email within 1 business day.
Frequently asked questions
Can a placeholder replace a field's label?
No. Placeholder text disappears as soon as you type, its contrast is often too low, and it isn't reliably announced by screen readers. Criterion 3.3.2 requires a real label, associated with the field in code and visible at all times. A placeholder can show an example format, alongside the label, never in its place.
Should I really allow pasting into the card and password fields?
Yes. Blocking paste "for security" is a false friend: it stops password managers from working, so discourages strong passwords, and heavily penalises people with motor disabilities. Being able to paste a password or code is part of WCAG 2.2's accessible authentication (3.3.8): recommended rather than strictly required by the EAA today, but one of the simplest, highest-return fixes.
Is a review-before-confirm step really mandatory?
For orders involving a payment or a legal commitment, yes — that's WCAG 3.3.4 (Error Prevention, level AA), part of the EAA baseline. Users must be able to review, correct or cancel their details before final confirmation. A summary page with per-line "Edit" links and an explicit "Confirm and pay" button satisfies it, and reduces costly mistakes for everyone.
Does an automated scan check a checkout form?
In part. A tool detects a field with no label, a missing autocomplete attribute, insufficient contrast or a structure problem. But whether an error message is announced out loud, whether pasting is blocked, or whether a review step exists needs a real keyboard-and-screen-reader run. Our report combines the automatically detectable breaches with the list of points to check manually.
Is accessible authentication (WCAG 2.2) required by the EAA?
Not yet formally. The EAA relies on EN 301 549, currently aligned on WCAG 2.1. Criteria 3.3.8 (Accessible Authentication) and 3.3.7 (Redundant Entry) arrived with WCAG 2.2 in 2023 and aren't part of the current baseline. They are strong recommendations, though: standards are moving towards 2.2, and these criteria settle the most blocking checkout obstacles. Applying them now is a safe investment.