Shopify checkout accessibility in 2026: what you can and can't fix

When an audit lists checkout findings, the first question is who owns the code. Since Shopify retired checkout.liquid, the answer is almost never "the theme". This guide explains what changed, what each plan can touch, and how we handle checkout items in a fix list so nobody is promised a fix that isn't possible.

What changed: checkout.liquid is gone

For years, Shopify Plus stores could edit checkout templates directly through checkout.liquid. That ended in two stages:

• Information, shipping and payment steps: checkout.liquid stopped working on August 13, 2024 (Shopify changelog).
• Thank you and order status pages: checkout.liquid and additional scripts were sunset on August 28, 2025 (shopify.dev). For non-Plus stores, script tags on those pages are sunset on August 26, 2026 (Help Center).

Checkout is now customized through checkout extensibility: the checkout editor, branding settings, and app extensions. None of these lets a theme developer edit checkout HTML.

What each plan can change

From Shopify's plan comparison (Help Center) and the checkout UI extensions docs:

So on a Basic, Grow or Advanced store, the checkout's markup belongs to Shopify. On Plus, the markup still belongs to Shopify, but the store can add its own extension components to the main steps, and those components are the store's code.

Shopify's own conformance report

Shopify publishes an Accessibility Conformance Report for its checkout, based on the VPAT 2.5 format and covering WCAG 2.0, 2.1 and 2.2 at levels A and AA. The current report is dated March 2026 and says remediation is ongoing. It marks a number of success criteria as "Partially Supports". Among them:

• contrast (1.4.3)
• focus order (2.4.3)
• focus visible (2.4.7)
• on input (3.2.2)
• name, role, value (4.1.2), with examples involving the PayPal, Venmo and Amazon Pay controls
• status messages (4.1.3)

Read it before you quote any checkout finding. If an auditor reports something Shopify already lists, the honest note in the change log is "known platform issue, listed in Shopify's conformance report", not a fix. The report gives accessibility@shopify.com as the contact.

What you can fix on every plan

1. Branding that breaks contrast

The checkout editor lets the merchant pick colors for buttons, backgrounds, form fields and accents. A brand palette that works on the storefront can fail inside checkout. Watch for:

• button text on a light brand color (1.4.3 Contrast (Minimum): 4.5:1 for normal text);
• input borders and the focus ring against the form background (1.4.11 Non-text Contrast: 3:1);
• accent colors used for links and error text.

These are settings, not code, and they're fixable on any paid plan. Test the checkout preview with a contrast checker after every brand change. If a finding is caused by the merchant's color choice, it belongs in the fix list. If it persists with high-contrast colors, it's Shopify's.

2. Everything before checkout

Many findings filed under "checkout" are really in the path to it:

• the cart page and cart drawer (focus, labels, quantity controls, remove buttons, the "added to cart" announcement);
• the product form (variant pickers, quantity, error messages when no size is chosen);
• discount code fields and shipping estimators on the cart page;
• the Check out button itself, when the theme renders it.

All of that is theme code and fixable. Our cart drawer guide and swatches guide cover the two most common ones.

Dynamic checkout buttons are a gray zone. The theme decides where they appear (through Liquid's payment_button filter), but Shopify and the payment providers render the buttons themselves. You can fix the surrounding layout, spacing and headings. You can't fix the wallet buttons' internals.

3. Thank you and order status page apps

Apps on these pages are available on all plans except Starter. If an app placed there causes a finding, the options are the same as for any app: its settings, a different app, or a ticket to the vendor. If the agency built a custom extension for these pages, that extension is its code and can be fixed.

What changes on Shopify Plus

On Plus, a store can add checkout UI extensions to the information, shipping and payment steps: a gift message field, a delivery date picker, a loyalty banner, an upsell. Those extensions are built from Shopify's UI components. Shopify says its web components have accessibility built in: semantic HTML, keyboard support, ARIA attributes, focus management and color contrast (Polaris web components). The developer still has to:

• give every field a label and every validation problem an error message;
• use a sensible heading structure within the extension;
• keep custom content (images, banners) accessible, with alt text and readable contrast;
• test the extension with a keyboard and a screen reader inside the real checkout.

So on Plus, findings inside a custom extension are in scope, the same way theme code is. Findings in Shopify's own checkout components still go to Shopify.

How we handle checkout findings in a fix list

When an audit includes checkout items, we sort each one before quoting:

1. Where is it really? Reproduce it. If it's on the cart page, in the cart drawer or on the product form, it's theme code: in scope.
2. Is it caused by branding? Try it with the checkout preview set to high-contrast colors. If the problem goes away, the fix is a settings change: in scope on any plan.
3. Is it inside an extension or app? A custom extension is in scope on Plus. A third-party app goes to the vendor.
4. Is it in Shopify's own checkout? Check the conformance report. Either way it's out of scope for a theme fix list. We write it up with steps to reproduce so the merchant or agency can report it to Shopify, and the change log marks it "reported to platform", not "fixed".

This is why our scope lists "Checkout on non-Plus Shopify stores (Shopify-owned code)" as an exclusion. It isn't a way to dodge work. It's the only honest answer.

What to tell the client

A short version that's accurate and not legal advice:

Shopify hosts and maintains the checkout on every plan. We can adjust the checkout's branding, and we can fix the cart and product pages that lead into it. Problems inside Shopify's own checkout components have to be fixed by Shopify. We've documented them with steps to reproduce so they can be reported. Shopify publishes a conformance report for its checkout and says remediation is ongoing.

If the client's question is about legal risk, that's one for their lawyer. A fix list maps changes to WCAG success criteria. It isn't a statement of legal compliance.

Sources

• Shopify Help Center, Checkout extensibility, Customize checkout configurations and Checkout upgrade
• Shopify.dev, checkout.liquid and the August 13, 2024 changelog
• Shopify.dev, Checkout UI extensions and checkout technologies by plan
• Shopify.dev, Using Polaris web components
• Shopify, Accessibility Conformance Report: Shopify Checkout (WCAG edition), March 2026
• Shopify.dev, payment_button filter
• W3C WAI, Understanding WCAG 2.2: 1.4.3, 1.4.11

---

Checkout items in a client's audit? We sort what's fixable from what's Shopify's before quoting. Send us one client's audit findings. We review the findings and the code, then quote a fixed price for an agreed list of fixes. Your team retests. If the agreed fixes fail your retest, you don't pay for them. Send findings.