A customer has found a product, selected the right variant, and is ready to buy. From the store's perspective, it may seem that the hardest part is already done.
However, the shopping cart and checkout are exactly where an accessibility barrier can prevent some users from completing their purchase.
An inaccessible form, invisible keyboard focus, problems selecting a pickup point, unclear error messages, or an inaccessible payment gateway can stop a customer just before payment.
This is why checkout accessibility should not be evaluated screen by screen. It is better to go through the entire journey exactly as a customer would.
What does an accessible checkout process mean?
An accessible checkout should allow users to independently move from the shopping cart to order confirmation.
In practice, users should be able to:
- review the products in their cart,
- change product quantities or remove products,
- enter their personal and address details,
- select a delivery method,
- select a payment method,
- understand and correct form errors,
- review the price and order summary,
- place the order,
- receive clear confirmation that the process was completed successfully.
The challenge is that a checkout process often consists of several independent components. The store theme may come from one provider, the form from another, the pickup point selector from a delivery company, and the payment process from a payment provider.
Each of these components may work correctly on its own while the overall process remains inaccessible.
Start with a real checkout scenario
Instead of testing the cart, form, and payment process separately, prepare one specific test order.
A sample scenario could look like this:
- Find a product with several variants.
- Select a variant and add the product to the cart.
- Change the quantity.
- Proceed to checkout.
- Enter the customer's details.
- Intentionally enter an invalid postal code.
- Select a delivery method.
- Select a pickup point if the store provides this option.
- Correct the previously entered error.
- Select a payment method.
- Review the order summary and place the order.
Ideally, this test should be performed in a test environment so that it does not trigger real payments, shipments, or warehouse processes.
The same scenario can then be repeated after major changes to the store. It is much more useful than a general instruction to “test checkout accessibility” because it clearly defines the expected result.
Try buying a product without using a mouse
One of the most useful basic tests is completing the entire checkout process using only a keyboard.
Do not use a mouse or touchpad. Instead, use keys such as Tab, Shift + Tab, Enter, Space, and the arrow keys.
During the test, check:
- whether it is always clear which element currently has focus,
- whether the focus order is logical,
- whether product quantities can be changed,
- whether checkboxes and delivery options can be selected,
- whether dropdowns and modal windows can be opened and closed,
- whether a pickup point can be selected,
- whether all buttons can be activated without a mouse,
- whether keyboard focus becomes trapped anywhere in the process.
More complex interface elements require particular attention, including pickup point maps, custom select fields, calendars, sliders, popups, and third-party widgets.
If a user can open a delivery selection window using the keyboard but cannot close it or move to the next element, the checkout process is effectively blocked.
Don't just report “keyboard navigation doesn't work”
When you identify an accessibility problem, the way you describe it matters to the person who will need to fix it.
A report such as:
Delivery selection doesn't work with the keyboard.
is not very precise.
A much more useful description would be:
After opening the pickup point selection window, focus moves to the first element on the map, but pressing Tab does not allow the user to reach the close button or return to the checkout form.
A developer can then reproduce the exact scenario and verify whether the implemented fix actually solves the problem.
The checkout form is one of the most important parts of the entire process.
Each field should have a clear label, and required information should be clearly identified. A placeholder inside a field is not always an adequate replacement for a label.
The way the form behaves when an error occurs is particularly important.
A message such as:
Invalid data.
does not give the user much useful information.
A better message would be:
Check the postal code. Enter it in the 00-000 format.
Of course, this format should only be required where it actually applies to the selected country.
W3C guidance highlights the importance of identifying errors and providing users with information that helps them correct those errors.
Source: W3C – User Notifications
What happens after an error?
The error message itself is only part of the experience.
Intentionally make a mistake near the end of the checkout form and see what happens when you try to place the order.
Does the user know which field contains the error? Is focus moved to an appropriate location? Do previously entered details remain in the form? Does the user need to select the delivery or payment method again?
If a small error in one field forces the customer to complete the entire checkout again, they are being asked to do unnecessary work.
In some cases, they may simply abandon the purchase.
Check dynamic changes to prices, delivery, and payment options
A checkout is rarely a static form.
Selecting a country may change the available delivery methods. Choosing a courier may change the price. A particular delivery option may affect which payment methods are available. Applying a discount code may change the total order value.
Whenever something changes, check whether the user is made aware of that change.
This is particularly important for people using screen readers. A change in the DOM does not automatically mean that the information will be announced at the right time or in a meaningful way.
Screen reader testing should be carried out by someone who knows how to use the software correctly and can evaluate not only whether information is available, but also its timing, order, and context.
Don't forget about third-party modules
A common problem in ecommerce is assuming that accessibility issues in third-party modules are solely the responsibility of their providers.
From a technical perspective, your ability to modify such components may indeed be limited. From the customer's perspective, however, that distinction makes little difference.
If they cannot select a pickup point or complete a payment, they cannot complete their purchase.
Accessibility testing should therefore also include:
- delivery provider widgets,
- pickup point maps,
- external payment systems,
- instalment payment systems,
- third-party authentication mechanisms,
- CAPTCHA and other security mechanisms.
If the issue is located in a third-party solution, prepare a clear report for the provider with reproduction steps, a description of the problem, and the expected behaviour.
If the issue cannot be fixed, consider providing an alternative way to complete the task or using a different technical solution.
Automated audits can help, but they can't complete the purchase for the user
Automated tools are a useful first step when testing checkout accessibility. They can identify issues related to forms, contrast, HTML structure, and some uses of ARIA.
You can use online tools such as DockAccess, as well as tools that work directly in the browser. Our free Chrome and Firefox extension allows developers and testers to check accessibility while working with a website and analyse selected interface elements.
However, automated testing cannot replace going through the entire checkout process.
A scanner may not detect that a user does not know what to do after selecting a delivery method, that the focus order is confusing, or that a third-party window prevents them from returning to the checkout.
This is why the best results come from combining automated testing with manual testing of real user journeys.
Don't stop testing after clicking “Place order”
Placing the order is not necessarily the end of the process.
Check what happens next.
The user should clearly understand whether the order has been accepted, whether the payment was successful, and what happens next.
It is worth checking the confirmation page, the message displayed after payment, and the email sent after the purchase.
Pay particular attention to less common situations such as a rejected payment, interrupted connection, returning from a payment gateway, or retrying a payment.
An accessible process should also help users understand what happened when something did not go according to plan.
How can you start testing checkout accessibility?
You do not need to start by rebuilding the entire store.
Choose one popular product and complete the full journey from adding it to the cart to receiving the order confirmation. Then repeat the process without using a mouse and intentionally make a few mistakes in the checkout form.
Record not only technical errors, but also every point where it is unclear what the user should do next.
This provides a useful starting point for a more comprehensive accessibility audit.
At Dock, we help analyse the accessibility of complete ecommerce journeys by combining automated testing with manual accessibility audits. We can also help implement improvements in the store, its components, and integrations, and retest the process after the changes have been deployed.
