Shopify Accessibility: Fix Your Product Page for WCAG
A seven-row product-page audit maps Shopify buying controls to WCAG criteria, practical tests, fixes, and likely owners.
Shopify accessibility means making your store's content and buying controls usable by people with disabilities. On a product page, test images, variants, modals, purchase controls, live updates, quantity controls, and galleries against Web Content Accessibility Guidelines (WCAG) 2.2.
I ran two one-time-purchase Shopify stores, one selling niche products and the other print-on-demand apparel. For a small store, I'd audit the product page first. It puts 7 high-priority controls in one place, and one blocked action can stop a purchase.
For this audit, I mapped seven controls to W3C and Shopify accessibility guidance.
I also checked the US DOJ's Title III business guidance, then paired each control with a manual test.
Key takeaways
What does Shopify accessibility mean for your product page?
Shopify accessibility means your storefront lets disabled shoppers understand the product, choose a variant and quantity, and buy it. W3C recommends WCAG 2.2 as the testing target. Use its four principles to organize the audit:
- Perceivable: Shoppers can detect the content and controls.
- Operable: Shoppers can use every required interaction.
- Understandable: Labels, instructions, and results make sense.
- Robust: Assistive technology receives the right names, roles, and states.
Merchants control the theme, content, CSS, and app blocks customers receive. Shopify supplies guidance and theme controls. Its theme accessibility guidance can't guarantee the delivered storefront is fully accessible.
Use the criterion numbers to trace the standard, then test the shopper's task. A control passes only when a person can find and understand it. They must also be able to operate it and receive the result through their chosen tool.
The product page is one part of your store's wider design. Apply the same keyboard, screen-reader, and touch tests to the homepage, collections, cart, checkout, and account pages.
Can you get sued if your Shopify store isn't accessible?
Yes, a product page can create legal exposure when it blocks disabled shoppers from goods or services covered by Title III. Federal law requires covered public accommodations to provide full and equal enjoyment of their goods and services. DOJ's web guidance says that duty reaches goods and services offered online.
DOJ guidance points covered private businesses to WCAG while allowing them to choose how they provide access. It doesn't prescribe a detailed Title III web standard.
I'd use WCAG as the technical testing target for these controls. Passing all seven checks documents the tested interactions, but legal compliance and complaint risk require a broader assessment.
Our guide to store-wide accessibility risk covers the broader exposure and fix order. This article gives only the legal context needed to explain why these seven high-priority controls need testing.
Product page accessibility checklist, mapped to WCAG
The Product Page Accessibility Audit gives each high-priority control a standard, test, fix, owner, and likely cost. Use this order:
- Product images and alt text: Describe information a shopper can't get from surrounding copy.
- Variant swatches and selectors: Expose each option's name, state, and visible boundary.
- Size-chart modal: Move focus into the dialog and return it after closing.
- Buy button focus state: Keep a clear keyboard focus indicator on the button.
- Price and availability updates: Keep focus on the variant while announcing each change.
- Quantity selector: Label every control and give each target enough space.
- Image gallery and zoom: Provide named keyboard controls for every image and zoom action.
The summary below is the audit sheet. The later sections explain each fix and test:
1. Product images and alt text
Give every informative product image alt text that communicates the detail a shopper would otherwise miss. Replace a filename, keyword string, or repeated title with the useful detail. Describe the back closure, fabric texture, dimensions, or included accessory when it affects the choice.
Shopify documents a free admin path inside each product's media editor. Open the product, select its media item, and choose Add alt text. Write a brief description focused on the image detail that adds to nearby copy. Shopify's product-media instructions recommend the same approach.
Decorative graphics should have empty alt text. If useful words are baked into an image, include them in the alternative.
After saving, move through the gallery with a screen reader and check that each description separates one image from the others. Treat performance as a separate task covered in our product image optimization guide.
2. Variant swatches and selectors
A variant selector must expose each option's name, current state, and visible boundary without relying on color alone. A row of colored circles can block the buying task. A screen reader may announce only "button," or a low-vision shopper may not see which circle is selected.
Native radio inputs with text labels work when the theme supports them. Custom buttons still need a name such as "Blue," an announced selected state, and a visible cue beyond color. Existing theme settings may make the fix free, while custom markup often needs a code or vendor update.
Before switching apps, test Tab, the arrow keys, Enter, and Space on the demo, then listen for each option's name and state. Change every option from the keyboard before testing the same group by touch.
At a 390-pixel viewport, confirm the swatches remain selectable, don't overlap, and leave room around nearby controls. The same test supports the touch-spacing priorities in our mobile UX guide.
3. Size-chart modal
A size-chart modal must take focus, contain it, close with Escape, and return focus to its trigger. A visual-only popup can leave keyboard and screen-reader users moving through the hidden page behind it.
The native HTML dialog element can work when it fits the theme and browser support. Another option is the W3C modal dialog pattern. Either version needs a visible title, a working close button, and modal focus behavior. The app vendor or theme developer may own the fix.
Failures often come from a size-chart app or custom Liquid snippet. A plain inline size table is safer when the popup can't return focus. Without a mouse, open the chart, confirm its title is announced, and move through every control in both directions. Close it with Escape, then confirm the next Tab press continues from the trigger.
4. Buy button focus state
Keep a visible keyboard focus indicator on the add-to-cart or buy button in every state. Custom CSS often removes the browser outline for visual polish, which makes the main purchase action disappear for someone navigating with Tab.
Shopify's theme guidance calls for visible keyboard focus styles. Restore the default outline or add a clear custom focus ring around the button itself. Use a contrast checker to record the ring against the adjacent colors on light and dark button states.
This is usually a free CSS fix, though a quick-buy or subscription-app vendor may control the styles.
Test the default, disabled, loading, and sold-out button states. Start above the product form and press Tab until the purchase button receives focus. Change a variant and repeat. The theme may render a new element and lose the ring that worked before.
5. Price and availability updates
Keep keyboard focus on the selected variant while announcing a changed price or stock message. A visual update alone leaves a screen reader on the old price or stock state.
Place the changing message in a status region that exists before the update. W3C's status-message technique explains how role="status" creates a polite live announcement. Keep one short message with the color, size, availability, and price. A theme and app can cause duplicate speech when both announce the change.
The theme's variant script or product-form app normally owns this change. Run a screen reader and change variants. Each update should be announced once, and the next keyboard action should remain on the selector.
6. Quantity selector
A quantity selector needs a clear name, keyboard operation, and touch targets that meet the minimum size or spacing rule. Familiar plus and minus icons still need to expose their action and current value to assistive technology.
Real increase and decrease buttons need accessible names, and the visible Quantity label must connect to the input. Under WCAG 2.2, pointer targets should generally be at least 24 by 24 CSS pixels.
A theme setting or CSS edit may be enough. Quantity-break, bundle, and cart apps need the same treatment.
If you rely on a spacing exception, measure the button box and gap to the next target with browser developer tools. Record the exception, then operate the minus button, input, and plus button by keyboard and touch at a 390-pixel viewport.
Keep the value at or above the store's allowed minimum. A screen reader should announce the current value, each changed value, and any error in words. Verify all three before accepting the control.
7. Image gallery and zoom
Every product image and zoom action must be reachable and operable without swipe, drag, hover, or a mouse. Galleries often expose thumbnails visually while leaving arrow controls unnamed or making drag gestures the only way to move between images.
Native buttons work for previous, next, thumbnail, and zoom actions when each has a specific name and visible focus. Use a contrast checker to test controls over light and dark photos. Expose the active slide or thumbnail and keep primary navigation visible at all times.
I'd reject a gallery that passes a scan but can't be completed with a keyboard. From the main image, reach and activate every control with Tab. Open and close zoom, then confirm focus returns to its trigger.
3D viewers and video players need their own checks. Test Tab, Enter or Space, the vendor's documented arrow keys, and fullscreen controls. Escalate any unnamed control, keyboard trap, or drag-only action to the vendor or an accessibility specialist.
Do accessibility overlay widgets fix any of this?
Manual keyboard and screen-reader tests determine whether all seven controls work. Overlays and scans supply only partial evidence. A widget may add font-size or contrast settings, while the product form still needs direct tests for unnamed swatches, broken modal focus, and silent price updates.
DOJ treats automated tools as supplements to manual checks. Use this decision order:
- Verify: Run all seven keyboard, touch, and screen-reader tests.
- Remove: I'd remove any widget that interferes with assistive tools.
- Escalate: Get specialist help for focus loss, traps, silence, or duplicate speech.
A short merchant-run check covers limited devices, browsers, tools, and disability-related needs, so get specialist help for unresolved custom behavior and legal advice for a complaint.
An added widget can also affect Shopify page speed. Run the same Lighthouse mobile test before and after installation. Compare the speed result and script requests before keeping the widget.
FAQ
Can I use this checklist before paying for an audit?
Yes, use the checklist to fix obvious product-page barriers before paying for an audit. Pay for a professional review when custom code, third-party apps, a complaint, or unresolved screen-reader behavior remains.
What if this checklist misses a problem?
Rerun the seven tests after every theme or app change, and keep a monitored footer contact so shoppers can report barriers these tests miss. For a failure, record the URL, input, expected result, and exact step, then send it to the vendor or an accessibility specialist.
