E-Commerce Website Accessibility Requirements: The Complete 2026 Guide

Every product thumbnail needs alt text that describes the product: "Women's blue denim jacket, front view" — not "product-img-001" or empty. If you have 500 products, that's 500+ alt texts to write. Batch this with your product data entry process.

Product titles in images can't be read by screen readers or resized by users with low vision. Always use HTML text for product names.

Screen reader users need to know prices. If prices are rendered as images, within canvas elements, or via CSS content, they're invisible to assistive technology. Ensure prices are in the DOM as text.

Red strikethrough prices are invisible to colorblind users. Add text labels: "Was $49.99, now $29.99" or "Sale" badges with text, not just color changes.

If you offer different view modes, both the toggle controls and the resulting layouts must be navigable via keyboard.

When a quick-view popup opens, focus must move to the modal. Users must be able to close it with Escape. Focus must return to the trigger element when closed.

Users must be able to navigate between product images, trigger zoom, and close zoom using only a keyboard. Touch-only gestures (swipe, pinch-zoom) need button alternatives.

Dropdowns, radio buttons, and swatch selectors all need visible labels or aria-labels. Color swatches that are only visual (no text label like "Navy Blue") are inaccessible to screen reader users and colorblind users.

The quantity stepper (+ / - buttons and input field) needs a label ("Quantity"), and the +/- buttons need accessible names. Custom steppers that only respond to mouse clicks fail keyboard users.

The button text should be descriptive. "Add to Cart" is clear. An icon-only cart button needs aria-label="Add to Cart". After clicking, provide feedback ("Item added to cart") via aria-live region.

Star ratings need text equivalents ("4 out of 5 stars"). Review text must be real text, not images. Sort and filter controls for reviews need labels.

Product detail tabs should use role="tablist", role="tab", role="tabpanel", and proper aria-selected, aria-controls, and keyboard arrow navigation.

Cart contents must be accessible to screen readers

Each item in the cart needs its name, price, quantity, and subtotal available as text. Data tables or structured lists work well. Avoid relying on visual layout alone.

Remove and quantity controls need labels

A generic "X" button needs aria-label="Remove Blue Denim Jacket from cart". Quantity inputs need to be associated with their product.

Cart updates must announce changes

When quantity changes or items are removed, use aria-live regions to announce the change: "Blue Denim Jacket removed from cart. Cart total: $129.99."

Promo code input needs a label

The coupon/promo code field needs a visible or aria label. "Enter promo code" as placeholder text alone is not sufficient.

Name, address, city, state, zip, email, phone, card number, expiration, CVV &mdash; every field needs a <label> element or aria-label. Placeholder text is NOT a label. This is the #1 most cited ecommerce violation.

"Please fix the errors below" is not helpful. Each error must identify the field and the problem: "Email address: Please enter a valid email (e.g., name@example.com)." Errors should be programmatically associated via aria-describedby.

Google Places autocomplete and similar widgets must work with keyboard navigation. Users must be able to arrow through suggestions and select with Enter.

Third-party payment processors (Stripe Elements, PayPal, Square) embed iframes. Each iframe needs a title attribute: "Credit card payment form." The content inside the iframe should also be accessible.

Multi-step checkouts (Shipping > Payment > Review) need accessible step indicators. Use aria-current="step" on the active step and ensure the step count is available to screen readers.

Before the final "Place Order" button, users must be able to review everything &mdash; items, quantities, shipping, taxes, total &mdash; via screen reader. This also satisfies WCAG SC 3.3.4 (error prevention for financial transactions).

If your checkout times out, warn users at least 20 seconds before expiration and give them the option to extend. Timed sessions that expire without warning violate SC 2.2.1.

Search input must be labeled

The search field needs a visible label or aria-label ("Search products"). The search button needs an accessible name. Autocomplete suggestions must be keyboard navigable.

Filter controls need labels and state announcements

Checkbox filters ("Size: S, M, L, XL") need group labels and individual labels. When a filter is applied, announce the result count: "24 products found for Size: Medium."

Price range sliders need keyboard alternatives

Custom slider controls for price filtering must be operable via keyboard (arrow keys) and have proper ARIA attributes (role="slider", aria-valuemin, aria-valuemax, aria-valuenow). Or provide text inputs as an alternative.

Sort controls must be properly labeled

"Sort by" dropdowns need a label. The selected option should be announced to screen readers when changed.

Dynamic result updates need live region announcements

When filtering changes the displayed products without a page reload, use aria-live to announce the new result count. Otherwise, screen reader users won't know anything changed.

Shopify

Shopify's Dawn theme (default since 2.0) has significantly better accessibility than older themes, but it's not perfect out of the box. Key considerations:

• • Theme choice matters enormously. Free themes vary widely in accessibility. Dawn is the safest starting point. Third-party themes often have poor contrast, missing form labels, and non-semantic HTML.
• • Alt text must be added manually. Shopify provides an alt text field for product images, but it's empty by default. Train your team to fill this in for every product image upload.
• • Apps can break accessibility. Third-party Shopify apps inject their own HTML/CSS/JS. Review, popup, and upsell apps are frequent offenders. Test after installing any new app.
• • Checkout is semi-locked. Shopify's checkout is standardized, so core accessibility is handled. But custom checkout fields, scripts, or Checkout Extensibility apps need manual testing.

WooCommerce (WordPress)

WooCommerce inherits WordPress's accessibility, which means it depends heavily on your theme choice and plugin configuration.

• • Use an accessibility-ready theme. WordPress.org tags themes as “accessibility-ready” after review. Start with one of these. Storefront (WooCommerce's own theme) is a reasonable baseline.
• • Plugin conflicts are common. Page builders (Elementor, Divi) can override semantic HTML. Caching plugins can break ARIA live regions. Test thoroughly with each plugin combination.
• • Payment gateways vary. Stripe for WooCommerce has decent accessibility. Some other gateways inject inaccessible iframes without titles. Test your specific payment flow with a screen reader.
• • Image alt text is a WordPress feature. The media library supports alt text, but it requires manual entry. Bulk-editing alt text for existing products is possible via plugins or direct database update.

Magento / Adobe Commerce

• • Luma theme has baseline accessibility, but it's outdated. Adobe Commerce customers should invest in custom accessible frontend (e.g., Hyvae/PWA Studio with accessibility auditing).
• • Category layered navigation is a known issue. Filter controls in the sidebar often lack proper ARIA labels and keyboard handling. Custom work is usually needed.
• • Configurable products (size/color dropdowns) generally work, but custom attribute swatches may lack accessible names.

Custom / Headless (React, Vue, Next.js)

• • You have full control and full responsibility. No platform defaults will save you. Every component must be built accessibly from the ground up.
• • SPA routing needs focus management. After client-side navigation, set focus to the main content area or new page heading. Otherwise, screen reader users lose their place.
• • Dynamic content needs live regions. Cart updates, filter results, and form validation happening without page reload must use aria-live to announce changes.
• • Use established component libraries. Radix UI, Headless UI, and React Aria provide pre-built accessible components for dialogs, dropdowns, tabs, and more. Don't reinvent the wheel.