Someone lands on your store from a search, finds the product they want, and then gets stuck. Maybe the size dropdown will not open from the keyboard. Maybe the screen reader says “button” with no name when they reach the cart icon. Maybe the checkout throws an error in red text that nobody tells them about. They leave, and you never find out why.
That is what ecommerce accessibility is really about: whether a person using a keyboard, a screen reader, voice control or a zoomed-in screen can get from your home page to a confirmed order without help. This guide walks the whole shopping journey in the order a customer meets it, and points out where stores usually break.
Why ecommerce accessibility asks more than a brochure site
A five-page site for a law office is mostly text, a menu and a contact form. A store is an application. It has search, filters that change results without reloading, product options that change the price, a cart that updates in place, a checkout with a dozen fields and a payment step that often comes from another company. Every one of those moving parts has to tell assistive technology what just happened.
Stores also change constantly. New products, new plugins, a holiday banner, a new payment method. A store that passed a check in spring can fail one in the fall without anyone touching the theme, because a new plugin arrived with its own buttons and popups.
For US businesses there is also the legal side. Online stores get ADA demand letters like any other business site, and the benchmark those letters point to is usually WCAG 2.1 or 2.2 Level AA. Legal questions belong with an attorney, since nothing here is legal advice. The practical point is that the same standard that keeps a lawyer’s letter specific also gives you a clear technical target.
The header, menu and search box
Every visit starts here, so problems in the header repeat on every page. Press Tab from the top of your home page and watch.
- Skip link. The first Tab should reveal a “Skip to content” link. Without it, a keyboard user tabs through the logo, every menu item and every icon before reaching anything useful, on every page.
- Dropdown menus. Category menus that open only on mouse hover are one of the most common barriers in retail themes. A keyboard user should be able to open a submenu, move through it and close it with Escape. Our guide to an accessible dropdown menu covers how that should behave.
- Icon buttons. Account, wishlist, search and cart are often icons with no text. Each needs an accessible name such as “Cart, 2 items” so a screen reader does not announce a bare “link”.
- Search. The search field needs a real label, not just a magnifying glass. If suggestions appear as you type, they should be reachable with arrow keys and the number of suggestions should be announced.
Category pages, sorting and filters
Category pages are where shoppers narrow things down, and they are often the most complex screens in the store. Filters by size, color, price and brand usually update the product grid without a page reload. To a sighted mouse user that feels quick. To a screen reader user, nothing happened unless the page says so.
Things to check:
- Every filter checkbox and radio button has a label you can click, and the group has a name (“Size”, “Color”).
- Price sliders can be moved with arrow keys, or there are plain min and max fields as well.
- After a filter is applied, a short message like “24 products found” is announced, and focus does not jump to the top of the page.
- The sort menu does not reload the page the instant you arrow through it.
- Pagination and “Load more” buttons are big enough to tap and say where they go.
Filters get their own detailed post on accessible faceted search and filter controls, because there is a lot that can go wrong there.
The product grid itself matters too. Each product card usually has an image, a title, a price, maybe a rating and a quick “Add to cart” button. If the image, title and button are three separate links to the same product, a keyboard user tabs three times per product. One link per card, with the title as its text, is calmer to move through.
The product page
This is the page that sells. It is also where a lot of custom widgets live.
Images and galleries
Product photos need alt text that describes what a shopper needs to know: color, material, what is in the box. “Product image 1” helps nobody. Galleries with thumbnails should be operable from the keyboard, and a zoom or lightbox needs a visible close button and should close with Escape.
Options, swatches and price
Color swatches are a classic trouble spot. A row of colored circles with no text means a screen reader user hears “button, button, button” and a color-blind shopper cannot tell two shades apart. Each swatch needs a name, and the selected one needs to be announced as selected. When a choice changes the price or stock status, that change should be announced as well.
Quantity and add to cart
The quantity field needs a label, and plus and minus buttons need names, not just symbols. After “Add to cart”, many stores show a small notice or slide open a mini cart. If that confirmation is silent for screen reader users, they may add the item three times or give up, unsure whether it worked.
Tabs and accordions should work with the keyboard and say whether they are open. A size guide in a popup has the same needs as any modal: focus moves into it, stays there until it is closed, and returns to the button that opened it. The details of the whole page are in our post on accessible product pages and product image alt text.
Cart and mini cart
The cart page is a table of items with quantities, prices, remove links and a coupon field. Common problems:
- “Remove” links that are a small “x” with no name. Ten items, ten unnamed links.
- Changing a quantity updates totals silently, so a screen reader user does not know the total changed.
- A coupon error that appears in red text near the top of the page, far from the field, and is never announced.
- A mini cart drawer that opens over the page but leaves keyboard focus behind it.
If your store runs on WooCommerce, the specific patterns we see there, including the mini cart, store notices and the difference between the classic and block cart, are in common WooCommerce accessibility issues.
Checkout: where an accessible online store earns its sales
If one part of the journey gets your attention first, make it checkout. A barrier on a blog post is annoying. A barrier at checkout is a lost order.
A good checkout has a visible label on every field, uses the browser’s autofill so people do not retype their address, says clearly which fields are required, and handles errors properly: it tells you what went wrong, next to the field, in words, and moves you to the problem. It does not ask for the shipping address twice when billing is the same. It does not log you out partway through without warning.
The payment step needs separate attention. Card fields are often loaded inside a frame from the payment provider. You cannot rewrite that code, but you can test it, choose providers whose fields work with a keyboard and screen reader, and make sure the frame has a sensible title. Express buttons for wallets need names that say what they are.
Our step-by-step post on checkout accessibility goes field by field. Error handling, which trips up almost every store, has its own post on form error messages that people can find and understand. If you protect checkout or the account page from bots, read about accessible CAPTCHA alternatives before adding a puzzle.
Accounts, orders and returns
After the sale, customers come back to check an order, change an address or start a return. Login forms need labels, password fields should allow pasting so people can use a password manager, and one-time codes should not expire before someone using a screen reader can type them. WCAG 2.2 added a criterion, 3.3.8 Accessible Authentication (Minimum), that is about exactly this: logging in should not depend on memorizing or transcribing something unless there is help.
Order history is usually a table. It needs proper column headers so a screen reader can say “Status: Shipped” rather than reading a string of unrelated values. Return forms are forms like any other and need the same labels and error handling as checkout.
Order emails and receipts
Emails are part of the journey, and they are easy to forget. Order confirmations, shipping updates and password resets should have real text, not just an image of text, a logical reading order, enough color contrast and link text that says where it goes (“Track your package”, not “Click”). If you attach PDF invoices, either make them tagged and readable or give the same information in the email body.
Things that sit on top of every page
Some of the worst barriers are not part of the store at all. They are added on top:
- Newsletter and discount popups that appear after a few seconds, trap focus or cannot be closed from the keyboard. See our post on accessible popups and modals.
- Cookie banners that cover the bottom of the page and cannot be reached with Tab.
- Chat buttons that float over the “Place order” button or cover the focused field on small screens. Our live chat accessibility post covers what to ask a chat vendor.
- Overlay widgets sold as an instant fix. They add a toolbar but do not repair the cart, the filters or the checkout underneath.
A sensible order of work for a store
You do not need to fix everything at once. A practical order:
- Test one purchase end to end with the keyboard only. Pick a product with options, add it, change the quantity, apply a coupon, check out as a guest with a test payment. Write down every place you get stuck. Our post on keyboard navigation testing has a recording sheet.
- Fix checkout and cart first. These block revenue and they are what a complaint is most likely to describe.
- Fix the templates, not single pages. The product template, category template and header are shared by hundreds of pages. One fix there repairs all of them.
- Then the product page widgets: swatches, galleries, tabs, size guides.
- Then content: alt text for product images, descriptive link text, headings in descriptions. This is ongoing work for whoever adds products.
- Then the add-ons: popups, chat, cookie banner, reviews.
- Retest after updates. A theme or plugin update can undo work. Check checkout after every significant update.
Write down what you fixed and when. If questions come later from a customer or a lawyer, a dated record of real work is far more useful than a badge.
Does the platform matter?
Somewhat. WooCommerce gives you full control of the theme and plugins, which means you can fix nearly anything, and also that any plugin can add a barrier. Shopify controls its checkout more tightly, which removes some problems and limits what you can change in others, and most barriers come from the theme and installed apps. Our Shopify store accessibility post covers that side. On either platform, ecommerce accessibility comes down to the same shopping journey and the same tests.
If you would like a quick outside view before deciding anything, our free website accessibility check looks at a sample of pages and tells you what stands out. It is not a full audit, and it does not pretend to be one.
Frequently asked questions
Does an online store have to be accessible under the ADA?
Courts have not all agreed on how the ADA applies to websites, especially stores with no physical location, and there is no DOJ technical rule for business websites. The DOJ has said for years that the ADA covers the web content of businesses open to the public. A lawyer can tell you how it applies to you; WCAG 2.2 AA is the sensible technical target either way.
Which part of a store should I fix first?
Checkout and cart. They are where a barrier costs you an order, and they are often what complaints describe. Test a full guest purchase with only the keyboard, note every point where you get stuck or cannot tell what happened, and fix those before moving on to product pages and category filters.
Can I test my store myself without special software?
You can do a useful first pass. Put the mouse away and try to buy something with Tab, Enter, Space and the arrow keys. Zoom the browser to 200 percent and see if anything breaks. Run a free scanner such as WAVE on the product and checkout pages. That will not find everything, but it shows the biggest barriers.
Will an accessibility widget make my store accessible?
No. A widget adds a toolbar that changes fonts or colors, but it does not give names to unlabeled buttons, fix a mini cart that traps focus or make payment fields announce errors. Sites using overlays have still been sued. Fixing the theme, templates and plugins is what removes the barriers.
How often should a store be rechecked?
Check checkout after every significant theme, plugin or payment update, and do a broader check every month or so. New products bring new images and descriptions, and new plugins can add popups or widgets. Small regular checks catch problems before customers do.
If you would rather have someone go through the shopping journey with you, we audit stores against WCAG 2.2 AA, fix the theme and plugin problems we find, and keep checking after updates. You can read how that works on our WooCommerce accessibility page, or start with the wider picture of our website accessibility services.
All guides in this section
- WooCommerce Accessibility Issues and How to Fix Them
- Accessible Checkout: A Field-by-Field Guide for Stores
- Accessible Form Design: Labels, Groups and Layout
- Accessible Error Messages on Website Forms
- CAPTCHA Accessibility and Alternatives That Work
- Accessible Product Pages: Images, Swatches, Add to Cart
- Shopify Accessibility: What Store Owners Can Fix
- Accessible Booking Forms: Dates, Time Slots, Confirmation
- WordPress Contact Form Accessibility: What to Check
- Product Filter Accessibility for Online Stores
- Chat Widget Accessibility: Live Chat That Works for All
Next in this series: WooCommerce Accessibility Issues and How to Fix Them
