Shopify theme accessibility: how to check and improve your theme

By AbleAisle. Updated 28 October 2026.

Your theme decides how almost every page of your Shopify store looks and behaves: the header and menu, buttons, forms, product pages and colours. That makes it a major factor in whether your store works for people who use a keyboard, a screen reader or zoom.

This guide explains how to check your theme, what you can fix yourself in the theme editor, and what to hand to a developer. It uses WCAG 2.1 Level AA as the yardstick, with a few notes on the newer WCAG 2.2 additions.

Start with the right expectations

A theme is not "accessible" or "inaccessible" as a whole. Shopify's free themes are a sensible starting point, but your store is more than the theme: your colours, images, content, apps and any code you added all change the result. Check your own store as it is today rather than relying on a theme's description. The checkout is largely managed by Shopify, so most theme changes don't touch it, but test the whole customer path as far as you can.

Step 1: Test a copy, not your live theme

In the Shopify admin go to Online Store > Themes, find your current theme, open the ... menu and choose Duplicate. Do your experiments on the copy and preview it before you publish.

Step 2: Run the keyboard test

Keyboard problems are among the most serious theme issues, and you can find them in minutes with no tools. Put your mouse aside and use only the keyboard: Tab to move forward, Shift + Tab to go back, Enter to activate links and buttons, Space for checkboxes, Esc to close things.

Work through these questions on the home page, a collection page, a product page and the cart:

• Can you always see where you are? A visible focus indicator on every link, button and field is required by WCAG 2.4.7 Focus Visible. A common theme problem is custom CSS that removes the outline with outline: none and puts nothing in its place.
• Can you reach and use everything? The menu and its sub-menus, the search, the cart drawer, product options, quantity fields and the "Add to cart" button must all work without a mouse, as WCAG 2.1.1 Keyboard requires.
• Can you get out again? Pop-ups, drawers and newsletter modals should close with Esc or a close button you can reach, and must not trap you (2.1.2 No Keyboard Trap).
• Does the order make sense? Focus should follow the order you'd read the page.
• Is there a way to skip the menu? A "Skip to content" link as the first focusable item helps keyboard users avoid tabbing through the whole header on every page (2.4.1 Bypass Blocks).
• Is anything hidden behind a sticky header or cookie banner? WCAG 2.2 adds 2.4.11 Focus Not Obscured (Minimum), which asks that the focused item isn't completely covered.

Step 3: Check colour and text

In the theme editor (Online Store > Themes > Customize), colours are usually grouped into colour schemes under Theme settings. Normal text needs a contrast ratio of at least 4.5:1 and large text 3:1 (1.4.3 Contrast (Minimum)). Buttons' borders and form field outlines need 3:1 against their surroundings.

Fix a colour scheme once and every section that uses it improves. Then look separately at text placed over images, sale and sold-out badges, announcement bars and placeholder text, which often sit outside the main scheme. Our colour contrast guide walks through where these hide and how to check them.

Also try your store at 200% browser zoom, and on a phone-sized window. Text should resize and the page should reflow without you needing to scroll sideways to read a line (1.4.4 Resize Text and 1.4.10 Reflow). For tap targets, WCAG 2.2 adds 2.5.8 Target Size (Minimum), which asks for targets of at least 24 by 24 CSS pixels, with some exceptions.

Step 4: Check structure and headings

Screen reader users often move around a page by its headings and landmarks, so structure matters (1.3.1 Info and Relationships).

• One main heading per page. A product page's product name is normally the h1. Section titles under it should be h2, with h3 below that, without skipping levels just to get a certain font size.
• Headings describe their section, and aren't used just to make text bigger.
• Landmarks exist. A well-built page has a header, a navigation, a single main area and a footer. If you edit theme code, keep them.
• The page has a language and a title. The html tag should declare the language, usually with lang="{{ request.locale.iso_code }}" in theme.liquid (3.1.1 Language of Page), and each page needs a descriptive title (2.4.2 Page Titled).

Step 5: Check forms, buttons and links

Forms in a theme include the newsletter sign-up, search, contact form, login and account pages, and the cart's note field.

• Every field has a visible label that is connected to it, not just placeholder text that disappears when you type (3.3.2 Labels or Instructions).
• Icon-only buttons have a name. A cart icon, a search magnifier or a close "X" needs text a screen reader can announce, such as a visually hidden label (4.1.2 Name, Role, Value).
• Error messages are clear. Say what went wrong and how to fix it, in text, not by colour alone.
• Links make sense. "Click here" and repeated "Read more" links don't tell people where they lead. Make the link text describe the destination.

Step 6: Check images in your theme

Product images normally use the alt text you set in the admin, so write that first (see our alt text guide and the guide to accessible product images). In theme code, check that images output their alt value, for example with {{ image.alt | escape }} or the image_tag filter, and that decorative images use an empty alt="" on purpose. Edit code from Themes > ... > Edit code on your duplicated theme, and ask a developer if you're unsure.

Step 7: Check your apps

Apps can add pop-ups, chat widgets, reviews and sticky bars, which are frequent sources of keyboard traps and low-contrast text. If you find a problem, see whether it disappears when the app is switched off under App embeds in the theme editor, then contact the app's developer.

Where an automated check fits

Free tools such as the axe browser extension, WAVE and Chrome's Lighthouse accessibility audit scan a page in seconds and flag missing alt text, low contrast, missing labels and unnamed buttons. They are a useful first pass, but they only catch part of the issues. They can't tell you whether alt text is accurate, whether the focus order makes sense or whether a menu works with a screen reader, so keep the manual steps above. The W3C list of evaluation tools helps you compare options, and our guide to what an automated audit can and can't find goes into more detail.

AbleAisle's free Quick check runs automated checks on your home page in about a minute, without a sign-up, as a starting point. It does not replace testing by hand.

Frequently asked questions

Is my Shopify theme accessible?

You can't tell from a theme's name. Test your own store with the keyboard, zoom and an automated scan, then fix what you find.

Should I switch themes to improve accessibility?

Not necessarily. Many issues come from content, colours and apps and can be fixed in your current theme. For deep structural problems, such as a menu that can't be used with a keyboard, a developer can tell you whether a fix or a switch is less work.

Can I fix theme issues without code?

Many, yes: colour schemes, overlay strength, alt text and section headings are editable in the admin. Focus styles, landmarks and form markup usually need a small code change.

How often should I re-check?

After any theme update, new app or redesign.