La plupart des tests d’accessibilité portent sur une seule version d’un site : celle que l’équipe construit et consulte tous les jours, généralement en anglais et généralement depuis le bureau. Mais un site présent sur une douzaine de marchés est en réalité une douzaine de sites. Les traductions modifient la longueur du texte et son retour à la ligne, les équipes locales ajoutent leurs propres bannières et formulaires, différents composants apparaissent selon les pays, et la version qu’obtient un visiteur à Berlin ou à Tokyo n’a parfois jamais été testée.
Nous voulions savoir ce que cela représente en pratique. Nous avons donc pris 23 grands sites web multi-marchés, chargé leurs versions américaine, allemande, française et japonaise depuis chacun de ces pays, et exécuté le même audit d’accessibilité automatisé sur chacune d’entre elles. Ce guide présente ce que nous avons trouvé, le code que nous avons utilisé, et la manière d’intégrer des tests sensibles au marché dans votre propre processus.
Points clés
- La version que vous testez n’est pas celle que tout le monde obtient. Cinq des 20 sites aux résultats stables présentaient au moins un type d’échec d’accessibilité dans une version localisée qui n’apparaissait jamais sur leur version américaine.
- Les différences étaient concrètes : champs de date de naissance non étiquetés sur un formulaire d’inscription, champ de recherche sans étiquette, images sans alternative textuelle, boutons sans nom, et texte ne respectant pas le contraste requis.
- Les pages changent entre deux visites, il faut donc d’abord mesurer le bruit. Trois des 23 sites ont montré des résultats différents sur deux chargements de la même page américaine à quelques minutes d’intervalle.
- Les règles automatisées ne détectent qu’une partie du problème. Considérez-les comme un filet de régression marché par marché, et conservez des tests manuels avec une technologie d’assistance.
- Dans l’UE, l’European Accessibility Act s’applique depuis le 28 juin 2025 à de nombreux services destinés aux consommateurs, y compris le commerce électronique, ce qui place chaque version de marché dans le périmètre de conformité.
Pourquoi une seule version ne suffit pas
Plusieurs éléments changent d’un marché à l’autre et peuvent affecter l’accessibilité :
- Le texte. Les mots allemands sont longs, le texte japonais utilise des polices et des règles de césure différentes, et les étiquettes traduites peuvent être perdues, dupliquées ou laissées vides.
- Les composants. Les bannières de consentement, les murs de cookies, les contrôles d’âge, les sélecteurs de devise et de pays, les widgets de paiement locaux et les promotions régionales n’apparaissent souvent que sur certains marchés.
- Le contenu. Les équipes marketing locales publient leurs propres images et campagnes, parfois en dehors du système de conception principal, et le texte alternatif est la première chose à manquer.
- La diffusion. Certains sites servent une build, un domaine ou une instance de gestion de contenu différents selon la région.
L’apparence de ces versions dépend de l’endroit où se trouve le visiteur. Un test qui charge la page allemande depuis un bureau américain peut être redirigé, voir un flux de consentement différent, ou voir la variante américaine d’un composant régional. Pour tester ce que reçoivent les utilisateurs en Allemagne, le test doit s’exécuter comme un visiteur situé en Allemagne.
Comment nous avons testé
Nous avons choisi de grands sites web qui publient des versions américaine, allemande, française et japonaise de leur page d’accueil, en récupérant les URL à partir des annotations hreflang propres à chaque site. Le 4 octobre 2026, nous avons chargé chaque version dans Chromium via une sortie Shifter dans le pays correspondant, avec la langue et le fuseau horaire du navigateur réglés en conséquence : New York pour les États-Unis, Berlin, Paris et Tokyo. Nous avons attendu cinq secondes pour le rendu côté client et les bannières de consentement, puis exécuté axe-core 4.13 avec ses règles WCAG 2 niveaux A et AA.
Deux des 25 sites avec lesquels nous avons commencé ont renvoyé une page de blocage sur chaque marché et ont été exclus, ce qui a laissé 23 sites. Pour mesurer le bruit, nous avons audité chaque page américaine deux fois. Trois des 23 sites ont donné des résultats différents entre ces deux exécutions américaines, généralement à cause de bannières rotatives ou de contenu chargé de manière aléatoire, nous avons donc exclu ces trois sites lors de la comparaison entre marchés.
Ce que nous avons trouvé
| Mesure | US, première exécution | US, deuxième exécution | Allemagne | France | Japon |
|---|---|---|---|---|---|
| Occurrences de violations sur 23 sites | 158 | 165 | 174 | 168 | 161 |
| Sites sans violation détectée | 6 | 5 | 3 | 3 | 5 |
| Nombre moyen de types de violation par page | 1,6 | 1,7 | 1,8 | 1,8 | 1,7 |
Les versions localisées ont fait légèrement moins bien sur chaque mesure, mais les écarts à ce niveau sont proches du bruit d’une exécution à l’autre. Le signal le plus clair réside dans le lieu où sont apparus les problèmes. Parmi les 20 sites aux résultats américains stables, cinq présentaient au moins un type d’échec dans une version localisée qui n’apparaissait dans aucune des deux exécutions américaines :
| Type de site | Échec trouvé uniquement en dehors des US | Marchés |
|---|---|---|
| Plateforme de jeu | Champs de date de naissance du formulaire d’inscription (jour, mois, année) sans nom accessible | Allemagne, France, Japon |
| Constructeur de sites web | Champ de recherche principal sans étiquette | Allemagne, France, Japon |
| Éditeur de logiciels de sécurité | Sélecteur de devise avec un attribut ARIA invalide ; une image promotionnelle sans alternative textuelle ; un bouton de lecture vidéo sans nom | Allemagne, France, Japon |
| Plateforme e-commerce | Un bouton sans nom accessible | Allemagne, France |
| Site de projet open source | Texte de pied de page ne respectant pas le contraste de couleur | Allemagne, France, Japon |
Plusieurs de ces cas comptent davantage que ne le suggèrent les chiffres. Un utilisateur de lecteur d’écran ne peut pas terminer un formulaire d’inscription dont les champs de date n’ont pas de nom, et ne peut pas utiliser un champ de recherche annoncé uniquement comme « zone de texte modifiable ». Ce sont le genre d’échecs qui restent invisibles pour une équipe qui ne teste jamais que la page américaine.
Sur l’ensemble des 92 audits, l’échec le plus courant était le contraste des couleurs, trouvé sur 43 pages, suivi des boutons sans nom accessible et des images sans alternative textuelle.
Le code
Le module ci-dessous audite une page telle qu’un visiteur d’un marché donné la verrait, et signale les pages de blocage ou d’erreur afin qu’elles ne soient jamais confondues avec la page que vous vouliez réellement tester. Il nécessite Playwright et 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();
}
}Et pour l’exécuter sur un marché donné, avec le navigateur acheminé via une sortie dans ce pays :
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();Exécuté sur notre propre page d’accueil allemande, il n’a signalé aucune violation.
Deux leçons tirées de sa construction y sont intégrées. L’indicateur blocked existe parce que notre première exécution a audité des pages de blocage : deux sites ont refusé chaque sortie, et leurs pages de blocage ont produit des résultats d’apparence convaincante, y compris une page déclarée en anglais américain que nous avons brièvement prise pour une page allemande mal étiquetée. Et axe est injecté via evaluate plutôt que via une balise script, car les Content Security Policy strictes de certains sites refusent les scripts injectés.
Intégrer cela à votre processus
- Auditez chaque marché sur lequel vous vendez, depuis ce marché. Utilisez une sortie dans chaque pays et faites correspondre la langue et le fuseau horaire, comme décrit dans faire correspondre géolocalisation, fuseau horaire et locale du proxy, afin que l’audit voie les mêmes flux de consentement, redirections et composants régionaux que les visiteurs locaux.
- Trouvez les versions à partir du site lui-même. Les annotations hreflang listent chaque version de marché, de sorte que la liste d’audit reste complète à mesure que des marchés sont ajoutés.
- Mesurez le bruit avant de faire confiance aux différences. Auditez deux fois la même page et traitez comme du bruit les changements qui apparaissent aussi entre des exécutions identiques.
- Vérifiez que vous avez audité la bonne page. Enregistrez le statut, le titre et l’URL finale, et écartez les pages de blocage, les pages d’erreur et les redirections vers un autre marché. Notre article anti-bot stack lookup explique pourquoi un code de statut seul peut induire en erreur.
- Comparez avec la version principale. Signalez les échecs qui existent dans une version de marché mais pas dans la version que l’équipe teste, car ce sont ceux que personne n’a vus.
- Exécutez-le selon un calendrier régulier. Les campagnes et bannières locales changent chaque semaine ; les principes de détection de changement s’appliquent aussi à l’accessibilité.
- Gardez des humains dans la boucle. Le W3C est explicite : les outils ne peuvent pas vérifier toutes les exigences d’accessibilité, et un jugement humain est nécessaire. Les audits automatisés détectent les régressions ; ils ne prouvent pas qu’un site est accessible.
Pourquoi cela compte maintenant
L’accessibilité est depuis longtemps une exigence légale pour les sites web du secteur public dans de nombreux pays. Dans l’UE, l’European Accessibility Act s’applique depuis le 28 juin 2025 à un ensemble défini de produits et services destinés aux consommateurs, y compris le commerce électronique, et la norme européenne harmonisée utilisée pour s’y conformer s’appuie sur les WCAG. Pour une entreprise vendant à travers l’Europe, la version de son site pour chaque pays fait partie de ce qui doit répondre à ces exigences, pas seulement celle que ses développeurs consultent. Ceci est une information générale, pas un conseil juridique ; vérifiez les règles applicables dans chacun de vos marchés auprès d’un conseil juridique.
En résumé
L’accessibilité est généralement testée à un seul endroit et déployée sur de nombreux marchés. Dans notre audit de 23 sites multi-marchés, un quart de ceux ayant des résultats stables présentaient des échecs qui n’existaient qu’en dehors des États-Unis, allant de champs d’inscription non étiquetés à des images sans alternative textuelle.
Testez chaque version de marché comme la verrait un visiteur local, séparez les véritables différences du bruit, et comparez avec la version que votre équipe vérifie déjà. Cela coûte quelques minutes d’automatisation par marché, et cela révèle les problèmes auxquels vos utilisateurs là-bas se heurtent depuis toujours.
Sources et références
- Deque, axe-core, version 4.13, utilisé pour les 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 réalisés par Shifter le 4 octobre 2026 à l’aide du code ci-dessus.