La mayoría de las pruebas de accesibilidad se realizan sobre una única versión del sitio: la que el equipo construye y revisa a diario, normalmente en inglés y normalmente desde la oficina. Pero un sitio con una docena de mercados es en realidad una docena de sitios. Las traducciones cambian la longitud del texto y el ajuste de línea, los equipos locales añaden sus propios banners y formularios, en cada país aparecen componentes distintos, y la versión que recibe un visitante en Berlín o Tokio puede no haberse probado nunca.
Queríamos saber hasta qué punto esto importa en la práctica. Así que cogimos 23 sitios web grandes con presencia multimercado, cargamos sus versiones para EE. UU., Alemania, Francia y Japón desde dentro de cada uno de esos países, y ejecutamos la misma auditoría de accesibilidad automatizada en todas ellas. Esta guía explica lo que encontramos, el código que usamos y cómo incorporar pruebas sensibles al mercado a tu propio proceso.
Conclusiones clave
- La versión que pruebas no es la versión que recibe todo el mundo. Cinco de los 20 sitios con resultados estables tenían al menos un tipo de fallo de accesibilidad en una versión localizada que nunca apareció en su versión para EE. UU.
- Las diferencias eran concretas: campos de fecha de nacimiento sin etiquetar en un formulario de registro, un cuadro de búsqueda sin etiqueta, imágenes sin alternativas de texto, botones sin nombre y texto que no cumplía el contraste.
- Las páginas cambian entre visitas, así que mide primero el ruido. Tres de los 23 sitios mostraron resultados distintos en dos cargas de la misma página de EE. UU. con minutos de diferencia.
- Las reglas automatizadas solo detectan una parte del problema. Trátalas como una red de regresión mercado por mercado, y mantén las pruebas manuales con tecnología de asistencia.
- En la UE, la Ley Europea de Accesibilidad se aplica desde el 28 de junio de 2025 a muchos servicios de consumo, incluido el comercio electrónico, lo que convierte cada versión de mercado en parte de la superficie de cumplimiento normativo.
Por qué una sola versión no es suficiente
Varias cosas cambian entre mercados que pueden afectar a la accesibilidad:
- Texto. Las palabras en alemán son largas, el texto en japonés usa fuentes distintas y un salto de línea diferente, y las etiquetas traducidas pueden perderse, duplicarse o quedar vacías.
- Componentes. Los banners de consentimiento, muros de cookies, verificaciones de edad, selectores de moneda y país, widgets de pago locales y promociones regionales a menudo solo aparecen en algunos mercados.
- Contenido. Los equipos de marketing locales publican sus propias imágenes y campañas, a veces fuera del sistema de diseño principal, y el texto alternativo es lo primero que suele faltar.
- Distribución. Algunos sitios sirven una compilación, dominio o instancia de gestión de contenidos distinta por región.
El aspecto de esas versiones depende de dónde esté el visitante. Una prueba que carga la página alemana desde una oficina en EE. UU. puede ser redirigida, ver un flujo de consentimiento diferente, o ver la variante estadounidense de un componente regional. Para probar lo que reciben los usuarios en Alemania, la prueba tiene que ejecutarse como un visitante en Alemania.
Cómo hicimos las pruebas
Elegimos sitios web grandes que publican versiones en inglés de EE. UU., alemán, francés y japonés de su página de inicio, tomando las URL de las anotaciones hreflang de cada sitio. El 4 de octubre de 2026 cargamos cada versión en Chromium a través de una salida de Shifter en el país correspondiente, con el idioma y la zona horaria del navegador configurados para coincidir: Nueva York para EE. UU., Berlín, París y Tokio. Esperamos cinco segundos para la renderización del lado del cliente y los banners de consentimiento, y luego ejecutamos axe-core 4.13 con sus reglas WCAG 2 Nivel A y AA.
Dos de los 25 sitios con los que empezamos devolvieron una página de bloqueo en todos los mercados y fueron excluidos, lo que dejó 23. Para medir el ruido, auditamos cada página de EE. UU. dos veces. Tres de los 23 sitios dieron resultados distintos entre esas dos ejecuciones en EE. UU., normalmente debido a banners rotativos o contenido cargado de forma aleatoria, así que excluimos esos tres al comparar mercados.
Lo que encontramos
| Medida | EE. UU., primera ejecución | EE. UU., segunda ejecución | Alemania | Francia | Japón |
|---|---|---|---|---|---|
| Instancias de violación en 23 sitios | 158 | 165 | 174 | 168 | 161 |
| Sitios sin violaciones detectadas | 6 | 5 | 3 | 3 | 5 |
| Tipos medios de violación por página | 1,6 | 1,7 | 1,8 | 1,8 | 1,7 |
Las versiones localizadas obtuvieron resultados ligeramente peores en todas las medidas, pero las diferencias a este nivel están cerca del ruido entre ejecuciones. La señal más clara está en qué problemas aparecieron y dónde. De los 20 sitios con resultados estables en EE. UU., cinco tenían al menos un tipo de fallo en una versión localizada que no apareció en ninguna de las dos ejecuciones de EE. UU.:
| Tipo de sitio | Fallo encontrado solo fuera de EE. UU. | Mercados |
|---|---|---|
| Plataforma de juegos | Campos de fecha de nacimiento del registro (día, mes, año) sin nombre accesible | Alemania, Francia, Japón |
| Constructor de sitios web | Campo de búsqueda principal sin etiqueta | Alemania, Francia, Japón |
| Proveedor de software de seguridad | Selector de moneda con un atributo ARIA inválido; una imagen promocional sin alternativa de texto; un botón de reproducción de vídeo sin nombre | Alemania, Francia, Japón |
| Plataforma de comercio electrónico | Un botón sin nombre accesible | Alemania, Francia |
| Sitio de proyecto de código abierto | Texto del pie de página que no cumplía el contraste de color | Alemania, Francia, Japón |
Varios de estos casos importan más de lo que sugieren las cifras. Un usuario de lector de pantalla no puede completar un formulario de registro cuyos campos de fecha no tienen nombre, ni puede usar un cuadro de búsqueda que se anuncia solo como “editar texto”. Son el tipo de fallo que permanece invisible para un equipo que solo prueba la página de EE. UU.
En las 92 auditorías realizadas, el fallo más común fue el contraste de color, encontrado en 43 páginas, seguido de botones sin nombre accesible e imágenes sin alternativas de texto.
El código
El módulo siguiente audita una página tal como la vería un visitante en un mercado concreto, y marca las páginas de bloqueo o error para que nunca se confundan con la página que querías probar. Necesita Playwright y 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();
}
}Y ejecutándolo para un mercado, con el navegador enrutado a través de una salida en ese 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();Ejecutado contra nuestra propia página de inicio en alemán, no se reportó ninguna violación.
Dos lecciones de su construcción están incorporadas. El indicador blocked existe porque nuestra primera ejecución auditó páginas de bloqueo: dos sitios rechazaron todas las salidas, y sus páginas de bloqueo produjeron resultados de aspecto convincente, incluida una página declarada como inglés de EE. UU. que por un momento confundimos con una página alemana mal etiquetada. Y axe se inyecta con evaluate en lugar de una etiqueta de script, porque las políticas de seguridad de contenido (CSP) estrictas de algunos sitios rechazan los scripts inyectados.
Cómo incorporarlo a tu proceso
- Audita cada mercado en el que vendes, desde ese mercado. Usa una salida en cada país y haz coincidir idioma y zona horaria, como se describe en cómo hacer coincidir la geolocalización, la zona horaria y el idioma del proxy, para que la auditoría vea los mismos flujos de consentimiento, redirecciones y componentes regionales que los visitantes locales.
- Encuentra las versiones a partir del propio sitio. Las anotaciones hreflang enumeran cada versión de mercado, por lo que la lista de auditoría permanece completa a medida que se añaden mercados.
- Mide el ruido antes de confiar en las diferencias. Audita la misma página dos veces y trata los cambios que también aparecen entre ejecuciones idénticas como ruido.
- Comprueba que auditaste la página correcta. Registra el estado, el título y la URL final, y descarta páginas de bloqueo, páginas de error y redirecciones a otro mercado. Nuestro análisis de la pila anti-bot explica por qué un código de estado por sí solo puede inducir a error.
- Compara frente a la versión principal. Informa de los fallos que existen en una versión de mercado pero no en la versión que prueba el equipo, ya que esos son los que nadie ha visto.
- Ejecútalo con regularidad. Las campañas y banners locales cambian semanalmente; los principios de detección de cambios también se aplican a la accesibilidad.
- Mantén a las personas en el proceso. El W3C es explícito en que las herramientas no pueden comprobar todos los requisitos de accesibilidad y que se requiere el juicio humano. Las auditorías automatizadas encuentran regresiones; no demuestran que un sitio sea accesible.
Por qué importa ahora
La accesibilidad lleva mucho tiempo siendo un requisito legal para los sitios web del sector público en muchos países. En la UE, la Ley Europea de Accesibilidad se aplica desde el 28 de junio de 2025 a un conjunto definido de productos y servicios de consumo, incluido el comercio electrónico, y el estándar europeo armonizado utilizado para cumplirla se basa en WCAG. Para una empresa que vende en toda Europa, la versión de su sitio en cada país forma parte de lo que debe cumplir esos requisitos, no solo la que revisan sus desarrolladores. Esto es información general, no asesoramiento legal; comprueba las normas que se aplican en cada uno de tus mercados con asesoría legal.
La conclusión
La accesibilidad se suele probar en un solo lugar y se distribuye a muchos. En nuestra auditoría de 23 sitios multimercado, una cuarta parte de los que tenían resultados estables presentaba fallos que solo existían fuera de EE. UU., desde campos de registro sin etiquetar hasta imágenes sin alternativas de texto.
Prueba cada versión de mercado tal como la vería un visitante local, separa las diferencias reales del ruido, y compara frente a la versión que tu equipo ya revisa. Cuesta unos minutos de automatización por mercado, y encuentra los problemas con los que tus usuarios allí han estado lidiando todo este tiempo.
Fuentes y referencias
- Deque, axe-core, versión 4.13, utilizada para las auditorías.
- W3C Web Accessibility Initiative, Selecting web accessibility evaluation tools.
- Noerr, Accessibility in e-commerce: new obligations for online shop operators starting from June 2025.
- Auditorías realizadas por Shifter el 4 de octubre de 2026 utilizando el código anterior.