A maior parte dos testes de acessibilidade acontece em uma única versão do site: aquela que a equipe constrói e observa todos os dias, geralmente em inglês e geralmente a partir do escritório. Mas um site com uma dezena de mercados é, na prática, uma dezena de sites. As traduções mudam o comprimento do texto e sua quebra de linha, as equipes locais adicionam seus próprios banners e formulários, componentes diferentes aparecem em países diferentes, e a versão que um visitante em Berlim ou Tóquio recebe pode nunca ter sido testada.
Queríamos saber o quanto isso importa na prática. Então pegamos 23 grandes sites multi-mercado, carregamos suas versões para EUA, Alemanha, França e Japão de dentro de cada um desses países, e rodamos a mesma auditoria automatizada de acessibilidade em todas elas. Este guia compartilha o que encontramos, o código que usamos e como incorporar testes com consciência de mercado ao seu próprio processo.
Principais conclusões
- A versão que você testa não é a versão que todos recebem. Cinco dos 20 sites com resultados estáveis tinham pelo menos um tipo de falha de acessibilidade em uma versão localizada que nunca apareceu na versão para os EUA.
- As diferenças eram concretas: campos de data de nascimento sem rótulo em um formulário de cadastro, uma caixa de busca sem rótulo, imagens sem alternativas textuais, botões sem nome e texto que falhou no contraste.
- As páginas mudam entre visitas, então meça o ruído primeiro. Três dos 23 sites mostraram resultados diferentes em dois carregamentos da mesma página dos EUA, com minutos de diferença.
- Regras automatizadas capturam apenas parte do problema. Trate-as como uma rede de regressão mercado a mercado, e mantenha testes manuais com tecnologia assistiva.
- Na UE, o European Accessibility Act está em vigor desde 28 de junho de 2025 para muitos serviços de consumo, incluindo e-commerce, o que torna cada versão de mercado parte do escopo de conformidade.
Por que uma única versão não é suficiente
Várias coisas mudam entre mercados que podem afetar a acessibilidade:
- Texto. Palavras em alemão são longas, o texto em japonês usa fontes diferentes e quebra de linha diferente, e rótulos traduzidos podem ser perdidos, duplicados ou deixados vazios.
- Componentes. Banners de consentimento, cookie walls, verificações de idade, seletores de moeda e país, widgets de pagamento locais e promoções regionais muitas vezes aparecem apenas em alguns mercados.
- Conteúdo. Equipes de marketing locais publicam suas próprias imagens e campanhas, às vezes fora do sistema de design principal, e o texto alternativo é a primeira coisa a desaparecer.
- Entrega. Alguns sites servem uma build, domínio ou instância de gerenciamento de conteúdo diferente por região.
A aparência dessas versões depende de onde o visitante está. Um teste que carrega a página alemã a partir de um escritório nos EUA pode ser redirecionado, ver um fluxo de consentimento diferente, ou ver a variante dos EUA de um componente regional. Para testar o que os usuários na Alemanha recebem, o teste precisa rodar como um visitante na Alemanha.
Como testamos
Escolhemos grandes sites que publicam versões em inglês dos EUA, alemão, francês e japonês de sua página inicial, retirando as URLs das próprias anotações hreflang de cada site. Em 4 de outubro de 2026, carregamos cada versão no Chromium através de uma saída Shifter no país correspondente, com o idioma e o fuso horário do navegador configurados para corresponder: Nova York para os EUA, Berlim, Paris e Tóquio. Esperamos cinco segundos para a renderização do lado do cliente e banners de consentimento, depois rodamos o axe-core 4.13 com suas regras WCAG 2 Nível A e AA.
Dois dos 25 sites com que começamos retornaram uma página de bloqueio em todos os mercados e foram excluídos, o que deixou 23. Para medir o ruído, auditamos cada página dos EUA duas vezes. Três dos 23 sites deram resultados diferentes entre essas duas execuções nos EUA, tipicamente por causa de banners rotativos ou conteúdo carregado aleatoriamente, então excluímos esses três ao comparar os mercados.
O que encontramos
| Medida | EUA, primeira execução | EUA, segunda execução | Alemanha | França | Japão |
|---|---|---|---|---|---|
| Instâncias de violação em 23 sites | 158 | 165 | 174 | 168 | 161 |
| Sites sem violações detectadas | 6 | 5 | 3 | 3 | 5 |
| Média de tipos de violação por página | 1,6 | 1,7 | 1,8 | 1,8 | 1,7 |
As versões localizadas tiveram um desempenho ligeiramente pior em todas as medidas, mas as diferenças nesse nível estão próximas do ruído entre execuções. O sinal mais claro está em quais problemas apareceram e onde. Dos 20 sites com resultados estáveis nos EUA, cinco tinham pelo menos um tipo de falha em uma versão localizada que não apareceu em nenhuma das execuções nos EUA:
| Tipo de site | Falha encontrada apenas fora dos EUA | Mercados |
|---|---|---|
| Plataforma de jogos | Campos de data de nascimento no cadastro (dia, mês, ano) sem nome acessível | Alemanha, França, Japão |
| Construtor de sites | Campo de busca principal sem rótulo | Alemanha, França, Japão |
| Fornecedor de software de segurança | Seletor de moeda com atributo ARIA inválido; imagem promocional sem alternativa textual; botão de reprodução de vídeo sem nome | Alemanha, França, Japão |
| Plataforma de e-commerce | Um botão sem nome acessível | Alemanha, França |
| Site de projeto de código aberto | Texto do rodapé que falhou no contraste de cor | Alemanha, França, Japão |
Várias dessas falhas importam mais do que as contagens sugerem. Um usuário de leitor de tela não consegue preencher um formulário de cadastro cujos campos de data não têm nomes, e não consegue usar uma caixa de busca que é anunciada apenas como “editar texto”. São o tipo de falha que permanece invisível para uma equipe que só testa a página dos EUA.
Em todas as 92 auditorias, a falha mais comum foi o contraste de cor, encontrada em 43 páginas, seguida por botões sem nome acessível e imagens sem alternativas textuais.
O código
O módulo abaixo audita uma página como um visitante em um mercado a veria, e sinaliza páginas de bloqueio ou erro para que nunca sejam confundidas com a página que você pretendia testar. Ele precisa do Playwright e do 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();
}
}E executando para um mercado, com o navegador roteado através de uma saída naquele país:
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();Executado contra nossa própria página inicial alemã, ele não reportou violações.
Duas lições da sua construção estão incorporadas aqui. A flag blocked existe porque nossa primeira execução auditou páginas de bloqueio: dois sites recusaram todas as saídas, e suas páginas de bloqueio produziram resultados de aparência convincente, incluindo uma página declarada como inglês dos EUA que por um momento tomamos por uma página alemã mal rotulada. E o axe é injetado com evaluate em vez de uma tag de script, porque Content Security Policies rigorosas em alguns sites recusam scripts injetados.
Incorporando isso ao seu processo
- Audite cada mercado em que você vende, a partir daquele mercado. Use uma saída em cada país e ajuste idioma e fuso horário, conforme descrito em correspondência entre geo, fuso horário e locale do proxy, para que a auditoria veja os mesmos fluxos de consentimento, redirecionamentos e componentes regionais que os visitantes locais.
- Encontre as versões a partir do próprio site. Anotações hreflang listam todas as versões de mercado, então a lista de auditoria permanece completa à medida que mercados são adicionados.
- Meça o ruído antes de confiar nas diferenças. Audite a mesma página duas vezes e trate as mudanças que também aparecem entre execuções idênticas como ruído.
- Verifique se você auditou a página certa. Registre o status, o título e a URL final, e descarte páginas de bloqueio, páginas de erro e redirecionamentos para outro mercado. Nossa consulta de stack anti-bot explica por que um código de status sozinho pode enganar.
- Compare com a versão principal. Reporte falhas que existem em uma versão de mercado mas não na versão que a equipe testa, já que essas são as que ninguém viu.
- Execute em uma agenda. Campanhas e banners locais mudam semanalmente; os princípios de detecção de mudanças se aplicam também à acessibilidade.
- Mantenha humanos no processo. O W3C é explícito ao afirmar que ferramentas não conseguem verificar todos os requisitos de acessibilidade e que o julgamento humano é necessário. Auditorias automatizadas encontram regressões; elas não provam que um site é acessível.
Por que isso importa agora
A acessibilidade há muito tempo é uma exigência legal para sites do setor público em muitos países. Na UE, o European Accessibility Act está em vigor desde 28 de junho de 2025 para um conjunto definido de produtos e serviços de consumo, incluindo e-commerce, e o padrão europeu harmonizado usado para atendê-lo se baseia no WCAG. Para uma empresa que vende em toda a Europa, a versão do site de cada país faz parte do que precisa atender a essas exigências, não apenas aquela que seus desenvolvedores observam. Isso é informação geral, não aconselhamento jurídico; verifique as regras aplicáveis em cada um dos seus mercados com assessoria jurídica.
Conclusão
A acessibilidade costuma ser testada em um único lugar e entregue para muitos. Em nossa auditoria de 23 sites multi-mercado, um quarto daqueles com resultados estáveis tinha falhas que existiam apenas fora dos EUA, desde campos de cadastro sem rótulo até imagens sem alternativas textuais.
Teste cada versão de mercado como um visitante local a veria, separe diferenças reais de ruído, e compare com a versão que sua equipe já verifica. Isso custa alguns minutos de automação por mercado, e encontra os problemas que seus usuários ali vêm enfrentando o tempo todo.
Fontes e referências
- Deque, axe-core, versão 4.13, usado nas auditorias.
- W3C Web Accessibility Initiative, Selecting web accessibility evaluation tools.
- Noerr, Accessibility in e-commerce: new obligations for online shop operators starting from June 2025.
- Auditorias realizadas pela Shifter em 4 de outubro de 2026 usando o código acima.