How to fix accessibility issues without breaking your theme

Never fix on the live theme. Make a copy (a duplicate theme on Shopify, a staging site or at least a full backup on WordPress), make one group of changes at a time on the copy, have someone review them, test the copy with the same checks that found the problems plus a quick look at the pages that make money, and only then publish. Keep code changes somewhere a theme update cannot overwrite them, and retest after every update.

Accessibility fixes are usually small: a missing label, a button with no name, a colour a shade too light. The risk is not the fix itself but where it is made. An edit in the live theme's code shows to every customer at once, and an edit to a parent theme can vanish at the next update.

Step 1: Make a copy you can throw away

Shopify

In Shopify admin, go to Online Store, open the menu next to the theme and choose Duplicate. Shopify suggests exactly this before customising, so you can discard changes and start again; the copy appears as "Copy of" plus the theme name.¹ You can hold up to 20 themes, and deleting one is permanent, so download a theme before deleting it if you might need it.¹

Preview the copy from the theme library. The preview bar shows the theme name and a Draft status, and you can copy a preview link to share; a link without sign-in works for anyone with the URL and expires after two days.² That is how a colleague or developer reviews your fix before it goes live.

WordPress and WooCommerce

Back up first, and back up both halves. The WordPress handbook says a full restore needs the database and the files, that downloading the WordPress folder does not back up the database, and that you should always back up before an upgrade.⁵ If your host offers a staging copy of the site, make your changes there.

Step 2: Put changes where updates will not erase them

• WordPress classic themes: use a child theme. WordPress's theme handbook explains that a child theme keeps customisations separate from the parent, so parent updates do not erase them, and warns that functions added straight into the parent theme will disappear at its next update.⁶
• WordPress block themes: changes made in the Site Editor are stored in the database. CSS added in Styles survives a theme update but is cleared if you switch themes, so keep a copy of it.⁷
• Shopify: keep a written list of every code change you make, or keep the theme in version control, so you can reapply your fixes if you move to a newer version of the theme. Shopify's developer documentation also describes a Lighthouse CI GitHub action for catching accessibility regressions in a theme repository.⁴

Step 3: Fix in small, named batches

Group fixes by where they live, not by WCAG number:

Start with content and settings. They are low risk and quick. Make each code change separately so that if something breaks, you know which change did it.

Step 4: Avoid the fixes that cause new problems

• Do not remove focus outlines because they look untidy after a design change. Styling an outline so it disappears is a listed failure of 2.4.7 Focus Visible. If you want a different look, use :focus-visible with a clear replacement.¹⁰
• Do not add ARIA to cover a wrong element. A div with a click handler needs to become a button, not gain a role and leave keyboard handling missing.
• Do not hide content with display: none when you meant to hide it only visually. W3C notes that it hides content from screen readers too; use a visually hidden class instead.¹¹
• Do not install an overlay to "fix everything at once." It changes nothing in your theme; see do accessibility widgets make a website compliant?
• Turn off what you no longer use. Old app embeds on Shopify can be switched off in the theme editor under App embeds, then checked in preview.³

Step 5: Review before publishing

Have a second person look at each change, ideally someone who did not write it. For code, that means a pull request or at least a diff; for settings, a shared preview link. The review asks three questions: does the fix solve the problem the check found, does the page still look and work the same for everyone else, and has anything else changed by accident?

If you use Website Mechanic, Jralo's AI agent fixes the problems a check found and sends the changes back for review, as a GitHub pull request or, for WordPress, as a fixed theme. Nothing is merged or published until you decide.

Step 6: Retest the copy, then the live site

1. Run the same automated check that found the problems, on the preview or staging copy where you can, and compare the counts.
2. Do a keyboard pass through the menu, a product page, the cart and any pop-up you changed. W3C's quick checks cover reaching everything, getting out of everything, a sensible order and visible focus.⁹ Our ten-minute keyboard test walks through it.
3. Click through a purchase by mouse and on a phone, up to the payment step, to make sure nothing that used to work has broken.
4. Publish, then run the check again on the live site.

Step 7: Keep checking after updates

Updates can undo fixes or bring new problems, even from the platform. In July 2024, WooCommerce warned that a style change in version 9.1.0 of its Checkout block could make fields on dark themes look unlabelled; the change was reverted.⁸ Retest after theme, plugin, app and platform updates. Paid Jralo plans check every day and keep a dated, timestamped record of what was found and fixed, so you can see when something came back. The free check is a good way to set a baseline before you start; it also lists which countries' accessibility laws are likely relevant to your site, as a pointer rather than legal advice. Automated testing finds many problems, not all, which is why steps 5 and 6 include people.