An accessibility statement for a Shopify store, written from a real test.

Four layers, four different owners

Before any finding makes sense, it helps to see the store as the customer's browser sees it: not one product but four, assembled at load time, each maintained by somebody different.

The findings name the layer, because the fix is a different conversation in each case: a ticket for your developer, a setting change, an app removed, or a documented limitation.

What goes in the statement when part of the stack is not yours

This is the part merchants find hardest to write, and it is straightforward once the principle is clear: describe the limitation, name the alternative, give a date if you have one. A sentence stating that the payment step is provided by the platform, that a specific behaviour there is not fully accessible, and that orders can be completed by phone or email meanwhile is honest, useful to the customer, and exactly what Annex V asks for.

What must not happen is silence. A statement claiming full conformance while the checkout has a known problem is a claim contradicted by two minutes of testing, and the annotated example shows how the honest version reads instead.

What we deliver to a Shopify merchant

An audit of your actual store, run as a customer with a real basket and a real card. A findings report naming the layer responsible for each item, with severity and remedy. The accessibility statement written from those findings, signed by Europe Services SE for the European Union, with a public code anyone can verify. A hosted feedback channel so the route the law requires actually reaches you. Monthly re-testing for the year and five years of records.

No app is installed on your store, no script is added to your theme, and nothing about the way your shop works changes because you bought the audit. What changes is that you know, in writing, what your customers meet, and you have a document that describes it truthfully.

Choosing a theme with accessibility in mind

Most merchants meet accessibility after the theme is already bought, which is the expensive order. If you are about to choose or rebuild, twenty minutes of testing in the demo store will tell you more than any marketing claim on the listing page. Open the demo, put the mouse aside and try four things: move through the header menu with the keyboard and see whether submenus open and close predictably; open the product gallery and try to reach the second image; add an item to the cart and watch whether anything announces that it worked; open the search and see whether the suggestions are reachable.

A theme that survives those four is not guaranteed compliant, but it is built by people who thought about it, and that difference is worth more than any badge in the listing. A theme that fails all four will cost you a developer's week later, every time it is updated.

The same logic applies to the apps you install on day one. Each one that manages its own overlay — pop-ups, quick view, cart drawers, cookie consent — is a candidate for a focus problem, and it is far easier to reject it now than to unpick it from a live store during a remediation sprint.

Documents and media you uploaded yourself

Every store accumulates them: a sizing chart saved as a picture, a care leaflet as an untagged file, a campaign video with burned-in text and no captions, an ingredients table screenshotted from a supplier email. They are invisible in any automated report because a machine sees an image and moves on, and they are among the easiest findings to fix once someone points at them. A size chart retyped as an HTML table takes fifteen minutes and removes a barrier that stops a purchase outright for anyone who cannot see the picture. We list these separately in the findings, because they are usually the fastest wins available and they do not require a developer at all.

The migration moment

Replatforming is the cheapest time to get this right and the moment it is most often forgotten. During a migration somebody is already touching every template, the content is being reviewed, and the forms are being rebuilt: adding proper labels, a visible focus style and a sane heading order costs almost nothing while that work is happening, and costs a separate project afterwards. If a migration is on your roadmap this year, run the audit on the old store first. The findings become the specification for the new one, and you launch with a statement that is true on day one instead of a promise to look at it later.

Working with your agency

Most stores are maintained by an agency or a freelancer, and the findings report is written so it can be handed over without translation. Each item names the page, the component, what a user cannot do, the change to make and a severity. That format matters commercially: a developer quoting from a list of concrete changes gives you a price, while a developer quoting from a machine-generated score gives you a project.

It also protects you in the other direction. When the agency says something is impossible on your plan, the finding is precise enough to check, and the statement can record the limitation honestly instead of pretending it does not exist. Either way you end up with a document that matches the store, which is the only version worth publishing.