Online shopping is a daily activity for millions of people. It is how many of us buy groceries, clothing, electronics, gifts, and essential services. For people with disabilities, an accessible e-commerce site is not just a convenience. It can be the difference between being able to shop independently and having to rely on someone else to make purchases for them.

Yet a surprising number of online stores still have accessibility barriers that prevent users with disabilities from browsing products, adding items to a cart, or completing checkout. According to multiple studies, the average e-commerce site has dozens of WCAG violations, and the most critical barriers tend to appear at exactly the moments that matter most: product pages and checkout flows.

In this guide, we will walk through the unique accessibility challenges of e-commerce sites, the WCAG requirements that apply, and practical steps you can take to make your online store usable for every shopper.

Why E-commerce Accessibility Matters More Than You Think

When a physical store has a step at the entrance, wheelchair users cannot get in. The same principle applies online. If your product pages, navigation, search, or checkout are not accessible, you are turning away customers at the door. The difference is that online, the barrier is often invisible to the store owner.

Consider these points:

  • Market reach: Roughly one in four adults in the United States lives with a disability. If your store is not accessible, you are excluding a significant portion of your potential customer base.
  • Legal risk: The ADA applies to e-commerce sites. Major retailers have faced lawsuits over inaccessible checkout buttons, missing alt text on product images, and forms that screen readers cannot fill out.
  • Revenue impact: Every shopper who abandons a cart because your checkout is inaccessible is a lost sale. Accessibility barriers directly reduce conversion rates.
  • SEO benefits: Many accessibility improvements, such as descriptive page titles, clear heading structure, and alt text on product images, also improve search engine rankings.

For more on the business case for accessibility, see our guide on the benefits of web accessibility.

Key WCAG Requirements for E-commerce Sites

E-commerce sites need to meet the same WCAG standards as any other website, but certain success criteria are especially relevant. Here are the ones that most commonly affect online stores.

1.4.3 Contrast (Minimum) (Level AA)

Text on product pages, buttons, and forms must have sufficient contrast against its background. Low contrast is one of the most common issues on e-commerce sites, especially with light gray text on white backgrounds for pricing, product descriptions, and “Add to Cart” buttons.

1.4.11 Non-text Contrast (Level AA)

This criterion extends contrast requirements to user interface components like form field borders, button outlines, and focus indicators. If a shopper cannot see the “Buy Now” button or the input field for their credit card number, they cannot complete their purchase.

2.4.6 Headings and Labels (Level AA)

Product pages, category pages, and checkout steps should use clear, descriptive headings and labels. A screen reader user navigating by headings should be able to find the product title, price, description, and add to cart section quickly.

3.3.2 Labels or Instructions (Level A)

When content requires user input, provide labels or instructions. This is critical for checkout forms: name, shipping address, credit card fields, and billing information all need clear labels that screen readers can announce.

3.3.3 Error Suggestion (Level AA)

If a checkout form detects an error, such as an invalid credit card number or missing zip code, it should suggest a correction. “Please enter a valid 16 digit card number” is far more helpful than “Error” with no explanation.

4.1.3 Status Messages (Level AA)

When a user adds an item to their cart, applies a discount code, or submits a form, the confirmation or error message should be announced to assistive technology without requiring the user to move focus. This is done using ARIA live regions.

For a full overview of WCAG levels and requirements, see our guide on the levels of WCAG compliance.

Making Product Pages Accessible

Product pages are the heart of any e-commerce site. They are where shoppers decide what to buy. Here is how to make them accessible.

Product Images and Alt Text

Every product image needs descriptive alt text. This is not just for screen reader users. Alt text also helps SEO and appears when images fail to load. For product images, the alt text should describe the product clearly enough that a shopper who cannot see the image still understands what is being sold.

Good alt text: “Men’s navy blue cotton crew neck t-shirt, front view.”

Bad alt text: “img1234” or “shirt” or “image of product.”

If you offer multiple product images showing different angles, colors, or details, each one should have unique alt text that describes what is different about that particular view. For example: “Same t-shirt, back view showing plain design” or “Same t-shirt in burgundy color option.”

For a deep dive on writing effective alt text, see our guide on accessible images and alt text.

Product Titles and Headings

The product name should be the main heading on the page, typically an <h1>. Product attributes like “Description,” “Specifications,” “Reviews,” and “Shipping Information” should be subheadings (<h2> or <h3>) so screen reader users can jump between sections.

Avoid using heading tags purely for visual styling. If text looks like a heading, make it a heading. If it is not a heading, style it with CSS instead.

Pricing Information

Pricing should be clearly associated with the product. Do not rely on visual proximity alone to connect a price to a product. Use semantic HTML so the price is announced in context. If the price has multiple components (original price, discount price, per unit price), make sure each part is labeled clearly.

For example, instead of just showing “$29.99 $19.99” with one struck through, use markup that communicates “Original price $29.99, sale price $19.99.”

Product Variants and Dropdowns

Product variants like size, color, and quantity often use dropdown menus or radio buttons. These must be accessible:

  • Every dropdown or option group needs a label that is programmatically associated with it.
  • Radio buttons for color or size selections should have text labels, not just color swatches. If you use color swatches, include the color name as text or as an aria-label.
  • When a shopper selects a variant, any change in price or availability should be announced to screen reader users via an ARIA live region.

Product Reviews

User reviews add value but often introduce accessibility problems. Watch for:

  • Star ratings that are images without alt text. Each star icon image needs an alt attribute, or the rating should be conveyed as text like “4 out of 5 stars.”
  • Review forms that lack proper labels on input fields.
  • Review content that uses heading levels inconsistently, making it hard to navigate between reviews.

Quantity and Add to Cart Controls

The “Add to Cart” button is the most important call to action on a product page. Make sure it is:

  • A real <button> element, not a <div> or <span> styled to look like a button.
  • Keyboard focusable and operable with the Enter and Space keys.
  • Clearly labeled. “Add to Cart” is clear. A shopping cart icon with no text label is not.
  • Announced as a button to screen readers.

Quantity selectors should be standard form controls with associated labels. If you use plus and minus buttons to change quantity, make sure those buttons are accessible and that the current quantity value is announced when it changes.

Accessible Search and Filtering

Many shoppers use search to find products. If your search is not accessible, some users will never find what they are looking for.

Search Bar Accessibility

The search input field needs a label. A visually hidden <label> element is fine as long as it is programmatically associated with the input. A placeholder is not a substitute for a label because placeholders disappear once the user starts typing and may not be announced by all screen readers.

The search button should be a real <button> with a descriptive label. If it is a magnifying glass icon, include text like “Search” or use an aria-label="Search" on the button.

Filter and Facet Controls

Product filters (by category, price range, brand, rating) are often implemented as custom widgets that can be difficult for keyboard and screen reader users. To make them accessible:

  • Use standard HTML form controls where possible (checkboxes, radio buttons, select elements).
  • If you build custom filter widgets, use ARIA roles, states, and properties to communicate what the widget is and how it works. See our guide on how to use ARIA for web accessibility for detailed instructions.
  • When filters are applied and the product list updates, announce the change (such as “12 products found”) using an ARIA live region so screen reader users know the results changed.
  • Make sure filtered results can be navigated by keyboard without getting trapped.

Making the Shopping Cart Accessible

The shopping cart is a critical checkpoint in the e-commerce journey. Here is how to make it work for everyone.

Cart Contents and Updates

When a shopper adds an item to their cart, the cart total and item count should update and the change should be announced. Do not force the user to navigate to the cart page to confirm their item was added. Use an ARIA live region to announce “Product added to cart” or update the cart count indicator in a way that screen readers detect.

Cart Item Layout

Each item in the cart should have a clear structure. Use a definition list, a table, or a well structured list with headings. Each item should show:

  • Product name
  • Quantity (with an accessible way to change it)
  • Price
  • Remove button (a real, labeled <button>)

If you use a table layout for the cart, follow the principles in our guide on accessible data tables.

Quantity Controls in the Cart

Just like on the product page, quantity controls in the cart should be standard form inputs with labels. If you use plus and minus buttons, make sure they are real buttons with accessible names and that the updated quantity is announced.

Removing Items

The remove button should have a clear text label or an aria-label like “Remove Men’s navy blue t-shirt from cart.” A trash can icon with no text or label is not accessible. Confirm to the user that the item was removed by announcing the change.

Accessible Checkout: The Most Critical Flow

Checkout is where the most accessibility barriers occur, and it is also where the highest stakes are. A shopper who makes it all the way to checkout and then cannot complete their purchase is a lost customer who may never return.

Checkout Form Labels

Every form field in checkout needs a programmatically associated <label>. This includes:

  • Shipping address fields (name, street, city, state, zip code, country)
  • Billing address fields
  • Credit card fields (card number, expiration, CVV)
  • Contact information (email, phone)
  • Shipping method selection

Use <label for="..."> paired with id attributes on the inputs. Do not rely on placeholder text, which disappears and is not a proper label. For detailed guidance on building accessible forms, see our guide on accessible forms.

Error Handling and Validation

Checkout errors are frustrating for everyone, but they are especially problematic for users with disabilities if not handled accessibly.

  • Do not rely on color alone to indicate errors. A red border around a field is not enough. Include text that says what the error is and how to fix it.
  • Announce errors using ARIA. Use aria-live="assertive" or aria-live="polite" on an error message container so the screen reader announces the error when it appears.
  • Set focus to the first error. When the form is submitted with errors, move keyboard focus to the first field with an error so the user knows where to start fixing things.
  • Provide clear error messages. “Please enter your shipping zip code” is helpful. A generic “Please fix the highlighted errors” is not, especially if the highlights are not accessible.

Payment Method Selection

If you offer multiple payment methods (credit card, PayPal, Apple Pay, etc.), the selection controls should be accessible radio buttons or buttons with proper ARIA attributes. Each option should have a clear text label, not just a logo.

If payment fields change based on the selected method (for example, credit card fields appear when “Credit Card” is selected), make sure the new fields are announced to screen reader users when they appear.

Place Order Button

The final “Place Order” or “Complete Purchase” button should be:

  • A real <button> element.
  • Clearly labeled with descriptive text.
  • Keyboard accessible.
  • Not disabled unless there is a clear, announced reason. If the button is disabled because required fields are empty, make sure screen reader users understand why.

Order Confirmation

After the order is placed, the confirmation page or message should be accessible. The order number, total, and shipping information should be in a logical reading order with clear headings. If you send a confirmation email, that email should also be accessible (though email accessibility is a topic of its own).

Account Registration and Login

Many e-commerce sites require or encourage account creation. The registration and login forms have the same accessibility requirements as checkout forms.

  • Every field needs a label.
  • Error messages need to be clear and announced.
  • Password requirements should be listed before the field, not shown only after a failed attempt.
  • “Show password” toggles should be accessible buttons with descriptive labels.
  • “Remember me” checkboxes should be standard HTML checkboxes with labels.
  • Social login buttons (Log in with Google, Facebook, etc.) should be real buttons with descriptive text labels, not just icons.

Mobile E-commerce Accessibility

A large share of online shopping happens on mobile devices. Mobile accessibility for e-commerce means more than just responsive design.

  • Touch targets for buttons and form controls should be at least 44x44 pixels so they are easy to tap for users with motor impairments.
  • The checkout flow should not require hover interactions, which do not work on touch screens.
  • Product image zoom and swipe galleries should have accessible alternatives, not just gestures that cannot be performed with a keyboard or screen reader.
  • Make sure the cart and checkout are usable in portrait and landscape orientation without locking to one mode.

For more on designing for every screen, see our guide on mobile web accessibility.

Common E-commerce Accessibility Barriers (and How to Fix Them)

Here is a summary of the most common accessibility problems on e-commerce sites and their fixes.

1. Product Images Without Alt Text

Problem: Product photos have no alt attribute or generic alt text like “image.” Fix: Write descriptive alt text for every product image that conveys what a shopper needs to know to make a buying decision.

2. Checkout Forms Without Labels

Problem: Input fields use placeholder text instead of labels, so screen reader users do not know what each field is for. Fix: Add <label> elements associated with each input via for and id attributes.

3. Add to Cart Buttons Built With Divs

Problem: “Add to Cart” is a styled <div> with an onclick handler, which keyboard and screen reader users cannot operate. Fix: Replace with a real <button> element with descriptive text.

4. Color Only Error Indicators

Problem: Form errors are shown with red borders or red text, with no text explanation. Fix: Add text error messages and announce them with ARIA live regions.

5. Inaccessible Filter Widgets

Problem: Product filters are custom JavaScript widgets with no keyboard support or ARIA attributes. Fix: Use standard HTML form controls or add ARIA roles, keyboard handlers, and live region announcements.

6. Cart Updates Not Announced

Problem: Adding an item to the cart changes the cart count visually but screen reader users get no feedback. Fix: Use an ARIA live region to announce cart updates.

7. Missing Focus Indicators

Problem: The default browser focus outline is removed and not replaced, so keyboard users cannot see where they are on the page. Fix: Provide a visible, high contrast focus indicator for all interactive elements. See our guide on keyboard accessibility for details.

8. Inaccessible Product Carousels

Problem: Product carousels auto rotate and cannot be paused, or they trap keyboard focus. Fix: Provide pause controls, ensure keyboard users can navigate through carousel items, and do not auto rotate by default.

Testing Your E-commerce Site for Accessibility

Building an accessible store is an ongoing process. You need to test regularly.

Automated Scanning

Run an automated accessibility scanner on your product pages, cart, and checkout. Tools like Accessible Metrics can detect missing alt text, unlabeled form fields, low contrast, missing focus indicators, and many other issues automatically. Start with a free scan to get a baseline of where your store stands.

Manual Keyboard Testing

Navigate your entire checkout flow using only a keyboard. Can you tab to every field, every button, and every link? Can you fill out the form and submit it without using a mouse? If you get stuck, your customers who rely on keyboards will too.

Screen Reader Testing

Test your checkout with NVDA (free, Windows), VoiceOver (built into macOS and iOS), or TalkBack (built into Android). Go through the full purchase flow from product page to order confirmation. Listen for missing labels, unlabeled buttons, and confusing announcements.

For more on testing methods, see our guides on how to test the accessibility of your website and automated vs manual accessibility testing.

A Quick Checklist for E-commerce Accessibility

Use this checklist to review your online store:

  • Every product image has descriptive alt text.
  • Product pages use a clear heading structure with the product name as the <h1>.
  • Pricing information is clearly labeled and associated with the product.
  • Product variant selectors (size, color) have accessible labels.
  • The search bar has a proper label and an accessible submit button.
  • Product filters are keyboard accessible and use ARIA where needed.
  • The “Add to Cart” button is a real <button> with a text label.
  • Cart updates are announced to screen readers via ARIA live regions.
  • Every checkout form field has a programmatically associated <label>.
  • Form errors include text messages, not just color changes.
  • Error messages are announced and focus moves to the first error.
  • The “Place Order” button is a real <button> with descriptive text.
  • All interactive elements have visible, high contrast focus indicators.
  • The checkout flow works on mobile with adequate touch target sizes.
  • The order confirmation page is accessible with clear headings and reading order.

The Bottom Line for Online Stores

E-commerce accessibility is not optional. It is a legal requirement, a business imperative, and a matter of basic fairness. When your online store is accessible, you open your doors to every shopper, you reduce legal risk, you improve SEO, and you increase revenue.

The most important thing is to start. Run a scan, fix the high impact issues first (product page alt text, checkout form labels, and add to cart buttons), and then work through the rest systematically. Every barrier you remove is a customer you welcome back.

Is your online store accessible to every shopper? Sign up for Accessible Metrics and run a free accessibility scan today. You will get a detailed report against WCAG 2.1 AA standards that shows exactly what needs fixing on your product pages, cart, and checkout, so you can turn every visitor into a customer.