WCAG 3.2.5: Cambio a petición

Qué Significa Esta Regla

WCAG 3.2.5 Cambio a Petición es un criterio de Nivel AAA bajo el principio de Comprensible. Establece que los cambios de contexto deben ser iniciados únicamente por la persona usuaria, no activados automáticamente por el sistema. Un "cambio de contexto" se define en WCAG como un cambio importante en el contenido de la página web que, sin que la persona usuaria sea consciente, puede desorientar a quienes no pueden ver la página completa a la vez. Esto incluye cambios en el agente de usuario (navegador), el viewport, el foco o el contenido que alteren significativamente el significado de la página.

En concreto, el criterio prohíbe cualquier mecanismo que provoque un cambio de contexto sin una petición explícita de la persona usuaria. Esto amplía los requisitos de 3.2.1 (Al recibir el foco) y 3.2.2 (Al introducir datos) abordando todos los escenarios restantes en los que podrían producirse cambios de contexto automáticos — incluyendo, entre otros: páginas que se actualizan automáticamente, carruseles que avanzan automáticamente y navegan fuera de la página, etiquetas meta de redirección con retrasos cortos, navegación activada por JavaScript al completar un campo de formulario y apertura de nuevas ventanas o pestañas sin iniciativa de la persona usuaria.

Para cumplir este criterio se requiere una de dos condiciones: o bien los cambios de contexto solo se activan mediante una acción explícita y deliberada de la persona usuaria (como activar un botón o enlace), o se proporciona un mecanismo que le permita desactivar los cambios de contexto automáticos antes de que ocurran. Por ejemplo, si una página se actualiza automáticamente cada 30 segundos y navega a contenido nuevo, no cumple — a menos que exista un control claramente etiquetado para desactivar ese comportamiento antes de que ocurra la primera actualización. Simplemente proporcionar una advertencia después de los hechos no es suficiente.

El criterio se aplica de forma amplia a todo contenido web interactivo y dinámico. Los elementos y comportamientos comúnmente afectados incluyen: redirecciones mediante <meta http-equiv='refresh'>, llamadas de JavaScript a window.location o history.pushState activadas por temporizadores, controladores de eventos onchange en elementos <select> que navegan a una nueva URL, formularios que se envían automáticamente, navegación activada por el foco y cualquier widget que se desplace automáticamente, avance diapositivas o cambie el conjunto de contenido visible sin entrada de la persona usuaria.

Una excepción oficial importante: si el cambio de contexto es en respuesta a una configuración que la persona usuaria ha configurado explícita y conscientemente — por ejemplo, un panel de preferencias donde la persona selecciona "actualizar automáticamente cada minuto" — el comportamiento automático es permisible porque la persona lo ha solicitado. La distinción clave es si la persona usuaria tomó una decisión informada y deliberada para habilitar el comportamiento automático, frente a encontrárselo de forma inesperada.

Por Qué Importa

Los cambios de contexto inesperados se encuentran entre las experiencias más desorientadoras en la web, y su impacto varía significativamente entre distintos grupos de personas usuarias con discapacidad.

Para personas ciegas que dependen de lectores de pantalla, una navegación repentina de página o una actualización de contenido puede hacer que el cursor de lectura salte a una posición completamente diferente en la página — o se reinicie al principio — sin ningún anuncio. Si una persona está a mitad de una frase en un artículo largo y la página se redirige automáticamente a una nueva URL, pierde completamente su lugar y puede no entender qué ha pasado o cómo recuperarse. Lectores de pantalla como NVDA, JAWS y VoiceOver no siempre anuncian los eventos de navegación a nivel de página de manera coherente o oportuna, por lo que las personas pueden confundirse sobre dónde están y qué ha cambiado.

Para personas con discapacidades motoras que navegan con teclado, puntero de cabeza, dispositivo de conmutación o tecnología de seguimiento ocular, los cambios de foco inesperados pueden ser catastróficos. Si el foco se mueve de forma programática sin acción de la persona usuaria — por ejemplo, cuando un formulario avanza automáticamente al siguiente campo al completar el anterior — la persona puede perder la referencia de su posición y verse obligada a volver a navegar laboriosamente para encontrar adónde la ha llevado el sistema. Para quienes utilizan dispositivos de entrada que requieren un esfuerzo físico significativo por pulsación, esta re-navegación representa una barrera de accesibilidad real.

Las personas con discapacidades cognitivas, incluidas aquellas con trastornos de atención, problemas de memoria o condiciones de ansiedad, son particularmente vulnerables a los cambios inesperados. Los cambios automáticos de página rompen su modelo mental de la interfaz. Una persona que se detiene a leer instrucciones y luego descubre que la página se ha recargado probablemente se sentirá confundida o angustiada. Esta interrupción puede hacer imposible completar transacciones o consumir información de forma independiente.

Para personas con trastornos vestibulares, los cambios visuales rápidos e inesperados — como un carrusel que avanza automáticamente y además desencadena navegación — pueden causar síntomas físicos como mareos y náuseas. Incluso las personas videntes sin discapacidad diagnosticada se benefician de interfaces predecibles: la investigación muestra de forma consistente que las navegaciones inesperadas aumentan las tasas de error y de abandono de tareas en todos los grupos de personas usuarias.

Un escenario concreto del mundo real: un sitio de comercio electrónico turco envía automáticamente un formulario de filtro de productos en el momento en que la persona selecciona un valor en un desplegable — navegando a una nueva URL de resultados de búsqueda. Una persona que solo usa teclado y que se desplaza con la tecla Tab por los filtros para seleccionar múltiples criterios descubre que al seleccionar la primera opción la página se recarga inmediatamente y el panel de filtros se colapsa. Debe volver a abrir el panel, volver a navegar hasta su posición inicial e intentarlo de nuevo — potencialmente en un bucle que hace que la función sea completamente inutilizable. Según la Organización Mundial de la Salud, aproximadamente 1,3 mil millones de personas en todo el mundo viven con algún tipo de discapacidad, y patrones como este las excluyen de forma desproporcionada de los servicios digitales.

Desde la perspectiva de usabilidad y SEO, las páginas que redirigen o se actualizan automáticamente también tienden a tener tasas de rebote más altas, ya que las personas que se encuentran con comportamientos inesperados suelen abandonar el sitio. Los motores de búsqueda también pueden penalizar las redirecciones inesperadas que difieren entre las sesiones del rastreador y de la persona usuaria, por lo que la conformidad con 3.2.5 está alineada con una buena higiene de SEO técnico.

Reglas Relacionadas de Axe-core

WCAG 3.2.5 requiere pruebas manuales porque las herramientas automatizadas no pueden detectar de forma fiable si un cambio de contexto fue iniciado por la persona usuaria o activado automáticamente. La distinción depende de comprender la intención de la persona y el flujo de interacción, lo que requiere juicio humano. Ninguna regla de axe-core se corresponde directamente con el alcance completo de este criterio. Sin embargo, las siguientes consideraciones se aplican a las pruebas automatizadas y semiautomatizadas:

• Sin regla directa de axe-core (se requieren pruebas manuales): Axe-core y Lighthouse no pueden detectar navegaciones activadas por JavaScript, páginas que se actualizan automáticamente o formularios que se envían automáticamente porque estos comportamientos dependen de condiciones de tiempo de ejecución, temporización y estado de interacción de la persona usuaria que los análisis estáticos o guiados por scripts no pueden replicar. Un escáner que observa el DOM en un único momento no puede determinar si window.location.href se está estableciendo en respuesta a un temporizador o a un clic de la persona usuaria.
• Detección de meta refresh (automatización parcial posible): Algunas herramientas automatizadas, incluidas reglas antiguas de axe y extensiones de navegador, pueden señalar la presencia de <meta http-equiv='refresh' content='0; url=...'> en la cabecera del documento. Sin embargo, axe-core no tiene una regla de producción dedicada para esto en la versión 4.10. Se requiere una inspección manual del código fuente de la página y de las cabeceras HTTP para verificar que no se esté produciendo una redirección automática.
• Análisis de listeners de eventos (manual): Detectar controladores onchange en elementos <select> que desencadenan navegación requiere una revisión manual del código o el uso de las herramientas de desarrollo del navegador para inspeccionar los listeners de eventos asociados. Los análisis automatizados observan el DOM renderizado pero no las consecuencias de comportamiento de interactuar con cada elemento.
• Verificación de la gestión del foco (manual): Determinar si el foco se mueve de forma inesperada como resultado de un cambio de contexto iniciado por el sistema — en lugar de una acción de la persona usuaria — requiere que una persona probadora interactúe realmente con la página y observe el comportamiento del foco en tiempo real, usando un teclado y, opcionalmente, un lector de pantalla.

Cómo Probar

1. Análisis automatizado (línea base): Ejecuta axe DevTools o Lighthouse en la página para detectar cualquier problema señalado relacionado con redirecciones o gestión del foco. En Chrome DevTools, abre el panel Lighthouse y ejecuta una auditoría de Accesibilidad. En la extensión axe DevTools, haz clic en "Analyze" y revisa los resultados. Ten en cuenta que un resultado automatizado limpio no confirma la conformidad con 3.2.5 — las pruebas manuales son esenciales.
2. Inspeccionar meta refresh: Abre la página en un navegador, haz clic derecho y selecciona "Ver código fuente de la página", luego busca (Ctrl+F / Cmd+F) http-equiv o refresh. Cualquier etiqueta <meta http-equiv='refresh'> con una URL o con un retraso de más de 72 horas sin un mecanismo para desactivarla constituye un fallo.
3. Observar el comportamiento de la página a lo largo del tiempo: Carga la página y espera sin interactuar durante 2–5 minutos. Observa si se producen cambios de contenido automáticos, recargas de página, eventos de navegación o apertura de nuevas ventanas. Comprueba si cambian la barra de direcciones del navegador y el título de la pestaña. Si algo de esto ocurre sin tu intervención, es probable que el criterio no se cumpla.
4. Probar controles de formulario y desplegables: Usando solo el teclado (Tab, teclas de flecha, Enter, Espacio), navega hasta cada <select>, grupo de botones de opción o casilla de verificación. Cambia valores y observa si se produce una navegación o un cambio importante de contenido inmediatamente tras la selección — antes de que actives un botón de envío. Si es así, se trata de un fallo a menos que se haya proporcionado un control para desactivar este comportamiento antes de que llegaras al elemento.
5. Probar con NVDA + Firefox: Activa NVDA (Insert+Espacio para modo exploración), navega por la página usando las teclas de flecha y Tab. Completa interacciones con formularios y observa si el foco o la posición de lectura se reubican de forma inesperada. Escucha los anuncios de cambios de página. Si el lector de pantalla anuncia una página nueva o el cursor virtual se reinicia sin tu acción explícita, esto indica un cambio de contexto.
6. Probar con VoiceOver + Safari (macOS/iOS): Activa VoiceOver (Cmd+F5 en Mac), navega usando VO+Flechas. Interactúa con los controles y escucha si hay anuncios de página inesperados o reinicios del cursor. En iOS, desliza por los elementos y observa cualquier cambio repentino en la estructura del árbol de accesibilidad que no hayas iniciado.
7. Probar con JAWS + Chrome: Activa JAWS y navega con Tab y las teclas de flecha. Envía formularios e interactúa con widgets dinámicos. Verifica que la posición del foco y del cursor virtual se mantenga predecible y bajo tu control en todo momento.
8. Revisar el código fuente JavaScript: En Chrome DevTools, usa el panel Sources o busca (Ctrl+Shift+F) patrones como window.location, location.href, history.pushState, setTimeout combinado con llamadas de navegación y atributos onchange. Evalúa si alguno de estos se activa mediante temporizadores o eventos del sistema en lugar de acciones explícitas de la persona usuaria.
9. Comprobar carruseles y sliders que avanzan automáticamente: Identifica cualquier carrusel, presentación de diapositivas o banner rotatorio en la página. Verifica si avanzan automáticamente. Si lo hacen, comprueba si también desencadenan navegación (por ejemplo, enlazando a nuevas páginas) al avanzar automáticamente. Los carruseles que avanzan automáticamente y solo cambian el contenido visible pueden abordarse en 2.2.2, pero si además provocan navegación entran dentro de 3.2.5.

Cómo Corregir

Redirección con meta refresh — Incorrecto

<!-- This meta tag automatically redirects the user after 5 seconds.
     The user has no control over this navigation. -->
<head>
  <meta http-equiv='refresh' content='5; url=https://example.com/new-page'>
</head>
<body>
  <p>You will be redirected shortly...</p>
</body>

Redirección con meta refresh — Correcto

<!-- Remove the automatic redirect entirely.
     Provide an explicit link that the user can activate on their own terms.
     This gives users full control over when navigation occurs. -->
<head>
  <!-- No meta refresh tag -->
</head>
<body>
  <p>This page has moved. Please visit the new location:</p>
  <a href='https://example.com/new-page'>Go to the updated page</a>
</body>

Elemento select que navega automáticamente al cambiar — Incorrecto

<!-- The onchange handler immediately navigates when the user selects a value.
     Keyboard users have no chance to review their selection before navigation. -->
<label for='category'>Choose a category:</label>
<select id='category' onchange='window.location.href = this.value'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>

Elemento select que navega automáticamente al cambiar — Correcto

<!-- The select element no longer triggers navigation on change.
     A clearly labeled button gives the user explicit control over when to proceed.
     This pattern works for all users, including keyboard and screen reader users. -->
<label for='category'>Choose a category:</label>
<select id='category'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>
<button type='button' onclick='navigateToCategory()'>Go to category</button>

<script>
function navigateToCategory() {
  var select = document.getElementById('category');
  if (select.value) {
    window.location.href = select.value;
  }
}
</script>

Carrusel que avanza automáticamente y desencadena navegación — Incorrecto

<!-- This carousel auto-advances every 3 seconds and each slide links to a new page.
     When the slide changes automatically, clicking anywhere on it navigates unexpectedly. -->
<div id='carousel'>
  <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale'></a>
</div>
<script>
var slides = ['/promo/summer', '/promo/winter', '/promo/spring'];
var current = 0;
setInterval(function() {
  current = (current + 1) % slides.length;
  document.querySelector('#carousel a').href = slides[current];
}, 3000);
</script>

Carrusel que avanza automáticamente y desencadena navegación — Correcto

<!-- The carousel no longer auto-advances.
     Navigation between slides and to destination pages is entirely user-controlled.
     Pause and next/previous controls satisfy both 2.2.2 and 3.2.5. -->
<div id='carousel' aria-roledescription='carousel' aria-label='Featured promotions'>
  <div role='group' aria-roledescription='slide' aria-label='1 of 3'>
    <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale — Shop now'></a>
  </div>
</div>
<div>
  <button type='button' aria-label='Previous slide' onclick='prevSlide()'>‹</button>
  <button type='button' aria-label='Next slide' onclick='nextSlide()'>›</button>
</div>

Errores Comunes

• Usar onchange en elementos <select> para activar inmediatamente la navegación con window.location.href sin proporcionar un botón de envío independiente, obligando a las personas que usan teclado a un cambio de página inmediato antes de poder confirmar su selección.
• Implementar <meta http-equiv='refresh' content='30; url=...'> para gestionar el tiempo de espera de sesión sin ofrecer a las personas un mecanismo para ampliar su sesión o desactivar la redirección automática antes de que se dispare.
• Usar setTimeout o setInterval para llamar a location.replace() o history.pushState() para funciones de "conveniencia" como el guardado automático con actualizaciones de URL, lo que mueve de forma inesperada a las personas a nuevos estados del historial del navegador.
• Abrir nuevas ventanas o pestañas del navegador usando window.open() activado por un temporizador o un proceso automatizado en lugar de por un gesto de la persona usuaria como un clic o una pulsación de tecla, lo que muchos navegadores pueden bloquear como ventana emergente y que siempre constituye un cambio de contexto no solicitado.
• Enviar automáticamente un formulario de búsqueda o filtro usando form.submit() dentro de una función debounce activada por oninput en un campo de texto — incluso con un retraso — sin proporcionar un botón de envío visible como mecanismo de control alternativo.
• Proporcionar un control para "desactivar el avance automático" que aparece solo después de que ya se haya producido la primera navegación automática, en lugar de antes. El mecanismo de exclusión debe estar disponible para las personas antes de que ocurra el primer cambio de contexto.
• Confundir actualizaciones de contenido con cambios de contexto: las regiones en vivo que actualizan texto in situ (por ejemplo, un ticker de bolsa) no son cambios de contexto y son aceptables, pero reemplazar automáticamente toda la página visible o navegar a una nueva URL sí es un cambio de contexto y entra dentro de este criterio.
• Suponer que proporcionar un cuadro de diálogo de advertencia antes de la navegación automática satisface el criterio cuando el propio cuadro de diálogo se activa automáticamente y atrapa el foco del teclado. La persona usuaria debe poder desactivar el comportamiento, no solo ser advertida sobre él.
• Usar controladores de eventos onblur u onfocusout para activar la validación de formularios y la redirección automática a una página de error o a un paso diferente en un formulario de varios pasos, sin que la persona haya solicitado explícitamente continuar.
• Implementar enrutamiento de aplicaciones de una sola página (SPA) que actualiza history.pushState en función de la profundidad de desplazamiento o del tiempo pasado en una sección — un patrón que a veces se usa para analítica — lo que constituye un cambio de contexto no iniciado y puede confundir a las personas que usan lectores de pantalla cuyo búfer virtual está vinculado al estado de la URL.

Relación con las Normativas de Accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial nº 32933 el 21 de junio de 2025, establece requisitos obligatorios de accesibilidad web alineados con WCAG 2.2 para una amplia gama de entidades que operan en Turquía. La circular abarca instituciones y organismos públicos, plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores de servicios sanitarios, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE).

La circular exige el cumplimiento de WCAG 2.2 Nivel AA como estándar base para las entidades cubiertas. WCAG 3.2.5 Cambio a Petición es un criterio de Nivel AAA y, por lo tanto, no se requiere directamente bajo el umbral legal mínimo de la circular. Sin embargo, esto no significa que deba descartarse como irrelevante en el contexto turco.

Varias categorías de entidades cubiertas tienen razones prácticas de peso para buscar la conformidad AAA con 3.2.5. Las plataformas de comercio electrónico y las agencias de viajes con grandes bases de personas usuarias suelen implementar filtrado dinámico, navegación con sugerencias automáticas y carruseles promocionales — precisamente los patrones con más probabilidades de violar este criterio. Los bancos y proveedores de servicios financieros, que gestionan transacciones sensibles donde la navegación inesperada puede causar errores o problemas de seguridad, se benefician sustancialmente de garantizar que todos los cambios de contexto estén controlados explícitamente por la persona usuaria. Los portales de salud, donde las personas pueden encontrarse en estados vulnerables y necesitan interfaces predecibles y tranquilas, representan otra categoría en la que superar la base AA con criterios AAA como 3.2.5 demuestra tanto un compromiso ético como una seguridad práctica para las personas usuarias.

Las instituciones públicas sujetas a requisitos de auditoría y reporte bajo la circular deben documentar su nivel de conformidad. Aunque el Nivel AAA no está legalmente exigido, alcanzarlo — y documentarlo — proporciona un registro defendible de compromiso con una accesibilidad de primer nivel. Para las entidades que atienden a personas con discapacidad como audiencia principal o significativa, como la autoridad de seguridad social (SGK) o los servicios de apoyo a la discapacidad, buscar la conformidad de Nivel AAA está especialmente alineado con el espíritu de la regulación.

Las organizaciones que cumplen voluntariamente con WCAG 3.2.5 también se posicionan favorablemente en el contexto de la alineación con la accesibilidad de la Unión Europea, ya que las relaciones de comercio digital de Turquía con los estados miembros de la UE implican cada vez más la accesibilidad como criterio de contratación y asociación. El Acta Europea de Accesibilidad (EAA), que entró en vigor en junio de 2025, se aplica a productos y servicios ofrecidos en los mercados de la UE — incluidos aquellos proporcionados por empresas turcas a personas usuarias europeas — y fomenta firmemente patrones de interacción controlados por la persona usuaria coherentes con 3.2.5.

En términos prácticos, los equipos de desarrollo turcos que implementan el SDK de overlay de Accsible deben asegurarse de que cualquier widget inyectado dinámicamente, panel de preferencias o control asistivo no introduzca por sí mismo cambios de contexto no iniciados. La barra de herramientas y el panel de configuración del SDK deben abrirse y cerrarse solo en respuesta a acciones explícitas de la persona usuaria, y cualquier navegación o actualización de contenido activada a través del overlay debe ser iniciada por la persona. Esto garantiza que la propia solución de accesibilidad no cree las mismas barreras que está diseñada para eliminar.