Shopify accessibility: common violations and how to fix them

Shopify powers roughly 10% of all ecommerce sites globally and a disproportionate share of ADA web accessibility lawsuits. The platform is not inherently inaccessible. But the combination of customizable themes, a sprawling app ecosystem and constrained checkout customization creates specific accessibility problems that affect most Shopify stores.

This post covers the issues that are specific to Shopify: not generic WCAG theory, but the actual failures that appear when you run an axe-core scan on a Shopify storefront and test its flows with a keyboard and screen reader. For the full list of WCAG criteria that apply to online stores, see our WCAG 2.1 AA ecommerce checklist.

Dawn theme accessibility: what works and what does not

Dawn is Shopify's official free theme and the base from which many premium themes are built. Shopify has made genuine accessibility improvements to Dawn over the years. But several persistent issues remain in the default configuration, and customizations frequently break what was working.

Heading hierarchy

Dawn's product page template uses an <h1> for the product title, which is correct. But the section heading structure below that point is frequently broken. Product description content entered through the Shopify rich text editor often contains headings (h2, h3) that merchants add for formatting. If the theme wraps those sections in additional heading elements, the hierarchy becomes inconsistent.

The collection page is worse. When merchants use the "Collection image with text overlay" section, the collection title is sometimes rendered as a <div> styled to look like a heading rather than an actual heading element. Screen reader users navigating by headings will miss it entirely.

Fix: audit your heading structure with a screen reader's heading list view (NVDA: Insert+F7, VoiceOver: VO+U then use arrow keys to select Headings). Every page should have exactly one h1 and a logical descending hierarchy below it. Our screen reader testing guide covers the full testing protocol.

Landmark regions

WCAG 2.4.1 requires a mechanism to skip repeated navigation. Dawn includes a skip link and uses semantic HTML5 landmark elements (<header>, <main>, <footer>, <nav>). This is correct.

The problem arises with customizations. When merchants add sections using Shopify's section-based architecture, those sections are often wrapped in generic <div> elements with no landmark role. A homepage with eight custom sections may have no landmarks below the main header, leaving screen reader users with no way to navigate the page structure efficiently.

Fix: in your theme's section Liquid templates, ensure content areas use semantic elements. The main content section should be inside <main>. Repeated navigation menus need <nav> with distinct aria-label values ("Main navigation", "Footer navigation") to differentiate them.

Focus management in the cart drawer

Dawn's cart drawer is a common source of keyboard trap violations. When a user adds a product and the cart drawer opens, focus does not always move into the drawer. The user must Tab through the entire page to reach the drawer content. When the drawer closes, focus sometimes drops to the document body rather than returning to the add-to-cart button that triggered the action.

The fix requires JavaScript changes to Dawn's cart-drawer.js. On drawer open: move focus to the drawer heading or the first interactive element inside it. On drawer close: return focus to the triggering element. The drawer itself must use role="dialog", aria-modal="true" and an aria-label.

Product variant selectors

Dawn renders size and color selectors as either native <select> elements or as custom button groups depending on theme settings. The native select is accessible by default. The custom button group (used for color swatches) has several issues in the default implementation:

• Color swatch buttons often have accessible names that only contain the color value ("Blue") without context ("Color: Blue"). When a screen reader user navigates a list of variant options, "Blue, Green, Red, Black" with no context is ambiguous.
• The currently selected variant is indicated visually by a border or checkmark but often lacks an aria-pressed="true" or aria-checked="true" attribute to communicate the selection state programmatically.
• Unavailable variant options shown as strikethrough visually must also communicate unavailability in code: aria-disabled="true" and preferably a visible text label.

Third-party app accessibility problems

This is where most Shopify stores accumulate their worst accessibility failures. The Shopify App Store has over 8,000 apps. The majority inject JavaScript and DOM elements into your storefront without accessibility testing. You are legally responsible for the accessibility of everything on your pages, regardless of what injected it.

Review widgets

Apps like Yotpo, Okendo, Stamped and Judge.me inject review sections on product pages. Common failures:

• Star rating displays use images or icon fonts without text alternatives. A screen reader announces nothing or announces an icon glyph name.
• Review sort and filter dropdowns are custom-built and often keyboard inaccessible.
• Paginated review lists load more reviews via AJAX without announcing the new content to screen reader users (missing live regions).
• The "Write a review" modal does not trap focus correctly and does not return focus to the trigger on close.
• Star rating inputs in the review form use radio buttons styled as stars. If the radio group is not correctly labeled with a <fieldset> and <legend>, screen reader users cannot determine what the stars represent.

Fix: raise accessibility bugs with your review app vendor. As a workaround, add accessible wrappers around injected content where possible. Switch to apps with documented accessibility commitments. Okendo publishes a VPAT (Voluntary Product Accessibility Template). Most review apps do not.

Upsell and cross-sell popups

Post-purchase upsell apps and in-cart recommendation widgets (ReConvert, Frequently Bought Together, Bold Upsell) inject modals and product recommendations throughout the purchase flow. Common failures:

• Upsell modals that appear after add-to-cart do not trap focus, allowing keyboard users to interact with content behind the overlay.
• Modals lack role="dialog" and aria-modal="true", meaning screen readers do not treat them as dialog contexts.
• No close button with a keyboard-accessible focus target, or the close button has no accessible name ("X" with no aria-label).
• Recommended product cards in the cart have "Add" buttons that lack context about what product is being added.

Live chat and support widgets

Intercom, Gorgias, Tidio and similar chat widgets are some of the most persistent sources of accessibility violations on Shopify stores. Specific problems:

• The chat launcher button is often an iframe or a custom element injected at the bottom of the page with no accessible name or keyboard focus handling.
• Some implementations render the chat button with tabindex="-1", making it completely unreachable by keyboard.
• The chat window, when opened, frequently fails to trap focus. A keyboard user can Tab out of the chat overlay and interact with the page behind it.
• Chat messages from support agents announced in the chat window are often not exposed via live regions, so screen reader users must manually navigate to the chat to see responses.

Gorgias has published accessibility documentation and made improvements. Intercom's accessibility has improved but is inconsistent across widget versions. Test your specific configuration rather than relying on vendor claims.

Cookie consent banners

OneTrust, Cookiebot, Pandectes and Consentmo are common on Shopify stores operating in the EU. Accessibility issues:

• Banners that appear on load and do not move focus to the banner leave keyboard users to discover them by accident.
• Cookie preference center modals often have poor keyboard navigation, particularly in accordion-based category lists.
• Some banners use low-contrast text on branded background colors that fail WCAG 1.4.3.

Shopify checkout accessibility

Shopify's checkout is rendered on the checkout.shopify.com domain (or a subdomain of your store). Until recently, most of its markup was outside merchant control. Checkout Extensibility changed this in 2024, but with significant constraints.

What Shopify controls

The base checkout form (contact, shipping address, shipping method, payment) is rendered by Shopify. Shopify has made improvements here: form inputs have associated labels, error messages are programmatically associated with fields using aria-describedby, and the multi-step flow manages focus between steps.

However, the base checkout is not perfect. In testing with NVDA and VoiceOver:

• The order summary section on the right panel (desktop) has heading levels that do not always integrate cleanly with the main checkout heading hierarchy.
• The gift card and discount code input section uses a toggle pattern that does not consistently announce its expanded state on all screen readers.
• Shipping rate selection uses a radio group that is correctly marked up but the rate descriptions (including estimated delivery dates) are not always fully associated with the radio button's accessible name.

Checkout Extensibility and its limits

Checkout Extensibility allows merchants to add UI extensions to the checkout using Shopify's checkout-ui-extension framework. These extensions render as sandboxed components within Shopify's checkout UI.

The accessibility responsibility here is split. Shopify controls the host checkout shell. Merchants control the extension components they build or install. Poorly built extensions can introduce the same problems as any other custom UI: missing labels, broken focus management, inaccessible custom inputs.

Apps that add post-purchase pages (surveys, loyalty enrollment, upsell offers) via Shopify's post-purchase extension point render on a page you do not fully control. Test these flows explicitly. Post-purchase pages are part of the transaction flow and have been included in ADA complaints.

Shop Pay and accelerated checkout buttons

Shop Pay, PayPal, Apple Pay and Google Pay buttons appear on product pages and in the cart. These are rendered by Shopify and the payment providers. They are generally accessible (they use <button> elements with accessible names) but their positioning in the page's Tab order can create confusion when they appear above the standard add-to-cart button in the visual layout but below it in the DOM order.

Shopify's built-in accessibility features

Shopify has invested in accessibility in recent years. Features that help:

• Theme Store accessibility requirements. Since 2021, themes submitted to the Shopify Theme Store must pass a set of automated accessibility checks. This raises the baseline for commercially available themes.
• Dawn's skip link. Dawn includes a skip navigation link as its first focusable element. Many premium themes based on Dawn preserve this.
• Checkout form labels. The hosted checkout has properly associated labels on all core form inputs.
• Storefront API semantic HTML. Liquid templates encourage semantic HTML usage and Shopify's own Liquid objects generally render semantic elements.

Shopify's gaps:

• No built-in accessibility scanning or reporting for merchants. You have to find and fix violations yourself or hire someone to find them.
• App review process does not include accessibility checks. Inaccessible apps pass review and reach thousands of stores.
• Theme customizer (dragging sections, adding blocks) makes it easy to break heading hierarchy and landmark structure without any warning.
• Metafield-based product content (used for custom product attributes) is often rendered without semantic structure.

How to audit your Shopify store

Automated scanning first. Run axe-core or similar accessibility testing tools on your product page, collection page, cart and as far into checkout as you can reach. Automated tools find color contrast failures, missing alt text, missing form labels and parsing errors quickly. On a typical Shopify store with a few apps installed, expect 20-60 violations on the product page alone.

Keyboard testing second. Disconnect your mouse. Tab through the entire checkout flow: product page, add to cart, cart, checkout contact, shipping, payment, confirmation. If you get stuck, lose track of focus or cannot complete an action, that is a violation.

Screen reader testing third. Use VoiceOver on macOS (Command+F5) or NVDA on Windows (free download) with Chrome. Navigate the product page by headings, then by landmarks. Complete a checkout flow listening only to what the screen reader announces.

Prioritize by flow. Checkout failures are highest risk: both legally (they directly prevent purchase completion) and commercially (they cost you revenue). Fix checkout first. Then product pages. Then collection pages and search. Post-purchase flows like returns also carry legal risk: our guide on returns flow accessibility covers the specific failures that appear in those pages. Blog and static content pages carry the lowest risk. If you are considering moving to a different platform, our replatforming compliance checklist covers what to validate during migration.

What you can fix without a developer

• Add alt text to product images in the Shopify admin. The alt text field is directly on the media upload screen.
• Fix low-contrast text in theme settings. Most themes expose text color and background color settings in the theme customizer. Check combinations with a contrast checker tool.
• Review the heading structure of your homepage sections. In Dawn, section headings are typically set in the section settings. Ensure no section creates an h1 when one already exists on the page.
• Add an accessibility statement page linked in your footer. It does not fix violations but demonstrates good faith and is required for EAA compliance.

What requires a developer

• Focus management in cart drawer open and close cycles.
• ARIA attributes on custom variant selectors (aria-pressed, aria-checked, aria-disabled).
• Live region announcements for add-to-cart confirmations and search result count updates.
• Keyboard accessibility for any custom JavaScript component: custom dropdowns, accordions, tabs, modals.
• Fixing accessibility bugs introduced by third-party app scripts, either by editing app CSS or JS where permitted or by wrapping injected elements.

Frequently asked questions

Is Shopify accessible out of the box?

Shopify's Dawn theme includes basic accessibility features like skip links and semantic HTML. However, most Shopify stores fail WCAG 2.1 AA due to theme customizations, third-party app injections and broken heading hierarchies. The platform provides a foundation but not full compliance.

Do Shopify apps cause accessibility violations?

Yes. The majority of Shopify's 8,000+ apps inject JavaScript and DOM elements without accessibility testing. Review widgets, upsell popups, chat tools and cookie banners are the most common sources of violations. Store owners are legally responsible for all content on their pages regardless of what injected it.

Is Shopify checkout accessible?

Shopify's hosted checkout meets many WCAG 2.1 AA criteria for core form inputs and labels. However, checkout extensions, third-party apps and post-purchase flows frequently introduce accessibility failures. Headless Shopify checkouts require full accessibility implementation from scratch.

How do I fix Shopify accessibility issues without a developer?

You can add alt text to product images in the Shopify admin, fix low-contrast text in theme settings, review heading structure in section settings and add an accessibility statement page. Focus management, ARIA attributes and third-party app fixes require developer support.