How to Fix Accessibility Issues on Shopify
Shopify stores are built fast, and that speed has a cost. Themes ship with missing image descriptions, checkout forms that screen readers can't parse, and product dropdowns assembled from <div> tags that a keyboard can never reach. None of this is unusual — it's just how templated e-commerce works when accessibility isn't the priority.
The good news is that a meaningful share of these gaps are fixable without a developer, and the rest require only targeted code changes, not a rebuild. This article walks through the most common issues, how to find them, and exactly what to do on Shopify.
The usual accessibility gaps on Shopify
Product images with no description
Every product image on your store needs a text alternative that tells a screen reader what the image shows. This is WCAG success criterion 1.1.1 (Non-text Content). When it's missing, a screen reader announces something like "image_3847f.jpg" — or nothing at all. That's not just an accessibility problem; it also removes indexable content from your product pages.
The gap is widespread on Shopify because images can be uploaded without ever filling in an alt text field, and most themes don't enforce it.
Unlabelled form fields
Your newsletter signup, search bar, contact form, and any fields you've added via apps all need visible labels that are programmatically associated with their inputs. WCAG 4.1.2 (Name, Role, Value) requires that every user-interface component has a name a screen reader can announce. When a field says "Email" only via placeholder text inside the box, that placeholder disappears the moment someone starts typing — leaving them no way to check what they're filling in.
Shopify's native checkout has improved here, but third-party apps and theme-added forms frequently ship without proper <label> elements.
Custom interactive elements that aren't keyboard-reachable
This is where Shopify stores tend to fail silently. Colour swatches, size selectors, quantity steppers, and mobile menus are often built from <div> and <span> elements styled to look like buttons and dropdowns. Those elements are invisible to keyboards and screen readers unless extra ARIA attributes are added — and they usually aren't.
A customer navigating by keyboard (common for people with motor impairments, and for anyone who just prefers keyboard navigation) can reach your product page but not select a variant or add an item to the cart. That's a direct revenue loss, not an abstract compliance issue. It also falls under WCAG 4.1.2.
Icon-only buttons with no accessible name
Cart icons, search icons, wishlist buttons, and social share links frequently have no text. Visually, a shopping-bag icon is unambiguous. To a screen reader, a button with no label is announced as "button" — or the button's raw file name. Customers using screen readers have to guess what it does. This also breaks WCAG 4.1.2.
Focus indicators removed by the theme
When you navigate with a keyboard, a visible outline tracks where you are on the page. Many Shopify themes remove this outline in their CSS — it's considered visually untidy — without adding a replacement. This makes keyboard navigation functionally impossible for sighted users who rely on it. It also affects WCAG 1.4.3's broader intent around visual presentation, and it will be caught as a failure under WCAG 2.4.7 (Focus Visible).
---
How to find them
Start with a free automated scan. Tools like WAVE or the axe browser extension (available for Chrome and Firefox) will surface missing alt text, unlabelled inputs, and some ARIA errors in seconds. Run it on your homepage, a product page, a collection page, and your checkout. These tools catch roughly 30–40% of real WCAG issues — that figure is worth repeating, because automated passes are often treated as green lights when they aren't.
Do a keyboard-only walkthrough. Unplug your mouse and try to browse your store using only Tab, Shift+Tab, Enter, and arrow keys. Can you open the navigation menu? Select a product size? Add it to the cart? Complete a purchase? If you get stuck, you've found a gap.
Check your images in the admin. Go to Products in your Shopify admin, open a few products, and look at whether the alt text field under each image is filled in. Blank fields are 1.1.1 failures waiting to be fixed.
Inspect form labels in your browser. Right-click any form field and choose Inspect. Look at the HTML. If there's a <label> element that has a for attribute matching the input's id, the label is properly associated. If you see only a placeholder or a <div> styled as a label, it isn't.
---
How to fix each
Fixing missing alt text on product images
In the Shopify admin:
- Go to Products → select a product.
- Click on a product image.
- In the panel that appears, fill in the Alt text field. Describe what the image shows: "Dark blue merino wool crew-neck sweater, front view" is useful. "Sweater" is not. "IMG_4829" is worse than nothing.
- Save.
Do the same for collection images: Products → Collections → select a collection → click the collection image.
For images added through the Files section or theme banners, you'll need to edit the alt text in the theme customiser or directly in the theme's Liquid files, depending on how your theme handles them.
For purely decorative images (dividers, background textures, flourishes), you want an *empty* alt attribute — alt="" — so screen readers skip them. You set this in the Liquid template, not the admin.
Fixing unlabelled form fields
Newsletter popup / footer signup (theme customiser): Most themes expose a label field for the newsletter input in the theme customiser (Online Store → Themes → Customise). Look in the section settings for the footer or popup. If there's a "Label" field, fill it in. If the field exists only as a placeholder, you'll need to edit the theme code.
In the Liquid code:
Find the template file for the form (typically sections/footer.liquid or a popup section). Confirm that the input has a matching <label>:
``html <label for="newsletter-email">Email address</label> <input type="email" id="newsletter-email" name="contact[email]" placeholder="you@example.com"> ``
The for attribute on the label must match the id on the input exactly. If there's no <label> at all, add one. If there's only a placeholder, add a visible label (or a visually hidden one using a .visually-hidden CSS class if your design requires it).
Fixing icon-only buttons
In your theme's Liquid files, find the cart and search button markup. They typically look something like:
``html <button class="cart-icon">{% render 'icon-cart' %}</button> ``
Add an aria-label attribute:
``html <button class="cart-icon" aria-label="Open cart">{% render 'icon-cart' %}</button> ``
For social share links, add descriptive link text that's hidden visually if needed:
``html <a href="..." aria-label="Share on Instagram">{% render 'icon-instagram' %}</a> ``
Fixing custom variant selectors and dropdowns
If your theme uses <div>-based colour swatches or size buttons instead of a native <select>, the fastest reliable fix is to replace them with native elements. A native <select> is keyboard-accessible, announced correctly by screen readers, and requires no ARIA at all.
If the design genuinely requires a custom widget (styled swatches, for example), each option needs role="radio" or role="option", a matching aria-label, and keyboard event handling so arrow keys cycle through options. This is a code task, but it's a contained one — a developer familiar with ARIA patterns can typically do it in a few hours per component.
Restoring focus indicators
In your theme's CSS, search for outline: none or outline: 0. These declarations strip the focus ring. Remove them, or replace with a deliberate visible style:
``css :focus-visible { outline: 3px solid #005FCC; outline-offset: 2px; } ``
Using :focus-visible rather than :focus means the outline only appears for keyboard navigation, not mouse clicks — so it won't affect your visual design for most users.
---
What still needs a human
Automated scanners and the fixes above will close a real share of your store's gaps. But several important issues can't be caught by a script:
Meaningful alt text versus present alt text. A scanner confirms an alt attribute exists. It can't tell you whether "product image" is meaningful or whether the description matches what's actually shown. Only a human can judge whether someone who can't see the image gets enough from the text.
Reading order. Screen readers announce content in DOM order, which may not match the visual layout, particularly with CSS Grid and Flexbox. A scanner won't flag this. A five-minute screen-reader walkthrough will.
Error messages tied to the right field. When a checkout form rejects an entry, the error message needs to be programmatically associated with the field that caused it (WCAG 4.1.2). A scanner may miss this if it doesn't trigger a real validation error during its crawl.
Keyboard traps in custom menus and modals. A scanner can flag the absence of ARIA, but can't always detect whether focus gets stuck inside a component or escapes somewhere unexpected during real keyboard navigation.
Video and audio content. If your product pages include video demonstrations, those need captions for deaf customers and audio description for blind customers. A scanner won't watch the video and evaluate caption accuracy.
This is why we offer the Accessibility Snapshot: an automated WCAG scan combined with a short human review of your most important pages, delivered as a plain-English report. It tells you what a scanner found, what a human spotted on top of that, and — concretely — which issues carry the most risk and the most effort to fix. No obligation, no sales call. If you'd like one for your Shopify store, the link below takes about 30 seconds to fill in.