Wie Korrekturen zur Barrierefreiheit in ein Theme für Shopify, Shopware, WooCommerce oder Magento gelangen

Geht ein Fehler auf das Theme zurück, gehört die Korrektur in die Datei, aus der das fehlerhafte Markup, Styling oder der fehlerhafte Text stammt: in ein Template, ein Stylesheet, ein Skript oder eine Übersetzungsdatei des Shop-Themes. Jede Plattform hat für diese Dateien ihre eigene Struktur und ihre eigene Template-Sprache. Derselbe Fehler, etwa eine Schaltfläche ohne Namen, kann deshalb auf Shopify in einer Liquid-Datei stecken, auf Shopware in einer Twig-Datei, auf WooCommerce in einer PHP-Datei und auf Magento in einer .phtml-Datei.

Eine Korrektur im Theme ändert den Code, den der Shop selbst ausliefert. Entwicklerinnen und Entwickler können die Korrektur als Diff lesen, bevor sie live geht, und sie wie jede andere Codeänderung zurücknehmen. Ein Barrierefreiheits-Overlay funktioniert anders: Es ist ein Skript, das die Seiten des Shops im Browser der Besucherinnen und Besucher verändert. Das Theme bleibt dabei, wie es war, bis auf den Verweis, der das Skript lädt. Was Overlays ändern und was sie unverändert lassen

Ein Theme-Update kann eine Korrektur zur Barrierefreiheit rückgängig machen, wenn die Korrektur in einer Datei liegt, die das Update ersetzt, oder wenn das Update die Änderung nicht übernehmen kann. Auf manchen Plattformen können außerdem andere Änderungen eine Korrektur verdecken. Die Plattformen beschreiben das jeweils auf ihre Weise.

• WooCommerce. Änderungen, die direkt in einem Plugin oder einem Parent-Theme vorgenommen werden, verschwinden laut WooCommerce zur Template-Struktur, sobald sich das Plugin oder Theme aktualisiert. Bei diesem Vorgang wird die alte Version vollständig gelöscht und durch eine neue, aktualisierte Kopie ersetzt. WooCommerce empfiehlt stattdessen ein Child-Theme mit Template-Overrides. Diese Overrides werden nicht mitaktualisiert, wenn sich die Kern-Templates von WooCommerce ändern, und der Systemstatus-Bericht von WooCommerce kann darauf hinweisen, dass ein Override veraltet ist.
• Block-Themes in WordPress. Ein Template, das jemand im Website-Editor geändert hat, wird in der Datenbank der Website gespeichert und hat Vorrang vor den Template-Dateien des Themes und eines Child-Themes (WordPress Theme Handbook zu Templates und zur Template-Hierarchie). Eine Korrektur in der Datei eines solchen Templates bekommen Besucherinnen und Besucher dann nicht zu sehen.
• Magento Open Source und Adobe Commerce. Adobe rät nachdrücklich davon ab, die Theme-Dateien von Luma und Blank oder die Standard-Templates zu ändern, weil Upgrades sie überschreiben können (Adobe zu Themes, Adobe zu Templates). Für Änderungen empfiehlt Adobe ein eigenes Theme, das von Luma oder Blank erben kann.
• Shopware 6. Ein Theme, das von einem gekauften Theme erbt, lässt dessen Code unverändert, wie oben beschrieben. Shopware warnt jedoch: Überschreibt ein Theme Variablen eines Drittanbieter-Themes, lässt es sich unter Umständen nicht mehr kompilieren, wenn jenes Theme diese Variablen später umbenennt oder entfernt (Shopware zur Theme-Konfiguration).
• Shopify. Laut der englischsprachigen Seite des Help Centers von Shopify zum Aktualisieren von Themes werden Codeänderungen, die nicht mit dem Theme-Update kollidieren, in die aktualisierte Kopie übernommen. Sind sie mit dem Update nicht vereinbar, fehlen in der aktualisierten Kopie sämtliche Codeänderungen, und wer sie behalten will, muss sie in die neue Version übertragen. Das Update erscheint als Theme-Entwurf, dessen Name mit „Updated copy of“ beginnt.

Die Korrekturen von Validiscan sind Änderungen an den Dateien des Theme-Quellcodes, den Validiscan erhält. Welcher Code das ist (das verwendete Theme, sein Child-Theme oder ein Theme, das davon erbt), ist deshalb vor Beginn der Arbeit eine Frage an das Entwicklungsteam des Shops. Erhält Validiscan ein WooCommerce-Theme als ZIP, bittet das Kundenportal um den Theme-Ordner „einschließlich des Child-Themes, falls Sie eines verwenden“. Der Regressionsschutz, ein eigener Dienst, der nach einem Projekt monatlich abgerechnet wird, scannt den Shop wöchentlich oder monatlich erneut und vergleicht jeden Durchlauf mit dem Ausgangsstand. Taucht ein behobener Fehler wieder auf, etwa nach einem Theme-Update, wird der Befund wieder geöffnet und als Regression gemeldet. Ein erneuter Scan findet nur, was automatisierte Prüfungen auf den Seiten finden können, die er erreicht.

Validiscan bereitet Korrekturen an einer Kopie des Theme-Quellcodes vor und erhält diese Kopie auf einem von drei Wegen. Angewendet werden die Korrekturen in einem temporären Arbeitsordner, der nach jeder Auslieferung gelöscht wird.

• Ein GitHub-Repository, auf allen vier Plattformen. Der Shop installiert die GitHub App von Validiscan im Repository oder gibt Validiscan ein Zugriffstoken. Die Einrichtung von Validiscan legt die Berechtigungen der App fest: Schreibzugriff auf die Inhalte und Pull Requests des Repositorys, Lesezugriff auf seine Metadaten und sonst nichts.
• Ein Theme-Access-Passwort, nur auf Shopify. Die App Theme Access von Shopify erstellt Passwörter, die Schreibzugriff ausschließlich auf Themes gewähren (den Scope write_themes). Für die Einrichtung braucht es die Inhaberin oder den Inhaber des Shops oder eine Mitarbeiterin, einen Mitarbeiter oder einen Collaborator mit der Berechtigung für Themes. Laut Shopifys Dokumentation (Stand: 6. Oktober 2026) läuft der Link zum Passwort nach 7 Tagen ab oder sobald das Passwort angesehen wurde, und wer das Passwort löscht, entzieht damit den Zugriff.
• Ein ZIP des Themes, auf allen vier Plattformen, für ein Patch-Paket. Es wird im Kundenportal als eine einzige Datei von bis zu 100 MB hochgeladen. Das Kundenportal bittet auf Shopware um den Ordner des Theme-Plugins unter custom/plugins, auf WooCommerce um den Theme-Ordner unter wp-content/themes, auf Magento um den Theme-Ordner unter app/design/frontend und auf Shopify um die Theme-Datei, die sich im Shopify-Adminbereich herunterladen lässt.

Steht keiner der drei Wege zur Verfügung, hat Validiscan keinen Code, den es ändern könnte, und es wird keine Korrektur vorbereitet.

Validiscan liefert freigegebene Korrekturen als Pull Request, als unveröffentlichte Kopie des Shopify-Themes oder als Patch-Paket. Der Weg wird je Shop festgelegt, nicht je Plattform, und voreingestellt ist das Patch-Paket. Keiner der drei Wege verändert das veröffentlichte Theme des Shops oder den Standard-Branch des Repositorys.

Die Checkliste für die Prüfung im Pull Request von Validiscan bittet das Entwicklungsteam, die Korrekturen wie jede andere Änderung am Theme zu prüfen und die geänderten Elemente zusätzlich mit der Tastatur und nach Möglichkeit mit einem Screenreader zu bedienen. Sie nennt diese Schritte:

1. Prüfen Sie den Diff jedes Commits.
2. Stellen Sie den Branch in einer Vorschau- oder Staging-Umgebung bereit, nicht im Live-Shop.
3. Öffnen Sie die betroffenen Seiten und prüfen Sie, ob sie wie bisher aussehen und funktionieren.
4. Bedienen Sie die geänderten Elemente nur mit der Tastatur: Alles muss erreichbar und der Fokus sichtbar sein.
5. Prüfen Sie die geänderten Elemente nach Möglichkeit mit einem Screenreader, zum Beispiel NVDA oder VoiceOver.
6. Führen Sie den Merge durch, wenn Sie zufrieden sind. Validiscan prüft die betroffenen Seiten anschließend mit einem Verifizierungsscan.

Die Auslieferungsdokumente (der Text des Pull Requests, PATCH.md und die README) sind auf Englisch oder Deutsch verfasst. Kundinnen und Kunden, deren Sprache auf Dänisch, Französisch oder Spanisch eingestellt ist, erhalten die englische Fassung.

Was die Korrekturen auf der jeweiligen Plattform ändern und was Händlerinnen und Händler dafür bereitstellen, beschreiben die Plattformseiten: Korrekturen zur Barrierefreiheit für Shopify-Themes, für Shopware-Themes, für WooCommerce-Themes und für Magento-Themes.

Auf Shopify, Shopware, WooCommerce und Magento bereitet Validiscan Korrekturen im eigenen Theme-Code des Shops vor, wenn die Korrektur eines Fehlers dorthin gehört, und liefert sie auf den drei oben beschriebenen Wegen aus. Befunde der Stufe MANUAL erhalten nur eine Anleitung, keine Codeänderung. Sobald die Änderungen live sind, prüft ein Verifizierungsscan die betroffenen Seiten erneut. Das Remediation Evidence Package hält dann fest, was geprüft wurde, was geändert wurde und was der Verifizierungsscan ergeben hat, mit dem Datum jedes Scans. Es belegt eine Prüfung und die Arbeit an der Behebung; ein Zertifikat ist es nicht. Wie ein Projekt abläuft, Schritt für Schritt