The checkout process is for many webshops the most vulnerable part of the site when it comes to accessibility. While product pages often still work reasonably well with a screen reader, the process breaks down as soon as a customer needs to pay: buttons without clear labels, error messages that are not announced, or a payment widget from an external provider that cannot be used without a mouse. This is no accident. The checkout process contains the most dynamic elements of the entire site, and dynamic elements are precisely where screen readers and keyboard navigation run into trouble fastest.
This is not a minor detail. The payment step falls under the same EN 301 549 requirements as the rest of the site, and a user navigates through this step by definition at the moment they actually want to buy something. A screen reader that breaks down there excludes a customer at the decisive moment. That is also the reason why at axessia we include the checkout step as standard in the full scan, and not only in the free quick-scan of core pages.
Where it goes wrong in practice
The most common problems are remarkably recurring. A button for "next step" or "pay now" that contains only an icon without text that a screen reader can read out. An error message for an incorrectly filled postcode field that appears visually but is not announced because the correct technical link is missing. A progress indicator ("step 2 of 3") that is visually clear but remains invisible to a screen reader. And the payment provider itself: iDEAL or credit card widgets from third parties are often built in separately and have their own accessibility level, which a webshop has little control over but remains responsible for.
Also focus order is a recurring problem. After submitting a form with an error, the user's attention should go to the error message. If that does not happen, someone working with a keyboard or screen reader remains searching for what went wrong, without any clue.
Why an automated scan partially misses this
An automated scan is good at detecting missing labels, empty buttons and structural problems in source code. What a scan cannot assess well is behavior: whether an error message is actually announced out loud, whether focus jumps logically, and whether the checkout step remains accessible without a mouse after entering data. This requires someone who actually navigates the step with a screen reader. This is precisely the type of limitation that is explicitly stated in every axessia report: a scan tests some requirements, not all.
That is why the full scan focuses not only on the homepage but precisely on the steps that a customer actually goes through, including login and checkout. If you first want an indication without obligations, you can see in a few questions where your site currently stands.
What this means for the requirements you must meet
The underlying standard, EN 301 549, translates in practice to WCAG 2.1 level AA. It contains requirements about the name, role and status of interactive elements, about status messages that must be discernible without visual attention, and about information that is not conveyed only through color or position. For the exact wording and the location in the official text, EUR-Lex is the authoritative source; we translate those requirements into recognizable situations like the checkout process, but make no statements about your specific situation. More background on how that translation comes about, you can read on the page that explains where our information comes from.
How to test this yourself or have it tested
A first, practical step is to run through the checkout process yourself without a mouse: using only the Tab key and Enter. If you get stuck somewhere, there is a good chance a screen reader will also get stuck there. A second step is to test with a free screen reader such as NVDA, and specifically pay attention to what is read aloud as soon as an error occurs. For a complete picture, including the aspects that only emerge through manual review, more extensive testing is needed; axessia performs that testing and documents the findings in a prioritized action list, but does not carry out any remediation work itself. That remains the responsibility of your own developer or supplier, often based on precisely the points we identify. Other frequently asked topics around such concrete barriers can be found in the knowledge base with detailed topics per situation.
If you want to know what a full test of your checkout process and login environment costs, that is clearly outlined on the page with pricing and what it includes.
Would you like to get an impression yourself without any obligations? The free quick-scan from axessia gives you a first picture of your core pages within minutes, and the scope check shows whether the regulations apply to your organization.