Ecommerce accessibility: seven checks for a platform demo

What to take away

The Equality Act 2010 applies to online shops in Great Britain; Northern Ireland has separate disability discrimination protections, so ecommerce accessibility is a legal risk when disabled shoppers cannot complete a purchase.
Responsibility is splitthe platform owns the checkout core, while you own catalogue content and every app you switch on.
Test a demo store with a keyboard, a screen reader and 200 per cent zoom before you pay for a plan.
Ask for the VPAT (Accessibility Conformance Report) behind any accessibility claim, with the date it was produced.

Where the duty comes from

In Great Britain, the Equality Act 2010 makes it unlawful for a service provider to discriminate against disabled people, and an online shop counts as a service. In Northern Ireland, separate protections apply under the Disability Discrimination Act 1995, as amended. The Equality and Human Rights Commission (EHRC) enforces the Equality Act in Great Britain and can act against service providers. The duty under that Act is to make reasonable adjustments, not to reach a technical score.

WCAG 2.2 is the benchmark usually cited in complaints, even though the Act names no standard. The usual target is WCAG 2.2 Level AA; Level AAA is not a practical target for a whole store. It added criteria on focus appearance, dragging movements and consistent help.

Public sector bodies face separate rules under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018. Private retailers sit outside that regime, and platform pages sometimes blur the two.

Advice about the US Americans with Disabilities Act does not bind UK shops. The domestic duty rests on the Equality Act, which is why searches for an ecommerce platform ADA UK answer often miss the point.

Before an order is placed, the Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 require key information in a clear and comprehensible way. A checkout that a screen reader cannot follow puts that duty under strain.

Keep accessibility in the same review as data protection and pricing, because the same checkout journey carries all three duties.

BSI, the UK's national standards body, adopts BS ISO/IEC 30071-1, a code of practice for creating accessible ICT products and services; it appears in tenders and procurement questionnaires. Ask which named standard a vendor works to.

How to test a platform before you buy

Run these seven checks on a trial store in the theme you intend to buy. If you are weighing more than one platform, use the same products and purchase journey in each demo where possible, and note any conditions you cannot hold constant.

Use automated tools such as WAVE, axe, Lighthouse, Pa11y or Accessibility Insights for the first pass; they catch only a minority of barriers, so keep the manual checks below.

Pre-purchase accessibility checks

Tab through demo without mouse
Screen reader test order
Zoom 200% and 320px reflow
Contrast on prices and errors
Pause checkout session timers
Request accessibility statement and audit
Repeat on default and chosen theme

Open the vendor's demo and leave the mouse alone. Tab through search, product, basket and checkout, noting where focus disappears.
Switch on a screen readerVoiceOver on macOS or NVDA on Windows. Complete a test order, listening for unlabelled buttons.
Zoom to 200 per cent and narrow the window to 320 pixels. The checkout should reflow without sideways scrolling.
Check contrast on price text, error messages and disabled buttons against WCAG 2.2 AA: 4.5:1 for normal text and 3:1 for large text.
Ask whether checkout session timers can be paused for slower typists.
Request the accessibility statement, the VPAT (Accessibility Conformance Report) behind it, and a named contact.
Repeat the journey on the default theme and your chosen theme, because they rarely match.

What the platform controls, and what you control

On hosted platforms such as Shopify, BigCommerce, Wix and Squarespace, the vendor runs the checkout core. On self-hosted WooCommerce and Adobe Commerce, the checkout ships with the software and your theme, extensions and developer can change it, so the result of the seven checks depends more on your own build. Ask each vendor for its accessibility page and the audit document behind it; the rest of the store comes from its theme, your content and third party apps.

When more than one platform is on the shortlist, repeat the same seven checks on each demo. Record the result, supporting evidence and date for each demo, and distinguish checkout findings from theme, content and app findings; a result in one layer does not establish accessibility in another.

Who controls each layer

Layer

Default theme: Platform
Checkout fields: Platform or payment provider
Product descriptions: Merchant
Reviews and chat apps: App vendor
Cookie banner: Merchant
Accessibility statement: Merchant

Controlled by

Default theme: Tab order through checkout
Checkout fields: Screen reader labels on card fields
Product descriptions: Shopping with images off
Reviews and chat apps: Keyboard focus while widget loads
Cookie banner: Accept and reject keyboard reachable
Accessibility statement: Names standard, date and contact

Check that exposes gap

Default theme
Checkout fields
Product descriptions
Reviews and chat apps
Cookie banner
Accessibility statement

Layer	Usually controlled by	Check that exposes the gap
Default theme and templates	Platform	Tab order through the whole checkout
Checkout fields and payment steps	Platform or payment provider	Screen reader labels on card fields
Product descriptions and images	Merchant	Shopping with images turned off
Reviews, chat and pop-up apps	App vendor, picked by the merchant	Keyboard focus while the widget loads
Cookie banner	Merchant, using a platform tool	Accept and reject both reachable by keyboard
Accessibility statement	Merchant	Names a standard, a date and a contact

Third party apps are the weakest link in most reviews. A reviews widget can trap keyboard focus in checkout and block payment.

What to record before you sign

Put the position in writing before you sign. For each platform, record which themes carry a current audit, which checkout steps sit outside the vendor's control, and how quickly a reported defect gets fixed.

Record the answers against a named owner and a date, so a later dispute has evidence behind it.

An accessibility failure belongs among the platform risks worth exercising before launch, with an owner and a stop condition attached.

If a shopper reports a failed checkout

Log the report where you record order errors, with the browser, the assistive technology and the step that failed.

The Competition and Markets Authority enforces consumer protection law in the UK, and its guidance for online sellers sets out the information shoppers must see before they buy. Accessibility failures often appear as missing or unreadable information rather than a broken button.

Fix the flow, then re-test with the same setup. A screenshot is not proof that a screen reader user can now pay.

Common questions

These answers cover the UK duty and the practical evidence a demo test should leave you with.

Does the Equality Act 2010 apply to an online shop?

Yes. A shop is a service, and the duty to make reasonable adjustments covers how disabled customers browse, pay and contact you.

Is WCAG 2.2 a legal requirement for UK retailers?

Not directly. It is the standard usually cited when a complaint is prepared, and public sector sites carry separate duties under the 2018 accessibility regulations.

Can a platform's accessibility badge be trusted?

No. A badge may cover only a default theme at one point in time. Test your own journey on the theme and apps you plan to use.

Who fixes problems after launch?

It depends on the layer. The vendor owns checkout fields and templates, while you own content, images and the apps you add.