How accessibility fixes reach a Shopify, Shopware, WooCommerce or Magento theme

When the theme produces a failure, the fix goes into the file that produces the failing markup, style or text: a template, stylesheet, script or translation file of the shop’s theme. Each platform keeps those files in its own structure and template language, so the same failure, such as a button without a name, can sit in a Liquid file on Shopify, a Twig file on Shopware, a PHP file on WooCommerce and a .phtml file on Magento.

A fix in the theme changes the code the shop itself serves. A developer can read it as a diff before it goes live and revert it like any other change to the code. An accessibility overlay is different: a script that changes the shop’s pages in the visitor’s browser, while the theme stays as it was apart from the reference that loads the script. What overlays change and what they leave as it was

A theme update can undo an accessibility fix when the fix sits in a file that the update replaces or when the update cannot carry the edit over, and on some platforms other changes can hide a fix. The platforms document this in different ways.

• WooCommerce. Changes made directly in a plugin or a parent theme “will disappear when the plugin or theme updates itself; a process that entirely deletes the old version and replaces it with a fresh, updated copy” (WooCommerce on template structure). WooCommerce recommends a child theme with template overrides instead. Those overrides do not update when WooCommerce’s core templates do, and WooCommerce’s System Status report can show a notice that an override is out of date.
• WordPress block themes. A template that someone has changed in the Site Editor is saved in the site’s database and takes priority over the template files of the theme and of a child theme (WordPress Theme Handbook on templates and on the template hierarchy). A fix in the file of such a template is then not what visitors see.
• Magento Open Source and Adobe Commerce. Adobe “strongly recommend[s]” not changing the Luma and Blank theme files or the default templates, because upgrades can overwrite them (Adobe on themes, Adobe on templates). Adobe’s recommended place for changes is a custom theme, which can inherit from Luma or Blank.
• Shopware 6. A theme that inherits from a store-bought theme leaves that theme’s code unchanged, as described above. Shopware warns that a theme which overrides variables of a third-party theme can stop compiling if that theme later renames or removes them (Shopware on theme configuration).
• Shopify. Shopify’s Help Center on updating themes says that code edits which do not conflict with a theme update are carried into the updated copy. If they are incompatible with the update, all code changes are removed from the updated copy, and keeping them means copying them to the new version. The update arrives as a draft theme whose name starts with “Updated copy of”.

Validiscan’s fixes are edits to the files of the theme source it receives. Which source that is, the theme in use, its child theme or an inheriting theme, is therefore a question for the shop’s developer before the work starts. When a WooCommerce theme reaches Validiscan as a ZIP, the customer portal asks for the theme folder “including the child theme if you use one”. Regression protection, a separate service billed monthly after a project, scans the shop again weekly or monthly and compares each run with the baseline. When a failure that was fixed is found again, for example after a theme update, the finding is reopened and reported as a regression. A re-scan finds only what automated checks can find on the pages it reaches.

Validiscan prepares fixes on a copy of the theme’s source, which it gets in one of three ways. It applies the fixes in a temporary working folder, which is deleted after each delivery.

• A GitHub repository, on all four platforms. The shop installs Validiscan’s GitHub App on the repository, or gives Validiscan an access token. Validiscan’s setup specifies the App’s permissions as write access to the repository’s contents and pull requests and read access to its metadata, and nothing else.
• A Theme Access password, on Shopify only. Shopify’s Theme Access app creates passwords that grant write access to themes only (the write_themes scope). Setting up the app takes the store owner, or a staff member or collaborator with the Themes permission. As of 6 October 2026, Shopify’s documentation says that the link to the password expires after 7 days or once it has been viewed, and that deleting the password revokes the access.
• A ZIP of the theme, on all four platforms, for a patch bundle, uploaded in the customer portal as one file of up to 100 MB. The portal asks for the theme plugin’s folder under custom/plugins on Shopware, the theme folder under wp-content/themes on WooCommerce, the theme folder under app/design/frontend on Magento, and the theme file downloaded from the Shopify admin on Shopify.

Without any of the three, Validiscan has no code to change, and no fix is prepared.

Validiscan delivers approved fixes as a pull request, as an unpublished copy of the Shopify theme, or as a patch bundle. The way is set per shop, not per platform, and the patch bundle is the default. None of the three changes the shop’s published theme or the repository’s default branch.

The review checklist in Validiscan’s pull request asks the developer to review the fixes like any other theme change, and also to use the changed elements with the keyboard and, where possible, a screen reader. It lists these steps:

1. Read the diff of each commit.
2. Deploy the branch to a preview or staging environment, not to the live shop.
3. Open the affected pages and check that they look and work as before.
4. Operate the changed elements with the keyboard only: everything must be reachable and the focus visible.
5. If possible, check the changed elements with a screen reader, for example NVDA or VoiceOver.
6. Merge when satisfied. Validiscan then checks the affected pages with a verification scan.

The delivery documents (the pull request text, PATCH.md and the README) are written in English or German. Customers whose language is set to Danish, French or Spanish receive the English version.

Each platform page describes what the fixes change on that platform and what the merchant provides: accessibility fixes for Shopify themes, for Shopware themes, for WooCommerce themes and for Magento themes.

On Shopify, Shopware, WooCommerce and Magento, Validiscan prepares fixes in the shop’s own theme code for failures whose fix belongs there, and delivers them in the three ways above. Findings in the MANUAL tier get guidance only, not a code change. Once the changes are live, a verification scan checks the affected pages again. The Remediation Evidence Package then records what was tested, what was changed and what the verification scan found, with the date of every scan. It is evidence of an evaluation and of remediation work, not a certificate. How a project runs, step by step