You don't have to choose between Shopify updates and accessibility fixes

A while back, a developer told me something that stuck with me. He said fixing Shopify Liquid files is a hassle, because customizations don’t scale with theme updates. The moment you start editing a theme, you’ve effectively forked it, and every future update has to be diffed and re-applied by hand.

He’s not wrong. That’s effectively how maintaining a customized Shopify theme works.

It’s also why many teams avoid deep changes to a live theme, accessibility remediation included.

Accessibility fixes often require changes that only exist in Liquid templates: adding semantic HTML, correcting heading hierarchy, exposing labels to assistive technology, or fixing landmark structure. Those aren’t changes you can reliably layer on afterward with CSS or JavaScript.

But “that’s just how Shopify works” is where the conversation usually stops. I don’t think it should stop there. The fork isn’t a Shopify problem. It’s a process problem. And process problems have process answers.

Solving the update problem comes down to two ideas: isolate changes so most of them never collide with an update, and keep a clean, greppable record of the changes that can’t be isolated so the manual diff stays small and predictable.

The core problem

Two facts about Shopify themes create the pain:

• Custom edits don’t carry through theme updates. When Shopify ships a new version of the base theme, it doesn’t merge your changes in. You get the new version, and reconciling your customizations is on you.
• A GitHub-connected theme stops receiving Shopify’s theme updates. Once a theme is connected to GitHub, Shopify’s built-in “Update available” workflow no longer applies to that theme. If you want upstream theme updates, you need to bring them into your Git workflow yourself.

So you want two things at once: version control and the ability to take upstream updates. Do you have to choose one? No. You keep them in separate places on purpose. That’s the core idea, and everything below is just the mechanics of it.

Setup, before any remediation starts

This groundwork is what makes the update painless later. Do it first.

Isolate CSS and JavaScript into custom files

Any styling or scripting change goes into its own custom asset files instead of being edited into the theme’s existing files. These almost never conflict with an update. Because these are new assets rather than modifications to the theme’s files, upstream theme updates rarely touch them, so Git treats them as independent additions rather than conflicting edits. The one exception is the line that loads them: the stylesheet_tag or script_tag that enqueues these custom assets lives in Liquid, usually in theme.liquid, so that single hookup is a Liquid edit an update can collide with. Tag it with your A11Y-REMEDIATION marker like any other Liquid change. With that one line accounted for, most of your work is gone from the diff before the diff even starts.

Tag every Liquid change and keep a list

Liquid is the part you can’t fully isolate. Sometimes you have to edit a section or snippet directly. For every one of those edits, leave a clear comment describing what changed, and maintain a running list of every Liquid file you touched.

One refinement pays off later. Use a consistent, greppable marker in those comments:

{% comment %} A11Y-REMEDIATION: added aria-label + visible focus state to search toggle {% endcomment %}

Enter fullscreen mode Exit fullscreen mode

Now your “list of changed Liquid files” isn’t something you maintain by hand and hope is complete. It’s one command:

grep -rl "A11Y-REMEDIATION" .

Enter fullscreen mode Exit fullscreen mode

Designate an unconnected copy of the live theme to receive updates

Before you start, duplicate the live theme and leave that copy disconnected from GitHub. Because it isn’t connected, it stays eligible for Shopify’s updates. This copy is your update pipeline. The connected repo is your source of truth. Keeping them apart is the point.

The update workflow

When Shopify releases a new version of the base theme, this is how you take it without losing remediation work.

Phase 1: bring the update into version control

1. Update the theme copy in the Shopify admin. Shopify generates a new Updated Copy of the theme with the new version applied.
2. Create a backup branch from the connected repo’s main. If anything goes sideways, you have a clean restore point.
3. Create an update branch and pull the code from the Updated Copy into it, not from the live theme. This gets the upstream changes into Git where you can actually diff them.

Phase 2: reconcile, with a focus on every Liquid change

1. Merge update into dev using --no-commit (git merge --no-commit --no-ff update). This leaves the merge staged but uncommitted, giving you a chance to inspect both conflicting and automatically merged changes before creating the merge commit. The --no-ff flag forces an actual merge commit so you always land in that reviewable staged state, even when Git could have fast-forwarded.
2. Diff every Liquid file you modified during remediation, file by file. This is the one deliberately manual step, and it’s where your tagged comments and file list earn their keep. You know exactly which files to check, so you’re reviewing a short list, not the whole theme. Keep, adapt, or discard each incoming change so accessibility fixes are preserved without missing legitimate improvements in the updated theme.
3. Commit to dev once the diff is clean, then merge dev into main.

Phase 3: push back to Shopify, in the right order

1. Push main to the Updated Copy, not to Live yet. Order matters here, to avoid schema errors: push the configuration files first, config/settings_schema.json and config/settings_data.json, then push the remaining theme files. Pushing the config first means that if there’s a schema problem, the sync fails here, before the rest of the theme is touched, so you fix the JSON discrepancy and retry instead of discovering the problem after everything else has synced.
2. Verify the Updated Copy on Shopify before publishing. Alongside the usual schema and functional checks, re-run your accessibility checks here: an upstream update can change base-theme files you never touched and quietly regress accessibility along the way, so confirm the copy still holds up before it goes live. Only then publish it as the Live theme.

Why this holds up

Notice what each piece is doing. The unconnected copy keeps you eligible for updates. Version control keeps your work reviewable and reversible. Isolated CSS and JavaScript mean most of your changes never enter the diff at all. Tagged Liquid comments turn the unavoidable manual step into a bounded, predictable one. The config-first push order fails loudly and early instead of quietly and late.

None of this makes Shopify merge your changes. That was never on the table. What it does is shrink the manual work to the smallest surface possible and make every risky step recoverable.

The theme stays maintainable. Updates stay boring. “We customized it” stops meaning “we’re stuck on this version forever.”

That developer’s complaint was fair. It just wasn’t the end of the story. Shopify sets the constraint. A disciplined workflow keeps it manageable.