A shopper finds the right product, selects a size, and heads to checkout. Then a keyboard-only user cannot open the size selector—or a screen reader user hears three identical “Add” buttons with no way to tell which product each belongs to. The store may look polished, but the purchase journey is broken.
You do not need to be an accessibility specialist to find problems like these. This ecommerce accessibility checklist walks you through a practical keyboard and screen reader test, from product discovery to order confirmation. It will help you spot barriers, prioritize fixes, and give your developer or platform provider clear examples to work from.
Before you start: choose a real shopping journey
Testing an isolated homepage will miss many of the barriers that matter most to your customers. Pick a representative journey: find a product through navigation or search, choose a variant, add it to the cart, apply a discount code if you offer one, and proceed through checkout.
Use a product with the features your shoppers actually encounter, such as size options, image galleries, reviews, subscription choices, or personalization fields. If you sell different types of products, repeat the test with a few representative examples.
Prepare a safe way to test checkout without placing an unintended order. Depending on your setup, that might be a staging store, a payment provider’s test mode, or a controlled test order. Be careful not to enter real customer information into a test environment.
Set up your testing tools
- Keyboard: Put your mouse aside. Use Tab to move forward, Shift + Tab to move backward, Enter to activate links and many buttons, Space to activate buttons or checkboxes, arrow keys where appropriate, and Escape to close certain menus or dialogs.
- Screen reader: On Windows, NVDA is a widely used free option. On macOS, you can use the built-in VoiceOver. Start with the screen reader’s introductory help to learn how it moves through headings, links, form controls, and ordinary text; its commands are not the same as Tab navigation.
- Browser: Test in a browser that works well with your chosen screen reader. Record the browser, device, and screen reader you used so someone else can reproduce an issue.
First test with the keyboard and your screen reader separately. Then use them together. A control can be reachable by keyboard yet have an unclear screen reader label—or sound clear when read but still be impossible to operate.
Keyboard accessibility checklist for your online store
1. Can you see where keyboard focus is?
Load a page and press Tab. A visible outline, highlight, or other clear indicator should show which element will respond when you press Enter or Space. Move through the header, product content, and footer. If focus disappears, note exactly where it happens.
Focus should also follow a sensible order. For example, a shopper should not jump from a product option to the footer and then back to the Add to Cart button. A visible focus indicator is especially important on image-based buttons, dark backgrounds, and pop-up overlays.
2. Can you use navigation, search, and filters?
Open the main menu without a mouse. Can you reach its subcategories, tell which section is open, and close it? Try the search field, submit a query, and move through the results. On a collection page, use sorting and filters, including any price sliders or expandable filter groups.
Watch for controls that work only on hover. If a shopper must point a mouse at a category to reveal its submenu, keyboard users may never discover it. Also check that opening a filter panel moves focus into it appropriately and that closing it returns focus somewhere useful, such as the button that opened it.
3. Can you choose a product and add it to the cart?
On a product page, move through the gallery, variant selectors, quantity controls, and purchase options. Choose a size or color using the keyboard. If a selection changes the price or availability, check that the updated information is easy to find.
Try submitting without a required option. The resulting message should tell you what needs attention, and you should be able to reach the relevant control without searching the entire page. After adding an item, confirm that you can tell what happened and reach the cart. An update that appears visually but is never announced to a screen reader user needs attention.
4. Can you finish checkout without getting trapped?
Work through contact details, shipping, discount codes, and payment. Check every field, checkbox, and button. If a modal opens—for example, a shipping selector—focus should not slip behind it or become trapped after it closes.
Pay particular attention to third-party payment widgets. Even if another provider supplies the component, it is still part of your customer’s buying journey. If you find a problem you cannot change in your store editor, document it and raise it with the provider.
Screen reader accessibility checklist
A screen reader test is not simply listening to the page from top to bottom. Shoppers often navigate by headings, links, buttons, and form fields to locate what they need quickly. Try that approach on each page, then read the surrounding content where a label or instruction needs context.
Check page structure and product information
- Headings: Do headings describe meaningful sections, such as product details, delivery information, and reviews? Can you use them to understand the page without listening to every word?
- Links and buttons: Do labels make sense when encountered on their own? “View size guide” is more useful than “Click here.” Repeated “Add” buttons on a product listing may need product-specific context.
- Images: Does important product imagery have useful text alternatives? A description should convey purchase-relevant information when that information is not available nearby in text. Decorative images need not be announced as meaningful content.
- Price and availability: Can you identify the current price, any sale price, selected variant, and stock status without guessing?
For example, if color swatches display only colored circles, listen to how each choice is announced. A shopper should hear something useful such as “Navy, selected” rather than “button” or a file name.
Check forms, errors, and changing content
Move through the checkout form by its controls. Each field should have a clear label; placeholder text alone can be difficult to rely on once typing begins. Required fields and formatting instructions should be understandable before submission where possible.
Submit the form with a missing or invalid value. Does the error identify the problem and tell you how to correct it? Can you find the affected field? Repeat the test for changes that happen without a full page reload, such as applying a discount code, updating the cart quantity, or selecting a delivery method. A visible change is not necessarily an announced change.
Check dialogs, menus, and the final confirmation
Open a cart drawer, account menu, or pop-up. Listen for a meaningful name or context, confirm that you can reach its controls, and close it. Then check where your keyboard focus lands. Finally, verify that an order confirmation clearly communicates the result and any next steps.
A practical page-by-page ecommerce accessibility checklist
| Page or feature | Keyboard test | Screen reader test |
|---|---|---|
| Header and search | Open navigation and submit a search without a mouse. | Identify menu controls, the search field, and results. |
| Collection page | Operate filters and sorting; reach product links. | Understand filter names, selected options, and product information. |
| Product page | Select variants, adjust quantity, and add to cart. | Hear option names, selection state, price, and cart feedback. |
| Cart | Change quantity, remove an item, and continue to checkout. | Understand updated totals and any error messages. |
| Checkout | Complete fields, recover from errors, and reach payment controls. | Identify labels, instructions, errors, and order confirmation. |
This is a focused manual test, not a complete accessibility audit. It gives you a repeatable way to uncover high-impact issues in the path to purchase.
How to record and prioritize what you find
For each issue, write down the page URL, the action you attempted, what happened, what you expected, and the device, browser, and assistive technology used. A short screen recording can help your team reproduce a complex problem, but include written steps too.
Prioritize barriers that prevent shoppers from finding products, selecting options, understanding prices, or completing checkout. Next, address issues that make those tasks confusing or unusually slow. This is more useful than treating every finding as equally urgent.
When working with a developer, theme vendor, or app provider, describe the customer task rather than prescribing a technical fix you have not verified. “I cannot select a size with the keyboard on this product page” is a clearer starting point than “add ARIA to the selector.” Technical solutions should be tested after implementation; adding accessibility attributes does not automatically make a control usable.
Common testing mistakes to avoid
- Relying only on an automated scanner. Automated tools can flag some issues, but they cannot tell you whether a shopper can successfully choose a variant or recover from a checkout error.
- Testing only one page or device. Themes, apps, and payment components can behave differently across templates and screen sizes.
- Using Tab as your entire screen reader test. Screen reader users also navigate by headings, links, controls, and other page structure.
- Fixing the visual symptom only. A button might gain a focus outline but still have no useful name when announced.
- Testing once and stopping. New apps, campaigns, product options, and theme updates can introduce new barriers.
The Web Content Accessibility Guidelines (WCAG) 2.2 are a useful technical benchmark for planning and checking improvements. Legal requirements differ by jurisdiction and business context, so seek qualified advice if you need to assess your specific obligations. Manual keyboard and screen reader testing helps you understand the customer experience, but it does not establish full WCAG conformance on its own.
Make accessibility part of your store workflow
You do not have to fix every issue in a single project to make progress. Start with one complete purchase journey, resolve the barriers that block it, and retest. Then add a short keyboard and screen reader check whenever you change your theme, install an app, redesign a product page, or update checkout.
Your next step: put away your mouse and try to buy one of your own products. Record the first point where you get stuck or cannot tell what happened. That specific finding is a practical place to begin improving your store for more shoppers.
Frequently asked questions
Can I test my ecommerce store with only a keyboard?
Yes. Keyboard-only testing is an effective first pass for finding unreachable controls, missing focus indicators, and confusing navigation order. Add a screen reader test to check whether controls and page updates are communicated clearly.
Which screen reader should I use to test my store?
NVDA on Windows and VoiceOver on macOS are practical starting points. Use each tool with a compatible browser, learn its basic navigation commands, and document your setup when reporting issues. Testing more than one combination can reveal differences, but one repeatable test is better than none.
Does passing an automated accessibility scan mean my checkout is accessible?
No. An automated scan can identify certain technical issues, but it cannot confirm that a customer can understand product choices, respond to errors, and complete an order using a keyboard and screen reader. Test those tasks manually.
How often should I repeat accessibility testing?
Retest important shopping journeys after changes to your theme, navigation, product options, apps, or checkout. A regular check of your most-used templates can also help you catch problems before they persist across many product pages.