WCAG 3.2.1: Al recibir el foco

Qué significa esta regla

El Criterio de Éxito 3.2.1 de WCAG, Al recibir el foco (Nivel A), establece: «Si cualquier componente recibe el foco, no inicia un cambio de contexto.» En términos sencillos, el acto de mover el foco a un elemento interactivo —presionando Tab, Shift+Tab, las teclas de flecha u otro mecanismo de teclado— no debe, por sí mismo, provocar que ocurra algo dramático e inesperado en la página.

Un cambio de contexto se define en WCAG como un cambio importante en el contenido de la página que, si se realiza sin que la persona usuaria sea consciente, podría desorientarla. La especificación identifica cuatro tipos concretos de cambio de contexto: cambios en el agente de usuario (como abrir una nueva ventana o pestaña del navegador), cambios en la ventana gráfica o viewport (como desplazarse automáticamente a una parte lejana de la página), cambios en el propio foco (como mover automáticamente el foco a otro lugar) y cambios en el contenido que alteran significativamente el significado de la página (como enviar un formulario o cargar una vista completamente diferente).

La distinción clave que establece el criterio es entre recibir el foco y activar un control. Llegar con Tab a un botón y que esto provoque que se envíe un formulario es una infracción. Pero presionar Enter o Space mientras ese botón tiene el foco —una activación intencional y deliberada— es perfectamente aceptable e incluso esperable. La intención de la persona usuaria es lo que separa una interacción predecible de una desorientadora.

Patrones habituales que incumplen este criterio incluyen:

• Un desplegable <select> que navega automáticamente a una nueva URL tan pronto como una opción recibe el foco (no cuando la persona usuaria confirma su elección).
• Un selector de fecha que abre un cuadro de diálogo modal en el momento en que cualquiera de sus campos de entrada recibe el foco, sin ninguna activación por parte de la persona usuaria.
• Un carrusel o presentación de diapositivas que avanza automáticamente a la siguiente diapositiva cuando sus puntos de navegación reciben el foco.
• Un tooltip o popover que, cuando se activa por foco, mueve simultáneamente el foco del teclado hacia sí mismo sin previo aviso, dejando a la persona usuaria en una ubicación inesperada.
• Un campo de búsqueda que envía inmediatamente y recarga la página cuando recibe el foco.

Patrones que explícitamente no son infracciones incluyen: un tooltip o panel de descripción que aparece visualmente pero no mueve el foco ni altera el contenido principal de la página; un indicador de foco (como un contorno o anillo) que aparece alrededor del elemento enfocado; o un elemento que se expande para mostrar contenido adicional en línea, siempre que el foco permanezca donde la persona usuaria lo colocó.

No hay excepciones oficiales definidas en WCAG 3.2.1. El criterio se aplica de forma universal a todos los componentes de la interfaz de usuario en una página. Sin embargo, el documento de Comprensión de WCAG señala que los cambios de contexto desencadenados por la activación deliberada de la persona usuaria (clic, Enter, Space) quedan fuera del alcance de este criterio, que solo se refiere al acto pasivo de recibir el foco.

Por qué es importante

El criterio Al recibir el foco se sitúa dentro del Principio 3 — Comprensible — porque la predictibilidad es un requisito fundamental para la usabilidad. Cuando una página se comporta de forma inesperada en respuesta únicamente al foco, las consecuencias van desde una leve confusión hasta la pérdida total de acceso, dependiendo de las necesidades y herramientas de la persona usuaria.

Las personas que solo usan teclado (personas que no pueden usar un ratón debido a discapacidades motoras, lesiones por esfuerzo repetitivo o parálisis) dependen exclusivamente de la navegación por teclado. Cuando al llegar con Tab a un campo de formulario se desencadena una recarga de la página, pueden perder todos los datos que ya han introducido y verse redirigidas lejos de su objetivo. Recuperarse de esa interrupción puede requerir un tiempo y esfuerzo significativos —o pueden simplemente abandonar por completo.

Las personas usuarias de lectores de pantalla (que a menudo también son personas que solo usan teclado) se enfrentan a una capa adicional de desorientación. Los lectores de pantalla anuncian el elemento que tiene el foco en ese momento. Si el foco salta inesperadamente a un nuevo elemento —por ejemplo, un modal que se abrió automáticamente—, el lector de pantalla anuncia el nuevo contexto sin dar a la persona usuaria ningún marco de referencia sobre qué acaba de ocurrir o por qué. Esto es análogo a que te levanten físicamente y te lleven a otra habitación sin previo aviso.

Las personas con discapacidades cognitivas, incluidas aquellas con TDAH, trastornos de ansiedad o deterioro de la memoria, dependen de interfaces predecibles para construir y mantener un modelo mental de una página. Los cambios de contexto repentinos e inexplicables rompen ese modelo, generando confusión, ansiedad y errores. Un estudio del proyecto WebAIM Million encuentra de forma consistente que los componentes interactivos complejos con comportamientos inesperados se encuentran entre las principales fuentes de quejas de accesibilidad de personas con discapacidades cognitivas.

Las personas con baja visión que utilizan software de aumento de pantalla (como ZoomText o Windows Magnifier) ven solo una pequeña parte de la pantalla a la vez. Si el foco provoca un desplazamiento o navegación automáticos, el contenido relevante puede salir completamente de su ventana gráfica ampliada, dejándolas mirando a un área en blanco o no relacionada de la pantalla.

Consideremos un escenario concreto del mundo real: el formulario de transferencia de dinero en línea de un banco turco contiene un menú desplegable para seleccionar el banco de destino. La persona desarrolladora ha implementado un evento de estilo onchange en el elemento <select> que se dispara no al confirmar, sino tan pronto como cualquier opción recibe el foco con las teclas de flecha. Una persona usuaria de lector de pantalla que llega con Tab al campo y presiona la flecha hacia abajo para explorar los bancos disponibles desencadena inmediatamente el envío del formulario o la recarga de la página. Nunca completa la transferencia y no puede determinar qué salió mal. Este escenario no es hipotético: fue un patrón documentado en muchas aplicaciones de una sola página tempranas.

Más allá de la accesibilidad, hay beneficios tangibles de usabilidad y de negocio. Los formularios que no secuestran el foco tienen tasas de abandono más bajas. Las páginas que se comportan de forma predecible obtienen mejores resultados en pruebas de usabilidad con todo tipo de audiencias. Los rastreadores de motores de búsqueda también se benefician de flujos de navegación predecibles, ya que las redirecciones inesperadas desencadenadas por eventos de foco pueden confundir la lógica de rastreo en ciertos escenarios de renderizado dinámico.

Reglas relacionadas de Axe-core

WCAG 3.2.1 Al recibir el foco requiere pruebas manuales porque las herramientas automatizadas no pueden determinar de forma fiable la intención de la persona usuaria ni predecir todos los posibles cambios de contexto. Axe-core y escáneres automatizados similares pueden analizar HTML estático y atributos ARIA, pero no pueden observar el comportamiento de JavaScript en tiempo de ejecución en respuesta a eventos de foco, especialmente si ese comportamiento constituye un cambio de contexto «importante» según la definición de WCAG. Un script que mueve el foco, envía un formulario o navega a una URL en el evento focus es invisible para un escáner estático a menos que la herramienta realmente simule interacciones de foco en cada elemento interactivo y luego analice qué cambió en el DOM, el viewport y la URL después. Este nivel de simulación de comportamiento no es alcanzable de forma fiable en un análisis automatizado sin una tasa de falsos positivos prohibitiva.

• Se requiere prueba manual — Cambio de contexto al recibir el foco: Las personas evaluadoras deben recorrer manualmente con Tab todos los elementos interactivos de la página (enlaces, botones, campos de entrada, selects, widgets personalizados) y observar si el foco por sí solo —sin ninguna activación— desencadena un cambio de contexto según la definición de WCAG. Esto incluye vigilar cambios de URL, apertura de nuevas ventanas o pestañas, movimiento del foco fuera del elemento actual, envíos de formularios y reemplazos importantes de contenido. Las herramientas automatizadas marcan los listeners de eventos de JavaScript asociados a eventos relacionados con el foco (focus, focusin, onfocus) como candidatos para revisión manual, pero no pueden determinar si esos controladores provocan un cambio de contexto descalificador.

Cómo probar

1. Preanálisis automatizado: Ejecuta axe DevTools (extensión del navegador o CLI) o Google Lighthouse sobre la página. Aunque ninguna de las dos herramientas puede señalar de forma definitiva infracciones de Al recibir el foco, axe DevTools puede mostrar problemas relacionados con la gestión del foco (como patrones de scrollable-region-focusable o trampas de foco) que merecen una inspección manual más detallada. Utiliza el panel «Needs Review» de axe DevTools: los elementos marcados allí suelen estar relacionados con comportamientos de componentes interactivos que requieren juicio humano.
2. Identificar todos los elementos interactivos: Antes de las pruebas con teclado, haz una lista de todos los componentes interactivos: enlaces, botones, campos de formulario, desplegables, casillas de verificación, botones de opción, selectores de fecha, carruseles, acordeones, pestañas, modales y cualquier widget personalizado que use tabindex. Presta especial atención a los widgets personalizados de JavaScript que escuchan eventos focus o focusin.
3. Prueba de navegación solo con teclado: Usando únicamente el teclado (sin ratón), presiona Tab de forma secuencial a través de cada elemento enfocable de la página. Después de cada pulsación de Tab, antes de presionar cualquier otra cosa, observa: ¿Cambió la URL? ¿Se abrió una nueva ventana o pestaña? ¿Se movió el foco fuera del elemento al que acabas de llegar con Tab? ¿Se envió un formulario? ¿Cambió drásticamente el contenido principal de la página? Cualquier respuesta «sí» es un posible incumplimiento.
4. Prueba de elementos select: Pon el foco en cualquier desplegable <select>. Usa las flechas Arriba y Abajo para moverte por las opciones sin presionar Enter o Space. Verifica que al navegar por las opciones no se desencadene ninguna navegación, envío de formulario ni cambio de contexto. Este es uno de los patrones que se incumplen con más frecuencia.
5. NVDA + Firefox: Activa NVDA (gratuito, para Windows). Abre Firefox y navega a la página. Presiona Tab a través de todos los elementos interactivos. Escucha los anuncios de NVDA: si NVDA comienza a anunciar una parte completamente diferente de la página o un nuevo contexto de página después de una pulsación de Tab (sin que hayas presionado Enter o Space), esto es una fuerte señal de incumplimiento.
6. JAWS + Chrome: Activa JAWS. Abre Chrome. Usa Tab para navegar. JAWS anunciará cada elemento enfocado. Vigila anuncios inesperados de nuevos diálogos, páginas o ubicaciones de foco a las que no navegaste deliberadamente.
7. VoiceOver + Safari (macOS/iOS): Activa VoiceOver (Cmd+F5 en macOS). Navega con Tab (o deslizando en iOS). Vigila cambios de contexto inesperados. En iOS, prueba también con acceso por interruptores para simular a personas con discapacidades motoras graves que navegan mediante escaneo.
8. Inspección de listeners de eventos en las DevTools del navegador: En Chrome DevTools, selecciona cualquier elemento interactivo sospechoso, ve al panel Elements y haz clic en «Event Listeners». Busca listeners focus o focusin. Si existen, revisa el JavaScript asociado para determinar si el controlador desencadena navegación, envío de formularios, movimiento de foco u otras acciones que cambien el contexto.

Cómo corregir

Desplegable select que envía automáticamente — Incorrecto

<!-- FAIL: Selecting an option via arrow key immediately navigates to a new URL -->
<label for='region'>Select Region</label>
<select id='region' onchange='window.location = this.value;'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>

Desplegable select que envía automáticamente — Correcto

<!-- PASS: Navigation only occurs when the user explicitly activates the Go button -->
<label for='region'>Select Region</label>
<select id='region'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>
<button type='button' onclick='navigateToRegion()'>Go</button>

<script>
function navigateToRegion() {
  var select = document.getElementById('region');
  window.location = select.value; // Only fires on deliberate button activation
}
</script>

Modal que se abre al enfocar un campo de entrada — Incorrecto

<!-- FAIL: Focusing the date input immediately opens a modal dialog and moves focus -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' onfocus='openDatePickerModal()' />

<script>
function openDatePickerModal() {
  var modal = document.getElementById('date-modal');
  modal.style.display = 'block';
  modal.querySelector('button').focus(); // Moves focus away without user intent
}
</script>

Modal que se abre al enfocar un campo de entrada — Correcto

<!-- PASS: The date picker opens only when the user explicitly clicks or presses Enter/Space -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' readonly aria-haspopup='dialog'
       aria-label='Departure Date — press Enter to open date picker' />
<button type='button' id='open-picker'
        aria-controls='date-modal'
        onclick='openDatePickerModal()'>
  Choose Date
</button>

<script>
function openDatePickerModal() {
  // Only called on explicit activation (click or Enter/Space on the button)
  var modal = document.getElementById('date-modal');
  modal.removeAttribute('hidden');
  modal.querySelector('[data-initial-focus]').focus();
}
</script>

Carrusel que avanza automáticamente al recibir el foco — Incorrecto

<!-- FAIL: Focusing a navigation dot advances the carousel slide, changing page content -->
<div class='carousel-dots'>
  <button class='dot' onfocus='showSlide(0)'>1</button>
  <button class='dot' onfocus='showSlide(1)'>2</button>
  <button class='dot' onfocus='showSlide(2)'>3</button>
</div>

Carrusel que avanza automáticamente al recibir el foco — Correcto

<!-- PASS: The carousel only changes slides when the dot is explicitly activated (click/Enter) -->
<div class='carousel-dots' role='tablist' aria-label='Carousel navigation'>
  <button class='dot' role='tab' aria-selected='true'
          aria-controls='slide-0' onclick='showSlide(0)'>
    Slide 1
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-1' onclick='showSlide(1)'>
    Slide 2
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-2' onclick='showSlide(2)'>
    Slide 3
  </button>
</div>
<!-- onclick only fires on deliberate activation, not on Tab focus -->

Errores comunes

• Usar onfocus como sustituto de onclick en elementos de navegación: A veces las personas desarrolladoras asocian controladores onfocus a enlaces o botones de navegación para «precargar» un destino, desencadenando accidentalmente una navegación completa en lugar de solo una precarga. Utiliza siempre onclick o onkeydown (comprobando Enter/Space) para cualquier acción que cambie el contexto.
• Vincular onchange en elementos <select> sin una acción de envío: En navegadores de escritorio, onchange en un <select> se dispara cuando se confirma una opción, pero en algunas implementaciones antiguas y en ciertos navegadores móviles puede dispararse a medida que las teclas de flecha se mueven por las opciones. Asocia siempre la navegación basada en select con un botón de envío explícito o utiliza un <form> con un <button type='submit'>.
• Mover el foco mediante programación dentro de un controlador de evento focus: Llamar a element.focus() dentro del controlador onfocus o focusin de otro elemento crea un salto de foco inesperado. Esto es una infracción directa: la persona usuaria llegó con Tab al elemento A y el foco se movió silenciosamente al elemento B. Mueve el foco solo en respuesta a acciones deliberadas de la persona usuaria.
• Abrir cuadros de diálogo modales en eventos de foco de cualquier elemento disparador: Un atajo habitual es asociar un controlador de apertura de modal al evento focus de un botón o campo de entrada disparador. Los modales solo deben abrirse en respuesta a un clic, la tecla Enter o la tecla Space, nunca solo al recibir el foco.
• Reproducir automáticamente medios o animaciones que cambian el contexto del viewport al recibir el foco: Un banner principal que inicia un video a pantalla completa o una animación grande en el momento en que su botón de reproducción recibe el foco cambia significativamente el contexto visual. Asocia las acciones de reproducción a eventos de activación, no a eventos de foco.
• Desencadenar actualizaciones de regiones en vivo que desplazan la página hacia contenido nuevo al recibir el foco: Algunos widgets dinámicos actualizan una región en vivo y luego desplazan el viewport hacia esa región tan pronto como un campo de entrada recibe el foco. Esto cambia el contexto del viewport y desorienta a las personas usuarias de ampliadores de pantalla. Desacopla las actualizaciones de regiones en vivo de los eventos de foco siempre que sea posible.
• Implementar trampas de foco personalizadas que atrapan inmediatamente a las personas usuarias sin avisar: Un componente personalizado que intercepta todas las pulsaciones de Tab en el momento en que recibe el foco, sin anunciar a la persona usuaria que se encuentra dentro de una trampa de foco, infringe tanto la letra como el espíritu de este criterio. Las trampas de foco solo son apropiadas dentro de cuadros de diálogo modales completamente abiertos, y se debe informar a las personas usuarias de cómo salir.
• Usar CSS :focus para activar display: block en menús desplegables que contienen elementos enfocables, provocando movimientos de foco inesperados en cascada: Los menús controlados solo por foco en CSS que revelan elementos enfocables pueden causar saltos confusos cuando el orden de foco del navegador se mueve después a los elementos recién visibles. Asegúrate de que los menús revelados sean esperables y estén claramente comunicados mediante atributos ARIA como aria-expanded.
• Confiar en bibliotecas de widgets de terceros sin auditar su comportamiento de foco: Muchas bibliotecas de componentes de interfaz (selectores de fecha, editores de texto enriquecido, desplegables tipo select2) han infringido históricamente el 3.2.1 abriendo ventanas emergentes o moviendo el foco en eventos focus. Audita siempre los componentes de terceros manualmente antes de su despliegue, independientemente de las afirmaciones de accesibilidad de la biblioteca.
• Olvidar probar en contextos de enrutamiento de aplicaciones de una sola página (SPA): En SPAs de React, Vue y Angular, los eventos de foco en enlaces de navegación a veces pueden desencadenar cambios de ruta mediante la lógica de prefetch del enrutador o la propagación de eventos, especialmente cuando los eventos de foco no se detienen correctamente. Prueba explícitamente los componentes de navegación de SPAs para verificar el cumplimiento del 3.2.1.

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 que hacen referencia explícita a WCAG 2.2 como estándar técnico. WCAG 3.2.1 Al recibir el foco es un criterio de Nivel A, lo que significa que se sitúa en la base del cumplimiento obligatorio según la circular. No hay exenciones para los criterios de Nivel A: todas las entidades cubiertas deben cumplirlos dentro de los plazos definidos.

Las instituciones públicas están obligadas a lograr la conformidad total en un plazo de un año a partir de la fecha de publicación de la circular. Las entidades del sector privado incluidas en el alcance disponen de dos años. Las entidades cubiertas por la Circular Presidencial 2025/10 incluyen una amplia gama de organizaciones: todas las instituciones y organismos públicos, plataformas de comercio electrónico y mercados en línea, bancos e instituciones financieras, hospitales y proveedores de atención sanitaria privados, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes y plataformas de reserva, empresas de transporte privado y escuelas e instituciones educativas privadas autorizadas por el Ministerio de Educación Nacional (MoNE).

La relevancia de WCAG 3.2.1 Al recibir el foco para estos tipos de entidades es directa y práctica. Pensemos en una plataforma de comercio electrónico donde un desplegable de categorías de productos navega automáticamente al recibir el foco: una persona cliente que usa teclado y tiene una discapacidad motora no puede explorar las categorías de productos y abandonará la compra. Un formulario de transferencia en línea de un banco con envíos desencadenados por el foco podría provocar transacciones financieras no deseadas o intentos fallidos repetidos para personas usuarias de lectores de pantalla. Un sistema de reserva de citas de un hospital donde los campos de fecha abren modales al recibir el foco puede impedir que pacientes con discapacidad programen su atención de forma independiente.

Según la circular, el incumplimiento expone a las entidades cubiertas a sanciones administrativas y riesgo reputacional. Para las entidades que actualmente están en procesos de transformación digital o adquiriendo nuevos sistemas web, incorporar ahora el cumplimiento de WCAG 3.2.1 en los requisitos de contratación y en las directrices para desarrolladores —en lugar de adaptar después de una queja— es tanto más rentable como más coherente con el espíritu de la regulación. Las organizaciones que utilizan el SDK de overlay de Accsible se benefician de herramientas integradas de gestión del foco que ayudan a identificar y remediar comportamientos inesperados al recibir el foco como parte de un flujo de trabajo más amplio de cumplimiento de WCAG 2.2 de Nivel A.