Ecommerce accessibility and WCAG 2.2: building an inclusive checkout

Why ecommerce accessibility needs an operating plan now

An accessible checkout is not a cosmetic enhancement. It is a journey that must let people understand products, enter details, recover from errors and complete an order when they use a keyboard, assistive technology or magnification. The European Accessibility Act includes ecommerce services within its scope and covers qualifying consumer services provided after 28 June 2025. For ecommerce, the Directive requires providers to supply available information about the accessibility of products and services being sold, and to make identification, security and payment functionality and services accessible. Separate information and procedural obligations apply to the service provider.

Actual scope depends on the business, the market served and national implementation. The framework includes an exemption for microenterprises providing services, as well as assessments concerning fundamental alteration and disproportionate burden. Member States determine effective, proportionate and dissuasive penalties, so there is no single EU-wide fine to quote. Obtain qualified advice before reaching a legal conclusion for a specific operation. From a delivery perspective, accessibility should nevertheless become a durable quality requirement rather than a last-minute compliance exercise.

Prerequisites: map the journey, not just a list of pages

Inventory screens, states and dependencies

Start with the full customer path: search, collections, product detail, variant selection, cart, sign-in, guest checkout, address, delivery, payment and confirmation. For every step, record modals, menus, dynamic messages, validation, payment integrations and third-party components. Guest checkout removes an avoidable barrier, while a clear progress indicator explains what remains. Include loading, error, out-of-stock and price-change states; these are often where otherwise usable interfaces break down.

Assign ownership and prepare realistic tests

Name product, engineering and content owners. Turn expectations into testable acceptance criteria before development, then prepare realistic data: long names, international addresses, empty fields, declined payments and unavailable variants. WCAG 2.2 is a W3C Recommendation, extends WCAG 2.1, and conforming to 2.2 also satisfies 2.0 and 2.1. It remains a technical standard, however. WCAG conformance does not by itself establish EAA compliance.

Auditing against WCAG 2.2 takes tools and people

What automation can catch

Automated checks can flag missing alternative text, absent field-label relationships, structural issues, missing accessible names and some colour-contrast failures. They are valuable during development and in release pipelines because they detect repeatable regressions. They cannot judge whether alternative text helps someone choose a product, whether focus follows a sensible sequence, or whether an error message provides a workable recovery route.

What a person must test

Complete the purchase with a keyboard only, then with high zoom and at least one representative screen-reader and browser combination. Make sure focus is visible, is not hidden by sticky banners or dialogs, and follows the DOM order. Review the criteria added or expanded in WCAG 2.2, including focus not obscured, alternatives to dragging, minimum target size, consistent help, redundant entry and accessible authentication. Each finding should record the step, expected result, observed result, severity and reproducible evidence.

Build forms and checkout interactions that support recovery

Labels, autocomplete and useful errors

Every field needs a persistent, understandable label; placeholder text is not a replacement. Prefer native HTML controls, stable autocomplete tokens and appropriate input types. Ask only for necessary data, accept international formats and identify required fields clearly. When validation fails, associate the message with the field, explain how to fix it and move focus predictably without deleting completed entries. Important updates may use an aria-live region, but its actual behaviour must be tested with assistive technology.

Keyboard, focus and dynamic components

Menus, variant selectors, coupon controls, expandable summaries and payment dialogs must work without a mouse. Preserve semantic HTML, a logical DOM sequence and a strong visible focus indicator. Do not move focus without a clear reason. When a dialog opens, manage focus within it and return focus to the triggering control when it closes. If an action relies on dragging, provide buttons or another straightforward alternative. Test autofill on real devices and browsers: renaming or replacing fields during the journey can disrupt autofill or prevent fields from being populated with saved data again.

Product discovery and theme quality come before payment

Customers cannot reach checkout if catalogue navigation is confusing. Set the document language, provide a skip link, use a meaningful heading hierarchy and expose semantic regions. Menus and dynamic components need names and states that do not rely on colour alone. Product images need alternative text that supports a buying decision rather than decorative prose or keyword stuffing.

Original and sale prices must remain understandable when visual styling is unavailable. If choosing a variant changes price or stock status, announce the update appropriately without overwhelming the user. Recheck the theme after updates and app installations. A third-party widget can introduce a focus trap, unnamed controls or a broken reading order even when the underlying theme was sound.

Release in risk order and protect working commerce logic

Prioritise findings by user impact, frequency and journey criticality. A payment blocker comes before an editorial imperfection. Group fixes by component, assign an owner and target date, and add regression coverage. Before release, compare staging with production, including configuration, apps and external providers. Avoid unnecessary large rewrites: small, verifiable changes reduce the chance of damaging tax, delivery or analytics behaviour.

1. Immediate: keyboard blockers, unnamed fields, imperceptible errors and inaccessible authentication.
2. High: obscured focus, hard-to-activate targets, repeated information requests and silent state changes.
3. Continuous: better alternative text, clearer instructions, editorial consistency and fewer fields.

To turn findings into an engineering backlog, design-system rules and release tests, explore our ecommerce design and development services.

Avoid governance shortcuts

The first mistake is treating an automated score as the outcome. The second is publishing an absolute claim without evidence or a defined scope. The third is fixing the theme while ignoring apps, payment gateways and content entered by the team. Keep a record of findings, decisions, exception assessments, tested versions and accountable owners. If a legal exception is being considered, it requires appropriate expertise and documentation; it is not a technical shortcut.

Place accessibility in design reviews, pull requests, editorial onboarding and supplier selection. Ask vendors how they handle keyboard input, focus, errors and dynamic updates. Offer an accessible feedback route and define who responds. Conformance is not a permanent state: catalogue content, themes and integrations change, so evidence and tests need maintenance.

Measure progress with operational KPIs

Track coverage of critical journeys, open issues by severity, median remediation time, regressions per release and the share of components with accessibility acceptance criteria. In the purchase path, monitor field errors, step abandonment and support requests with careful segmentation and privacy safeguards. These measures do not prove accessibility on their own; they help teams prioritise work and see whether fixes remain effective.

Create a baseline before changes and annotate each release. Repeat the same scenarios afterwards, but do not attribute every conversion movement to accessibility. Useful comparison requires similar periods, traffic and configuration. The goal is a more controlled system: fewer known blockers, stronger evidence and clear ownership.

Move from a one-off audit to inclusive ecommerce delivery

A credible programme combines a verified legal scope, WCAG 2.2 as a technical reference, clear content, semantic engineering and human checkout testing. Start with barriers that prevent purchasing, then extend coverage to catalogue, account and support. If you need a realistic roadmap for your store, contact AE Digital Agency. We will assess the stack, dependencies and priorities without presenting a technical audit as a legal guarantee.