Die meisten Tests zur Barrierefreiheit laufen an einer einzigen Version einer Website ab: der, die das Team täglich baut und betrachtet, meist auf Englisch und meist aus dem Büro heraus. Aber eine Website mit einem Dutzend Märkten ist eigentlich ein Dutzend Websites. Übersetzungen verändern Textlänge und Zeilenumbruch, lokale Teams fügen eigene Banner und Formulare hinzu, unterschiedliche Komponenten erscheinen in unterschiedlichen Ländern, und die Version, die ein Besucher in Berlin oder Tokio erhält, wurde womöglich nie getestet.
Wir wollten wissen, wie sehr das in der Praxis ins Gewicht fällt. Also haben wir 23 große Multi-Markt-Websites genommen, ihre US-, deutsche, französische und japanische Version jeweils aus dem entsprechenden Land heraus geladen und auf allen denselben automatisierten Barrierefreiheits-Audit durchgeführt. Dieser Leitfaden teilt, was wir gefunden haben, den Code, den wir verwendet haben, und wie man marktbewusstes Testen in den eigenen Prozess einbaut.
Die wichtigsten Erkenntnisse
- Die Version, die Sie testen, ist nicht die Version, die jeder erhält. Fünf der 20 Websites mit stabilen Ergebnissen wiesen mindestens einen Typ von Barrierefreiheits-Fehler in einer lokalisierten Version auf, der auf der US-Version nie auftauchte.
- Die Unterschiede waren konkret: unbeschriftete Geburtstagsfelder in einem Anmeldeformular, ein Suchfeld ohne Beschriftung, Bilder ohne Textalternativen, unbenannte Schaltflächen und Text, der den Kontrasttest nicht bestand.
- Seiten verändern sich zwischen Besuchen, also messen Sie zuerst das Rauschen. Drei der 23 Websites zeigten unterschiedliche Ergebnisse bei zwei Ladevorgängen derselben US-Seite innerhalb weniger Minuten.
- Automatisierte Regeln erfassen nur einen Teil des Problems. Behandeln Sie sie als marktweises Regressionsnetz und behalten Sie manuelle Tests mit assistiven Technologien bei.
- In der EU gilt der European Accessibility Act seit dem 28. Juni 2025 für viele Verbraucherdienstleistungen, einschließlich E-Commerce, wodurch jede Marktversion Teil der Compliance-Fläche wird.
Warum eine Version nicht ausreicht
Mehrere Dinge ändern sich zwischen Märkten, die die Barrierefreiheit beeinflussen können:
- Text. Deutsche Wörter sind lang, japanischer Text verwendet andere Schriftarten und Zeilenumbrüche, und übersetzte Beschriftungen können verloren gehen, doppelt vorkommen oder leer bleiben.
- Komponenten. Einwilligungsbanner, Cookie-Walls, Altersabfragen, Währungs- und Länderauswahl, lokale Zahlungs-Widgets und regionale Werbeaktionen erscheinen oft nur in bestimmten Märkten.
- Inhalt. Lokale Marketingteams veröffentlichen eigene Bilder und Kampagnen, manchmal außerhalb des Haupt-Designsystems, und alternativer Text ist das Erste, was dabei fehlt.
- Bereitstellung. Manche Websites liefern pro Region einen anderen Build, eine andere Domain oder eine andere Content-Management-Instanz aus.
Wie diese Versionen aussehen, hängt davon ab, wo sich der Besucher befindet. Ein Test, der die deutsche Seite aus einem US-Büro lädt, kann umgeleitet werden, einen anderen Einwilligungsablauf sehen oder die US-Variante einer regionalen Komponente erhalten. Um zu testen, was Nutzer in Deutschland bekommen, muss der Test als Besucher in Deutschland laufen.
Wie wir getestet haben
Wir wählten große Websites aus, die US-englische, deutsche, französische und japanische Versionen ihrer Startseite veröffentlichen, wobei wir die URLs aus den hreflang-Annotationen jeder Website selbst entnahmen. Am 4. Oktober 2026 luden wir jede Version in Chromium über einen Shifter-Exit im entsprechenden Land, wobei Sprache und Zeitzone des Browsers entsprechend eingestellt waren: New York für die USA, Berlin, Paris und Tokio. Wir warteten fünf Sekunden auf clientseitiges Rendering und Einwilligungsbanner und führten dann axe-core 4.13 mit seinen WCAG 2 Level A und AA Regeln aus.
Zwei der 25 Websites, mit denen wir begannen, lieferten in jedem Markt eine Blockseite und wurden ausgeschlossen, womit 23 übrig blieben. Um das Rauschen zu messen, haben wir jede US-Seite zweimal geprüft. Drei der 23 Websites lieferten zwischen diesen beiden US-Durchläufen unterschiedliche Ergebnisse, typischerweise wegen rotierender Banner oder zufällig geladener Inhalte, daher schlossen wir diese drei beim Vergleich der Märkte aus.
Was wir gefunden haben
| Messgröße | USA, erster Durchlauf | USA, zweiter Durchlauf | Deutschland | Frankreich | Japan |
|---|---|---|---|---|---|
| Verstoßinstanzen über 23 Websites | 158 | 165 | 174 | 168 | 161 |
| Websites ohne erkannte Verstöße | 6 | 5 | 3 | 3 | 5 |
| Durchschnittliche Verstoßtypen pro Seite | 1,6 | 1,7 | 1,8 | 1,8 | 1,7 |
Die lokalisierten Versionen schnitten bei jeder Messgröße etwas schlechter ab, aber die Abweichungen auf dieser Ebene liegen nahe am Durchlauf-zu-Durchlauf-Rauschen. Das klarere Signal liegt darin, welche Probleme wo auftauchten. Von den 20 Websites mit stabilen US-Ergebnissen wiesen fünf mindestens einen Fehlertyp in einer lokalisierten Version auf, der in keinem der beiden US-Durchläufe auftauchte:
| Website-Typ | Nur außerhalb der USA gefundener Fehler | Märkte |
|---|---|---|
| Gaming-Plattform | Geburtsdatumsfelder (Tag, Monat, Jahr) bei der Anmeldung ohne zugänglichen Namen | Deutschland, Frankreich, Japan |
| Website-Baukasten | Haupt-Suchfeld ohne Beschriftung | Deutschland, Frankreich, Japan |
| Anbieter von Sicherheitssoftware | Währungsauswahl mit ungültigem ARIA-Attribut; ein Werbebild ohne Textalternative; eine unbenannte Video-Abspielschaltfläche | Deutschland, Frankreich, Japan |
| E-Commerce-Plattform | Eine Schaltfläche ohne zugänglichen Namen | Deutschland, Frankreich |
| Open-Source-Projektseite | Fußzeilentext, der den Farbkontrasttest nicht bestand | Deutschland, Frankreich, Japan |
Mehrere dieser Fälle sind bedeutsamer, als die Zahlen vermuten lassen. Ein Screenreader-Nutzer kann ein Anmeldeformular nicht ausfüllen, dessen Datumsfelder keine Namen haben, und kann ein Suchfeld nicht nutzen, das nur als “Textfeld” angekündigt wird. Das sind genau die Fehlerarten, die für ein Team unsichtbar bleiben, das immer nur die US-Seite testet.
Über alle 92 Audits hinweg war der häufigste Fehler der Farbkontrast, gefunden auf 43 Seiten, gefolgt von Schaltflächen ohne zugänglichen Namen und Bildern ohne Textalternativen.
Der Code
Das folgende Modul prüft eine Seite so, wie sie ein Besucher in einem Markt sehen würde, und markiert Block- oder Fehlerseiten, damit sie nie mit der Seite verwechselt werden, die Sie eigentlich testen wollten. Es benötigt Playwright und axe-core.
import { readFileSync } from 'node:fs';
import { createRequire } from 'node:module';
const require = createRequire(import.meta.url);
const AXE_SOURCE = readFileSync(require.resolve('axe-core/axe.min.js'), 'utf8');
// Audit one page as a visitor in one market would see it: the browser's locale and time zone match the
// market, and the browser itself runs through an exit in that country.
export async function auditPage(browser, url, { locale, timezoneId }) {
const context = await browser.newContext({ locale, timezoneId });
const page = await context.newPage();
try {
const response = await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 60000 });
await page.waitForTimeout(5000); // let client-side rendering and consent banners appear
await page.evaluate(AXE_SOURCE); // evaluate, not a script tag, so the page's CSP cannot block it
const result = await page.evaluate(() =>
window.axe.run(document, { runOnly: ['wcag2a', 'wcag2aa'], resultTypes: ['violations'] }));
const lang = await page.evaluate(() => document.documentElement.getAttribute('lang'));
const status = response ? response.status() : null;
return {
url,
finalUrl: page.url(),
status,
blocked: status === null || status >= 400, // a block or error page, not the page you meant to audit
title: await page.title(),
lang,
violations: result.violations.map((v) => ({ id: v.id, impact: v.impact, nodes: v.nodes.length })),
};
} finally {
await context.close();
}
}Und die Ausführung für einen Markt, wobei der Browser über einen Exit in diesem Land geleitet wird:
import { chromium } from 'playwright';
import { auditPage } from './audit.mjs';
// One browser per market, running through an exit in that country.
const browser = await chromium.launch({
proxy: {
server: 'http://p.shifter.io:443',
username: `${process.env.SHIFTER_PROXY_USER}-country-de`,
password: process.env.SHIFTER_PROXY_PASS,
},
});
const result = await auditPage(browser, 'https://shifter.io/de', { locale: 'de-DE', timezoneId: 'Europe/Berlin' });
console.log(result.status, result.blocked, result.lang, result.violations);
await browser.close();Gegen unsere eigene deutsche Startseite ausgeführt, meldete er keine Verstöße.
Zwei Lehren aus der Entwicklung sind eingebaut. Das blocked-Flag existiert, weil unser erster Durchlauf Blockseiten prüfte: zwei Websites verweigerten jeden Exit, und ihre Blockseiten lieferten überzeugend aussehende Ergebnisse, darunter eine als US-Englisch deklarierte Seite, die wir kurzzeitig für eine falsch gekennzeichnete deutsche Seite hielten. Und axe wird mit evaluate statt mit einem Script-Tag injiziert, weil strikte Content Security Policies auf manchen Websites injizierte Skripte verweigern.
So integrieren Sie es in Ihren Prozess
- Prüfen Sie jeden Markt, in dem Sie verkaufen, aus diesem Markt heraus. Verwenden Sie einen Exit in jedem Land und stimmen Sie Sprache und Zeitzone ab, wie in Matching proxy geo, timezone and locale beschrieben, damit der Audit dieselben Einwilligungsabläufe, Weiterleitungen und regionalen Komponenten sieht wie lokale Besucher.
- Finden Sie die Versionen aus der Website selbst heraus. Hreflang-Annotationen listen jede Marktversion auf, sodass die Audit-Liste vollständig bleibt, wenn Märkte hinzukommen.
- Messen Sie das Rauschen, bevor Sie Unterschieden vertrauen. Prüfen Sie dieselbe Seite zweimal und behandeln Sie Änderungen, die auch zwischen identischen Durchläufen auftreten, als Rauschen.
- Prüfen Sie, ob Sie die richtige Seite geprüft haben. Erfassen Sie Status, Titel und finale URL, und verwerfen Sie Blockseiten, Fehlerseiten und Weiterleitungen zu einem anderen Markt. Unser Anti-Bot-Stack-Lookup erklärt, warum ein Statuscode allein in die Irre führen kann.
- Vergleichen Sie mit der Primärversion. Berichten Sie über Fehler, die in einer Marktversion existieren, aber nicht in der Version, die das Team testet, denn das sind die, die noch niemand gesehen hat.
- Führen Sie es regelmäßig aus. Lokale Kampagnen und Banner ändern sich wöchentlich; die Prinzipien der Änderungserkennung gelten auch für Barrierefreiheit.
- Behalten Sie Menschen im Prozess. Das W3C stellt klar, dass Tools nicht jede Barrierefreiheitsanforderung prüfen können und menschliches Urteilsvermögen erforderlich ist. Automatisierte Audits finden Regressionen; sie beweisen nicht, dass eine Website barrierefrei ist.
Warum es jetzt wichtig ist
Barrierefreiheit ist in vielen Ländern seit Langem eine gesetzliche Anforderung für Websites des öffentlichen Sektors. In der EU gilt der European Accessibility Act seit dem 28. Juni 2025 für eine definierte Gruppe von Verbraucherprodukten und -dienstleistungen, einschließlich E-Commerce, und die harmonisierte europäische Norm, mit der er erfüllt wird, baut auf WCAG auf. Für ein Unternehmen, das europaweit verkauft, ist die Version jedes Landes seiner Website Teil dessen, was diese Anforderungen erfüllen muss, nicht nur die, die seine Entwickler betrachten. Dies sind allgemeine Informationen, keine Rechtsberatung; prüfen Sie die in jedem Ihrer Märkte geltenden Vorschriften mit einem Anwalt.
Fazit
Barrierefreiheit wird meist an einem Ort getestet und an viele ausgeliefert. In unserem Audit von 23 Multi-Markt-Websites wies ein Viertel derjenigen mit stabilen Ergebnissen Fehler auf, die nur außerhalb der USA existierten, von unbeschrifteten Anmeldefeldern bis zu Bildern ohne Textalternativen.
Testen Sie jede Marktversion so, wie sie ein lokaler Besucher sehen würde, trennen Sie echte Unterschiede vom Rauschen und vergleichen Sie mit der Version, die Ihr Team bereits prüft. Es kostet ein paar Minuten Automatisierung pro Markt und findet die Probleme, auf die Ihre dortigen Nutzer die ganze Zeit gestoßen sind.
Quellen und Referenzen
- Deque, axe-core, Version 4.13, verwendet für die Audits.
- W3C Web Accessibility Initiative, Selecting web accessibility evaluation tools.
- Noerr, Accessibility in e-commerce: new obligations for online shop operators starting from June 2025.
- Audits durchgeführt von Shifter am 4. Oktober 2026 mit dem oben genannten Code.