Three different Shopify themes. Three different developers. Three different theme store listings proudly wearing an "accessible" badge. We installed a plain product page on each one and ran the single interaction every ecommerce store lives or dies by through three checks: keyboard only navigation, a screen reader, and a plain look at the rendered markup.
All three failed the exact same button.
Not three unrelated bugs you could wave off as "well, that one theme is a niche pick." The same interaction, the add to cart button, broke in the same category of way across a free starter theme, a paid multi-purpose theme, and a theme built specifically for a niche vertical. If the one button that actually makes the store money does not work for a keyboard user or a screen reader user, the badge on the listing page was never worth much.
The Stat: WCAG's 4.1.2 Name, Role, Value requires every UI component to expose a programmatic name and role that assistive technology can read, the exact requirement a styled-div add-to-cart button usually violates. (Source: W3C WCAG 4.1.2)
What We Actually Tested
Nothing exotic. We installed each theme's default demo product page, added no custom apps and no extra scripts, and left every setting on its factory default. Then we ran the add to cart flow three ways: tabbing through the page with a keyboard only, listening to it with a screen reader, and opening the browser's element inspector to read the actual markup behind the visible button.
That third step mattered more than we expected going in. On all three themes, the visual button looked completely normal. Rounded corners, brand color, a hover state, the works. The problems only showed up once we stopped looking at the button and started listening to it, or trying to reach it without a mouse.
Failure Point 1: A Div Wearing a Button Costume
On every single theme, the add to cart control was built from a styled <div> (in one case a plain <span> wrapped in an onclick handler) rather than a native <button> element. Visually it is indistinguishable from a real button. Functionally, to a screen reader, it is often just text sitting on the page.
A native <button> element gets its accessible role, its keyboard focusability, and its "activatable with Enter or Space" behavior for free, straight from the browser. A div gets none of that automatically. Without an explicit role="button", a tabindex, and matching keyboard event handlers, it is invisible to anyone who cannot see the styling and has to rely on the underlying semantics instead.
On two of the three themes, the screen reader read the button's visible text as plain content, no "button" role announced at all, no indication it was interactive. On the third, tabbing reached it but pressing Space did nothing, only a mouse click fired the add to cart action. A sighted mouse user would never notice any of this. A keyboard user or screen reader user hits a wall on the exact step that generates revenue.
If your team is set on styling a div because a native button is harder to lay out in a particular grid, the ARIA Authoring Practices Guide button pattern is the correct reference for what has to be added back manually, role, tabindex, and both keyboard handlers, to make it behave like the real thing. It is more code than just using <button>, which is usually the faster and more durable fix.
Failure Point 2: The Focus Ring That Got Coded Away
All three themes suppressed the default focus outline somewhere in their base stylesheet, almost certainly as part of a broader "clean up default browser styling" reset, and none of them replaced it with a visible alternative on the add to cart button specifically.
Practically, this meant tabbing through the product page, the button did receive focus (the browser's internal state changed correctly), but there was no visual indicator showing where focus had landed. A keyboard user has no way to confirm they are about to activate the add to cart button versus the size selector next to it, or the wishlist icon above it. They are left pressing Enter and hoping.
This is a completely different failure from failure point 1. A theme can fix the div problem, switch to a real <button> element, and still fail this one if the CSS reset strips the outline globally and nothing restores it. We saw exactly that pattern on the paid multi-purpose theme in our set: correct semantic markup, invisible focus state.
Failure Point 3: A Quantity Stepper With No Name
The plus and minus controls next to the quantity field were built as small icon-only buttons on all three themes, a glyph with no visible text and, critically, no aria-label attached to either control.
A sighted mouse user reads the icons instantly. A screen reader user hears "button, button" with no way to tell which one increases the quantity and which one decreases it, forcing a guess-and-check cycle just to order two of an item. This is the same WCAG 4.1.2 requirement from the callout above, applied to a second control on the same interaction, a component needs an accessible name, and an icon alone does not provide one.
Why the "Accessible" Badge Doesn't Cover This
None of this means the badge was a lie exactly. Theme store accessibility claims tend to describe broader, more automatable things: color contrast ratios on default text, a sensible heading structure across the template files, alt text placeholders on image blocks. Those checks run cleanly through automated scanners and are genuinely worth having.
What they do not cover, in our experience across these three themes, is interaction level testing of a single custom-built control like an add to cart button or a quantity stepper. That kind of testing requires a human tabbing through the page and a human listening to a screen reader, not a scanner reading computed CSS. A theme can pass every automated contrast and structure check and still fail badly on the one component that converts a visitor into a sale.
This piece is intentionally narrow, one interaction, three themes, tested hard. If you want the wider picture across more failure categories and more themes, we covered that ground in 7 Shopify Themes That Fail WCAG Out of the Box. Read that one for breadth. Read this one for depth on the button that actually matters most.
How to Test Your Own Add-to-Cart Button
You do not need special software to catch most of this yourself. A short manual pass covers the failure points above:
- Tab to the button using only your keyboard, and confirm you can actually see where focus has landed.
- Press both Enter and Space once focused, and confirm the button activates either way. Native buttons support both. Div based fakes frequently only listen for a mouse click.
- Turn on a screen reader (VoiceOver on Mac, NVDA on Windows) and confirm it announces "button" along with the visible label, not just plain unlabeled text.
- Open the browser's element inspector and confirm the button is a real
<button>element or a semantic equivalent, not a div or span relying on a click handler alone. - Check the quantity increase and decrease controls individually, and confirm each one has its own accessible name, not just a plus or minus glyph.
For the formal definition of what "exposes a name, role, and value" actually means in spec terms, WCAG's own explainer is the clearest primary source: Understanding Success Criterion 4.1.2.
If you are evaluating a new theme, or you already shipped on one that fails this exact test, a proper teardown of the product page catches this before a customer complaint or a demand letter does. Our Shopify accessibility testing service runs this same interaction level check, keyboard, screen reader, and markup, against your actual storefront rather than a demo page.
Want a second opinion from someone who has already run this test three times over? Email experts@wcag.world and we will walk through what we found, theme by theme, button by button, and how it maps to your own store. Or start directly with our Shopify accessibility solutions page.