WCAG 3.2.2: Al introducir datos

Qué significa esta regla

WCAG 3.2.2 On Input forma parte del principio de Comprensible y se incluye en la Pauta 3.2 Predecible. Establece que cambiar la configuración de cualquier componente de la interfaz de usuario no debe causar automáticamente un cambio de contexto, a menos que se haya informado previamente a la persona usuaria de que se producirá dicho comportamiento.

Un cambio de contexto es un cambio importante en el contenido de una página web que puede desorientar a las personas que no pueden ver toda la página a la vez. Según la especificación WCAG, los cambios de contexto incluyen: cambios de agente de usuario (navegador), cambios de ventana gráfica (viewport), cambios de foco y cambios de contenido que alteran significativamente el significado de la página. Enviar un formulario, abrir una nueva ventana o navegar a otra página son ejemplos de cambios de contexto. Simplemente revelar contenido adicional, como un acordeón que se expande, no lo es.

El criterio se aplica específicamente a cambiar la configuración de un componente de la interfaz —por ejemplo, seleccionar un botón de opción (radio), marcar una casilla de verificación o elegir una opción en un menú desplegable <select>— en contraposición a activar un control (como hacer clic en un botón). Si una acción requiere un paso de activación explícito (presionar Enter, hacer clic en Enviar), por lo general no entra en este criterio. El patrón problemático es cuando el simple hecho de seleccionar un valor desencadena al instante una navegación o una recarga importante de la página sin ningún aviso.

Qué se considera conforme: Un formulario que utiliza un botón de envío para procesar las selecciones de la persona usuaria, incluso si esas selecciones incluyen menús desplegables o casillas de verificación, cumple este criterio. Un menú desplegable que filtra resultados en la misma página sin recargarla ni desplazar el foco de forma significativa cumple. Una página que avisa de antemano a las personas usuarias —por ejemplo, con una nota visible como "Seleccionar un idioma recargará la página"— de que una entrada concreta desencadenará un cambio de contexto también cumple.

Qué se considera incumplimiento: Un selector de país o idioma que redirige automáticamente a la persona usuaria a una nueva URL en el momento en que se elige una opción incumple. Un formulario que se envía automáticamente y navega fuera de la página cuando se selecciona un botón de opción, sin ningún botón de envío, incumple. Un widget de autocompletado que desplaza el foco del teclado a una nueva región de la página sin previo aviso al realizar una selección también incumple.

Excepciones oficiales: La especificación WCAG indica que, si se informa a la persona usuaria del comportamiento antes de usar el componente, el cambio de contexto automático es aceptable. Este aviso debe estar presente antes de que se produzca la interacción, no después.

Por qué es importante

Los cambios de contexto inesperados son una de las experiencias más desorientadoras en la web, y su impacto se amplifica de forma drástica para las personas con discapacidad. Cuando una página navega, se recarga o desplaza el foco sin aviso, las personas que no pueden ver el diseño visual completo de la página pierden totalmente la orientación.

Las personas usuarias de lectores de pantalla son especialmente vulnerables. Cuando una persona ciega que utiliza NVDA o JAWS selecciona una opción en un menú desplegable y la página se recarga o navega de inmediato, el lector de pantalla anuncia el nuevo contexto de la página desde cero. La persona pierde la referencia de dónde estaba, qué estaba haciendo y debe volver a navegar toda la página para orientarse. No es una simple molestia: puede hacer que la tarea sea completamente imposible de completar de forma independiente.

Las personas que solo usan teclado, incluidas aquellas con discapacidades motoras que no pueden usar el ratón, se enfrentan a un problema similar. Pueden estar navegando por un formulario usando Tab y las flechas y desencadenar accidentalmente un cambio de contexto que no pretendían. Sin un control motor fino, recuperarse de una navegación de página no deseada puede requerir un esfuerzo considerable.

Las discapacidades cognitivas agravan aún más el problema. Las personas con trastornos de atención, dificultades de aprendizaje o problemas de memoria dependen de interfaces predecibles y estables para entender qué está ocurriendo. Los cambios de contexto repentinos rompen el modelo mental que han construido durante la sesión, lo que a menudo les obliga a empezar de nuevo o abandonar la tarea.

Las personas con trastornos vestibulares pueden experimentar malestar físico o desorientación cuando las páginas cambian de forma inesperada, especialmente si el cambio implica animación o desplazamientos de la posición de scroll.

Un escenario concreto del mundo real: considere una página de pago de comercio electrónico en Turquía donde una persona usuaria selecciona su provincia en un menú desplegable. Si esa selección recarga la página al instante para actualizar las opciones de envío, una persona usuaria de lector de pantalla podría encontrarse de repente en la parte superior de la página sin ninguna indicación de lo que ha ocurrido. Tendría que volver a navegar por todos los campos del formulario para encontrar dónde estaba, sin saber si sus entradas anteriores se han conservado. Este tipo de fricción puede hacer que las personas abandonen la compra por completo.

Desde una perspectiva de usabilidad y SEO, las páginas que se comportan de forma predecible tienen tasas de rebote más bajas. Es menos probable que las personas usuarias se marchen frustradas, y los rastreadores de motores de búsqueda pueden indexar el contenido de forma más fiable sin que redirecciones inesperadas interfieran con las rutas de rastreo.

Reglas relacionadas de Axe-core

WCAG 3.2.2 On Input requiere pruebas manuales. Las herramientas automatizadas como axe-core no pueden detectar de forma fiable infracciones de este criterio porque el comportamiento problemático es contextual y depende de la intención detrás de una interacción, no simplemente de la presencia o ausencia de un atributo o estructura HTML específicos. Una herramienta puede identificar que un elemento <select> tiene un controlador de eventos onchange, pero no puede determinar si ese controlador desencadena un cambio de contexto, si se ha advertido a la persona usuaria sobre ello o si el comportamiento resultante es desorientador en la práctica.

• Se requiere prueba manual — Patrones de navegación con onchange: Los escáneres automatizados pueden marcar elementos <select>, <input type='radio'> y <input type='checkbox'> que tienen controladores de eventos JavaScript (en particular onchange), pero no pueden determinar si esos controladores causan un cambio de contexto. Una persona evaluadora debe interactuar con cada uno de esos controles y observar si la página navega, se recarga, desplaza el foco a una región muy diferente u abre una nueva ventana sin un paso de activación explícito por parte de la persona usuaria.
• Se requiere prueba manual — Presencia y adecuación del aviso previo: Incluso si se detecta un cambio de contexto, una herramienta automatizada no puede determinar si la persona usuaria fue advertida adecuadamente antes de interactuar con el control. Una persona debe verificar que cualquier aviso previo sea visible antes de encontrar el componente, esté redactado con claridad y describa realmente el comportamiento que se producirá.
• Se requiere prueba manual — Gestión del foco después de la entrada: Algunas infracciones se manifiestan como un desplazamiento del foco a una ubicación inesperada tras el cambio de entrada, en lugar de una navegación directa. Las herramientas automatizadas no pueden rastrear de forma fiable los destinos del foco desencadenados por eventos onchange ni confirmar si la ubicación resultante del foco constituye un cambio de contexto desorientador.

Cómo probar

1. Línea base de escaneo automatizado: Ejecute axe DevTools o Lighthouse en la página para identificar cualquier problema marcado bajo WCAG 3.2. Aunque 3.2.2 en sí requiere pruebas manuales, axe puede mostrar problemas relacionados (como etiquetas faltantes o problemas de gestión del foco) que sirvan como punto de partida. Tome nota de todos los controles de formulario —especialmente menús desplegables <select>, grupos de botones de opción y casillas de verificación— para un seguimiento manual.
2. Identificar todos los controles de entrada con controladores de cambio: En las DevTools del navegador, inspeccione el JavaScript de la página o use el panel de Event Listeners para identificar cualquier <select>, <input type='radio'>, <input type='checkbox'> o widget personalizado que tenga un listener de eventos onchange, oninput o equivalente asociado.
3. Prueba manual de interacción con teclado: Usando solo el teclado (Tab para navegar, flechas para opciones de radio/select), interactúe con cada control identificado. Observe si al seleccionar una opción la página navega, se recarga, abre una nueva ventana o mueve el foco a una parte significativamente diferente de la página. Si es así, confirme si se mostró un aviso visible antes de encontrar el control.
4. Prueba con NVDA + Firefox: Inicie Firefox con NVDA activo. Navegue hasta cada control de formulario usando el cursor virtual de NVDA (flechas) y luego interactúe usando el modo formularios (Enter o Espacio). Seleccione opciones en menús desplegables y grupos de botones de opción y escuche si hay anuncios inesperados que indiquen una carga de página, navegación o un cambio de contexto importante. Tome nota de si NVDA lee un nuevo título de página o una región dramáticamente diferente.
5. Prueba con VoiceOver + Safari (macOS/iOS): Active VoiceOver y navegue hasta cada control usando VO+Flecha derecha. Interactúe con menús desplegables y casillas de verificación. Si se produce un cambio de contexto, VoiceOver normalmente anunciará la nueva página o el desplazamiento del foco. Determine si la persona usuaria fue advertida de antemano.
6. Prueba con JAWS + Chrome: Use JAWS en modo de cursor virtual para navegar por la página. Interactúe con los controles de formulario y compruebe si JAWS anuncia un cambio de contexto (cambio de título de página, nueva URL, nueva posición de lectura) inmediatamente después de la entrada, sin que se haya activado un botón de envío.
7. Prueba de observación visual: Para personas videntes sin tecnología de apoyo, seleccione opciones en cada menú desplegable y grupo de botones de opción y observe si la página navega o se recarga de forma inesperada. Si lo hace, compruebe si algún texto de instrucciones visible antes del control advertía sobre este comportamiento.

Cómo corregir

Menú desplegable select que se envía automáticamente — Incorrecto

<!-- BAD: Selecting a country immediately redirects the page -->
<label for='country'>Select Country</label>
<select id='country' name='country' onchange='window.location.href="/region/" + this.value'>
  <option value='tr'>Turkey</option>
  <option value='de'>Germany</option>
  <option value='us'>United States</option>
</select>

Menú desplegable select que se envía automáticamente — Correcto

<!-- GOOD: Selection is confirmed via a submit button; no automatic navigation -->
<form action='/region/' method='get'>
  <label for='country'>Select Country</label>
  <select id='country' name='country'>
    <option value='tr'>Turkey</option>
    <option value='de'>Germany</option>
    <option value='us'>United States</option>
  </select>
  <!-- Explicit submit button gives the user control over when navigation occurs -->
  <button type='submit'>Go</button>
</form>

Patrón de autoenvío con botones de opción — Incorrecto

<!-- BAD: Selecting a payment method immediately submits the form -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='this.form.submit()'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='this.form.submit()'>
    Bank Transfer
  </label>
</fieldset>

Patrón de autoenvío con botones de opción — Correcto

<!-- GOOD: onchange can update UI state without navigating; submit requires user action -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='showPaymentDetails(this.value)'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='showPaymentDetails(this.value)'>
    Bank Transfer
  </label>
</fieldset>
<!-- showPaymentDetails() reveals additional fields inline — no context change -->
<div id='payment-details' aria-live='polite'></div>
<button type='submit'>Confirm Payment</button>

Cambiador de idioma con aviso previo — Correcto

<!-- ACCEPTABLE: User is warned before interacting that selecting will reload the page -->
<p id='lang-notice'>Selecting a language will immediately reload the page.</p>
<label for='lang-select'>Language</label>
<select
  id='lang-select'
  name='lang'
  aria-describedby='lang-notice'
  onchange='window.location.href="/" + this.value + "/"'
>
  <option value='en'>English</option>
  <option value='tr'>Türkçe</option>
  <option value='de'>Deutsch</option>
</select>
<!-- The aria-describedby links the warning to the control for screen reader users -->

Errores comunes

• Vincular asignaciones de window.location.href directamente al atributo onchange de un elemento <select> sin un botón de envío, lo que provoca una navegación inmediata de la página en el momento en que la persona usuaria elige una opción.
• Usar this.form.submit() dentro del controlador onchange de un botón de opción, lo que envía todo el formulario y navega fuera de la página en el instante en que se selecciona una opción, antes de que la persona usuaria pueda revisar sus elecciones.
• Colocar el aviso previo después del control en el DOM de modo que las personas usuarias de lectores de pantalla y quienes navegan con teclado se encuentren con el control antes de oír o leer la advertencia sobre el comportamiento que desencadena.
• Mostrar el aviso previo solo como un tooltip o texto de marcador de posición (placeholder) que no se expone de forma fiable a las tecnologías de apoyo, dejando a las personas usuarias de lectores de pantalla sin ninguna indicación de que un cambio de contexto seguirá a su entrada.
• Crear widgets de menú desplegable personalizados usando elementos <div> y <ul> que lanzan navegación al seleccionar mediante JavaScript pero carecen de la estructura semántica que permitiría a las personas evaluadoras o a superposiciones de accesibilidad identificarlos como controles interactivos que requieren revisión según 3.2.2.
• Desencadenar un envío automático del formulario en el último campo de un formulario (por ejemplo, una entrada de PIN u OTP) cuando se alcanza el número requerido de caracteres, sin notificar a la persona usuaria que esto ocurrirá.
• Abrir un cuadro de diálogo modal o una nueva ventana del navegador en respuesta a que se marque una casilla de verificación, sin ningún aviso previo; esto constituye un cambio de contexto porque desplaza significativamente la ventana gráfica y el foco de la persona usuaria.
• Confundir actualizaciones de contenido dentro de la página, predecibles, con cambios de contexto y añadir botones de envío innecesarios alrededor de interacciones que ya son aceptables (como un filtro de búsqueda en vivo), lo que puede saturar la interfaz; los equipos deben entender que las actualizaciones en línea que no desorientan no requieren un paso de envío.
• Confiar únicamente en escaneos automatizados de accesibilidad y marcar 3.2.2 como cumplido porque ninguna regla automatizada lo señaló, sin realizar las pruebas manuales obligatorias con teclado y lector de pantalla que este criterio exige.
• Aplicar un controlador onchange que cambia el contexto a un <select> usado para ordenar o filtrar en una lista de resultados, provocando una recarga completa de la página en lugar de una actualización mediante AJAX, y sin advertir a las personas usuarias de que esta recarga se producirá al seleccionar.

Relación con la normativa 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 basados en WCAG 2.2. WCAG 3.2.2 On Input es un criterio de Nivel A, que representa el nivel mínimo de conformidad según la circular; es decir, el cumplimiento no es opcional sino legalmente obligatorio para todas las entidades cubiertas.

La circular define un calendario de implementación de dos niveles. Las instituciones públicas —incluidos ministerios, municipios, universidades estatales y organismos gubernamentales— deben lograr la conformidad completa de Nivel A en el plazo de un año desde la publicación de la circular. Las entidades del sector privado cubiertas por la regulación disponen de un plazo de dos años para cumplirla.

Los siguientes tipos de entidades están explícitamente cubiertos por la circular y, por lo tanto, deben garantizar que sus servicios digitales cumplan con WCAG 3.2.2: plataformas de comercio electrónico, instituciones públicas en todos los niveles de gobierno, bancos e instituciones financieras, hospitales y proveedores de servicios sanitarios, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes autorizadas, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE).

Para estas entidades, una infracción de WCAG 3.2.2 —como un selector de idioma en un portal bancario que redirige automáticamente al seleccionar, o un formulario de cita de hospital que se envía automáticamente cuando se elige un botón de opción de departamento— constituye un incumplimiento normativo directo. Dado que Turquía tiene una población considerable de personas usuarias con discapacidad y que los servicios digitales gubernamentales son cada vez más el canal principal para que la ciudadanía acceda a los servicios públicos, las consecuencias prácticas de ignorar este criterio son significativas.

Las organizaciones sujetas a la circular deben tratar las pruebas de WCAG 3.2.2 como un paso de auditoría obligatorio durante el aseguramiento de calidad (QA). Como las herramientas automatizadas no pueden detectar las infracciones de este criterio, las pruebas manuales realizadas por especialistas en accesibilidad capacitados —que cubran la interacción con teclado, el comportamiento de los lectores de pantalla con NVDA y JAWS y la revisión explícita de todas las interacciones impulsadas por onchange— deben integrarse en el proceso de cumplimiento. Es recomendable documentar los resultados de las pruebas y cualquier excepción aceptada (con avisos previos implementados) para demostrar la debida diligencia ante los organismos reguladores.