WCAG 2.4.3: Orden de foco

Qué Significa Esta Regla

WCAG 2.4.3 Orden de Foco es un criterio de éxito de Nivel A bajo el principio de Operable. Establece: «Si una página web puede ser navegada secuencialmente y las secuencias de navegación afectan al significado o al funcionamiento, los componentes enfocables reciben el foco en un orden que preserve el significado y la operabilidad.»

En términos prácticos, esto significa que cuando una persona usuaria pulsa la tecla Tab para moverse por los elementos interactivos de una página —enlaces, botones, campos de formulario, widgets personalizados y cualquier otro componente enfocable—, la secuencia en la que esos elementos reciben el foco debe tener sentido lógico. Las personas usuarias no deberían encontrarse saltando inesperadamente desde la mitad de un formulario a un enlace del pie de página, luego de vuelta a un botón de un modal y después a un elemento del menú de navegación.

El criterio se aplica a la navegación secuencial por teclado, que es la forma principal en que las personas que solo usan teclado y las personas usuarias de lectores de pantalla recorren una página. El orden del DOM es la fuente predeterminada del orden de foco en los navegadores: los elementos aparecen en la secuencia de tabulación en el orden en que aparecen en el Document Object Model (DOM), a menos que CSS o JavaScript alteren deliberadamente ese orden. Surgen problemas cuando el diseño visual se desvía del orden del DOM (por ejemplo, mediante reordenamiento con CSS Flexbox o Grid), o cuando los valores de tabindex imponen una secuencia antinatural.

Qué se considera un cumplimiento: El orden de foco debe ser lógico y significativo —no necesariamente idéntico al orden visual de lectura, pero lo suficientemente coherente como para que las personas usuarias puedan entender y operar la página. Un cuadro de diálogo modal que mueve el foco hacia sí mismo cuando se abre, mantiene el foco atrapado dentro mientras está abierto y devuelve el foco al elemento que lo activó cuando se cierra cumple este criterio. Un formulario de varios pasos donde Tab avanza por cada campo en el orden en que una persona usuaria los rellenaría (de arriba abajo, de izquierda a derecha en idiomas de izquierda a derecha) también cumple.

Qué se considera un incumplimiento: Que el foco salte desde el campo «Nombre de usuario» de un formulario de inicio de sesión a un banner promocional completamente no relacionado antes de llegar al campo «Contraseña» es un incumplimiento. Una aplicación de una sola página que abre un diálogo pero deja el foco en la página de fondo incumple. Usar valores enteros positivos de tabindex (por ejemplo, tabindex='2', tabindex='5') que fuerzan una secuencia de tabulación ilógica en toda la página también incumple.

Excepciones oficiales: WCAG señala explícitamente que el orden de foco no necesita coincidir con el orden visual de lectura siempre que preserve el significado y la operabilidad. También se permite que, en los casos en que las secuencias de navegación no afecten al significado o al funcionamiento —por ejemplo, una página con un solo elemento enfocable no tiene una secuencia que evaluar—, no se aplique el criterio. Además, cuando hay múltiples ordenaciones válidas que todas preservan el significado, cualquiera de esas ordenaciones es aceptable.

Los mecanismos clave de HTML y JavaScript que afectan al orden de foco incluyen: el orden natural del DOM de los elementos interactivos, el atributo tabindex (en particular los valores enteros positivos), las propiedades CSS que reordenan el diseño visual sin cambiar el DOM (como order en Flexbox/Grid, position: absolute y float), la gestión del foco impulsada por JavaScript (llamando a .focus() en elementos) y los patrones de diálogo ARIA que requieren una gestión explícita del foco.

Por Qué Importa

El orden de foco no es un detalle técnico menor: es la columna vertebral de la navegación web para una parte significativa de las personas usuarias. Varios grupos de discapacidad distintos dependen de una secuencia de foco lógica para usar productos digitales de forma eficaz.

Las personas con discapacidad motora que no pueden usar un ratón dependen por completo del teclado (o de dispositivos equivalentes al teclado, como interruptores de soplo y succión, punteros de cabeza o sistemas de seguimiento ocular) para navegar. Para estas personas, un orden de foco desordenado no es simplemente una molestia: puede hacer que una página sea completamente inutilizable. Si la tecla Tab lleva a una persona usuaria a la parte equivocada de la página, puede que no tenga una forma eficiente de llegar al control que necesita, y no puede simplemente mover la mano para hacer clic en otro lugar.

Las personas ciegas y con baja visión que usan lectores de pantalla como NVDA, JAWS o VoiceOver escuchan los elementos anunciados a medida que el foco se posa en ellos. Un orden de foco lógico significa que el flujo de audio que reciben refleja el flujo previsto de la interfaz. Cuando el foco salta de forma errática, las personas usuarias pierden su modelo mental de dónde se encuentran en la página. Según la Organización Mundial de la Salud, aproximadamente 2.2 billion people worldwide have some form of vision impairment, y para muchas de las que usan lectores de pantalla, el orden de foco es su forma principal de experimentar la estructura de la página.

Las personas con discapacidades cognitivas también se benefician de secuencias de foco predecibles. Un salto de foco inesperado en medio de un formulario puede causar confusión, obligar a las personas usuarias a reiniciar flujos de trabajo o hacer que pasen por alto campos obligatorios. Las personas con dificultades de atención o desafíos de memoria a corto plazo necesitan una navegación coherente y predecible para generar confianza al usar un sitio.

Un escenario concreto del mundo real: Imagina una página de pago de comercio electrónico turca. El diseño visual usa CSS Grid para colocar el resumen del pedido a la izquierda y el formulario de pago a la derecha. Sin embargo, en el DOM, el formulario de pago aparece primero y el resumen del pedido en segundo lugar. El diseño visual se ve correcto para las personas videntes que usan ratón, pero una persona usuaria de teclado que pulse Tab llegará a los campos del formulario de pago antes de haber tenido la oportunidad de revisar el resumen del pedido. Podría confirmar sin saberlo un pedido incorrecto. Peor aún, si un botón de «Confirmar compra» recibe el foco antes que un campo de «Aplicar cupón» debido a una mala gestión de tabindex positivo, una persona usuaria podría enviar accidentalmente una compra que pretendía descontar. Esta es una consecuencia financiera real y directa de un orden de foco roto.

Más allá de la accesibilidad, un orden de foco lógico mejora la experiencia de las personas usuarias avanzadas que prefieren la navegación por teclado por rapidez. También respalda indirectamente el SEO: un DOM bien estructurado que produce un orden de foco natural tiende a reflejar un marcado semántico significativo, que los motores de búsqueda utilizan para entender la jerarquía e importancia del contenido.

Reglas Relacionadas de Axe-core

WCAG 2.4.3 requiere pruebas manuales para una evaluación definitiva. Las herramientas automatizadas como axe-core no pueden determinar algorítmicamente si una secuencia de foco concreta «preserva el significado y la operabilidad»; ese juicio requiere una persona que entienda el propósito de la página y las relaciones entre contenidos. Sin embargo, axe-core y herramientas relacionadas pueden señalar ciertos patrones que son fuertes indicadores de problemas de orden de foco:

• tabindex (valores positivos) — indicador heurístico: Algunas herramientas de linting y auditoría advierten cuando los elementos tienen valores enteros positivos de tabindex (cualquier valor mayor que 0). Los valores positivos de tabindex anulan el orden natural del DOM y colocan esos elementos al frente de la secuencia de tabulación, lo que casi siempre crea un orden de foco ilógico e impredecible. Aunque el conjunto de reglas principal de axe-core no incluye una regla automatizada dedicada a «focus-order» (porque la corrección lógica de la secuencia no puede calcularse), herramientas como axe DevTools Pro y las auditorías manuales revisan específicamente el uso de tabindex positivo como indicador indirecto.
• scrollable-region-focusable: Axe-core incluye una regla que señala las regiones desplazables que no son enfocables por teclado. Aunque no es directamente una regla de orden de foco, una región desplazable que no puede recibir el foco rompe la secuencia de navegación general, haciendo que las personas usuarias de teclado se salten contenido con el que necesitan interactuar.
• Inspección manual de contenido reordenado con CSS: Las herramientas automatizadas no pueden detectar cuándo el order de CSS Flexbox o la colocación en Grid crean una discrepancia entre el orden visual y el orden del DOM. Una persona evaluadora debe comparar visualmente el diseño en pantalla con la secuencia de foco observada durante la navegación por teclado. Esta es la fuente más común de fallos de 2.4.3 en diseños responsivos modernos y es completamente invisible para los escáneres automatizados.
• Inspección manual de la gestión de foco en JavaScript en contenido dinámico: Las aplicaciones de una sola página, las implementaciones de scroll infinito, los modales y los menús desplegables requieren JavaScript para mover el foco adecuadamente a medida que el contenido cambia. Las herramientas automatizadas ejecutan una instantánea estática del DOM y no pueden simular la secuencia de interacciones de la persona usuaria necesaria para activar estos escenarios de gestión de foco. Solo las pruebas manuales con teclado pueden verificar que el foco se mueve a un modal recién abierto, vuelve al disparador correcto al cerrarse y no deja a la persona usuaria atrapada en una capa de fondo inaccesible.

Cómo Probar

1. Escaneo automatizado como punto de partida: Ejecuta axe DevTools (extensión del navegador) o Google Lighthouse en la página. Busca cualquier advertencia sobre valores positivos de tabindex y regiones desplazables señaladas. Ten en cuenta que un resultado automatizado limpio no significa que se cumpla 2.4.3: las pruebas manuales siempre son necesarias. Registra cualquier problema señalado para su investigación posterior.
2. Desconecta el ratón y navega solo con Tab: Empezando desde la barra de direcciones del navegador o la parte superior de la página, pulsa Tab repetidamente para moverte por cada elemento enfocable. Observa la secuencia con atención. Pregúntate: ¿se mueve el foco en un orden que coincide con el flujo lógico de lectura e interacción de la página? ¿El foco salta alguna vez a un área inesperada? ¿Alguna vez queda atrapado (sin poder avanzar ni retroceder) excepto dentro de un diálogo intencional?
3. Prueba los componentes dinámicos: Activa cualquier modal, cuadro de diálogo, menú desplegable, acordeón, panel de pestañas, selector de fecha u otros widgets interactivos usando el teclado. Verifica que el foco se mueva al contenido recién revelado inmediatamente tras la activación. Después de cerrar un diálogo, confirma que el foco vuelve al elemento que lo activó, no a la parte superior de la página ni a una ubicación arbitraria.
4. Prueba con NVDA + Firefox: Abre NVDA, inicia Firefox y navega a la página. Usa Tab para moverte por los elementos interactivos y escucha los anuncios. Verifica que la secuencia anunciada tenga sentido en contexto. Usa el modo de exploración de NVDA (teclas de flecha) para leer el contenido estático y confirma que el orden de lectura se alinea con el orden de foco de los elementos interactivos dentro de ese contenido.
5. Prueba con VoiceOver + Safari (macOS/iOS): Activa VoiceOver y usa Tab (en escritorio) o gestos de deslizamiento (iOS) para moverte por los elementos enfocables. Confirma que la secuencia de foco sea lógica. En iOS, prueba que los modales y superposiciones atrapen el foco correctamente y lo devuelvan al cerrarse.
6. Prueba con JAWS + Chrome: Usa la navegación con Tab de JAWS y confirma que la secuencia de foco anunciada sea coherente. Usa el cursor virtual de JAWS para cotejar el orden de lectura con el orden de foco de los elementos interactivos e identificar cualquier discrepancia.
7. Inspecciona el DOM frente al diseño visual: Abre las DevTools del navegador y examina la estructura del DOM. Compara el orden de los elementos interactivos en el DOM con su posición visual en pantalla. Si propiedades CSS como order, position: absolute o float están creando diferencias significativas, sigue manualmente la secuencia de tabulación para determinar si se ve afectado el significado o la operabilidad.
8. Revisa los valores de tabindex en el DOM: En la consola del navegador, ejecuta document.querySelectorAll('[tabindex]') para listar todos los elementos con atributos tabindex explícitos. Investiga cualquier elemento con un valor entero positivo y evalúa si su ubicación en el orden de tabulación modificado es lógica.

Cómo Corregir

Valores positivos de tabindex que crean un orden ilógico — Incorrecto

<!-- Positive tabindex values force an unnatural tab sequence -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email' tabindex='3'>

  <label for='name'>Full Name</label>
  <input type='text' id='name' tabindex='1'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone' tabindex='2'>

  <button type='submit' tabindex='4'>Submit</button>
</form>
<!-- Tab order: Full Name → Phone → Email → Submit
     Visual/logical order: Email → Full Name → Phone → Submit
     This mismatch breaks focus order. -->

Valores positivos de tabindex que crean un orden ilógico — Correcto

<!-- Remove all positive tabindex values; rely on DOM order.
     Rearrange DOM to match the logical sequence. -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email'>

  <label for='name'>Full Name</label>
  <input type='text' id='name'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone'>

  <button type='submit'>Submit</button>
</form>
<!-- Tab order now follows DOM order: Email → Full Name → Phone → Submit
     Matches logical and visual order. No tabindex needed. -->

Reordenamiento visual con CSS que no coincide con el orden del DOM — Incorrecto

<!-- DOM has sidebar first, main content second.
     CSS uses flexbox order to visually flip them.
     Keyboard users tab through sidebar links before main content links,
     which does not match what a sighted user sees first. -->
<style>
  .layout { display: flex; }
  .sidebar { order: 2; } /* Visually shown on the right */
  .main    { order: 1; } /* Visually shown on the left */
</style>

<div class='layout'>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
</div>
<!-- Focus order: About → Contact → Read Article
     Visual order: Read Article → About → Contact
     Mismatch breaks 2.4.3 -->

Reordenamiento visual con CSS que no coincide con el orden del DOM — Correcto

<!-- Fix: reorder the DOM to match the intended visual and logical order.
     Remove the CSS 'order' overrides that caused the mismatch. -->
<style>
  .layout { display: flex; }
  /* No 'order' overrides — DOM order determines both visual and tab order */
</style>

<div class='layout'>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
</div>
<!-- DOM order, visual order, and focus order now all match. -->

Cuadro de diálogo modal que no gestiona el foco — Incorrecto

<!-- Button opens a modal, but focus stays on the background page.
     Keyboard users cannot interact with the dialog. -->
<button id='open-modal' onclick='document.getElementById("dialog").style.display="block"'>
  Open Settings
</button>

<div id='dialog' style='display:none;'>
  <h2>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>
<!-- When dialog opens, focus remains on #open-modal in the background.
     Tab continues to background page elements, not dialog elements. -->

Cuadro de diálogo modal que no gestiona el foco — Correcto

<!-- Focus is moved into the dialog on open and returned to trigger on close.
     role='dialog' and aria-modal='true' inform screen readers of the context. -->
<button id='open-modal'>Open Settings</button>

<div id='dialog'
     role='dialog'
     aria-modal='true'
     aria-labelledby='dialog-title'
     style='display:none;'>
  <h2 id='dialog-title'>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>

<script>
  const openBtn = document.getElementById('open-modal');
  const dialog  = document.getElementById('dialog');
  const closeBtn = document.getElementById('close-modal');

  openBtn.addEventListener('click', () => {
    dialog.style.display = 'block';
    // Move focus to first focusable element in dialog
    document.getElementById('theme').focus();
  });

  closeBtn.addEventListener('click', () => {
    dialog.style.display = 'none';
    // Return focus to the element that triggered the dialog
    openBtn.focus();
  });
</script>
<!-- Focus order is now logical: trigger → dialog contents → back to trigger. -->

Errores Comunes

• Usar valores enteros positivos de tabindex (por ejemplo, tabindex='1', tabindex='5') para «controlar» el orden de foco en lugar de corregir la estructura del DOM. Los valores positivos de tabindex colocan los elementos por delante de todos los elementos enfocables de forma natural en la página, creando una secuencia global de tabulación caótica que es extremadamente difícil de mantener y casi siempre introduce errores.
• Aplicar order de CSS en Flexbox o CSS Grid para reordenar el contenido visualmente sin reordenar el DOM, y luego no probar la navegación por teclado. El diseño visual se ve correcto para las personas videntes, pero la secuencia de tabulación sigue el orden del DOM, no el orden visual, una discrepancia invisible pero grave para las personas usuarias de teclado.
• Abrir un modal o cuadro de diálogo sin mover el foco hacia él de forma programática usando el método .focus() de JavaScript. Las personas usuarias de lectores de pantalla y teclado permanecen varadas en el contenido de fondo, a menudo sin poder encontrar o interactuar con el diálogo.
• No devolver el foco al elemento que activó un modal, cajón o menú desplegable después de cerrarlo. Devolver el foco a la parte superior de la página o dejarlo en un elemento ahora oculto obliga a las personas usuarias a volver a navegar desde el principio, perdiendo su lugar en una página potencialmente larga.
• Insertar contenido cargado dinámicamente (por ejemplo, un mensaje de error en línea, una notificación emergente o una sección cargada de forma diferida) en el DOM después de elementos enfocables que lo preceden visualmente, de modo que las personas usuarias de teclado se encuentren con el contenido nuevo fuera de secuencia o no lo encuentren en absoluto.
• Usar tabindex='-1' para eliminar elementos de la secuencia de tabulación sin proporcionar un medio alternativo de acceso por teclado. Aunque tabindex='-1' en sí es una herramienta válida (hace que un elemento sea enfocables de forma programática pero lo elimina del orden natural de tabulación), aplicarlo incorrectamente a controles a los que las personas usuarias realmente necesitan acceder equivale a ocultar esos controles a las personas usuarias de teclado.
• Crear transiciones de rutas en aplicaciones de una sola página que restablecen el foco al cuerpo del documento o a la interfaz del navegador en lugar de mover el foco al nuevo encabezado de página o a un punto de salto de navegación. Las personas usuarias se ven obligadas a pulsar Tab por toda la navegación en cada cambio de ruta.
• Implementar widgets personalizados de carrusel o slider donde no se implementa la navegación con teclas de flecha y Tab mueve el foco por cada diapositiva oculta, obligando a las personas usuarias a pulsar Tab por docenas de elementos fuera de pantalla antes de llegar al contenido posterior de la página.
• Colocar un enlace de salto de navegación «invisible» en el DOM que siempre está con display:none (en lugar de ocultarlo visualmente con una técnica .sr-only / clip). Un enlace con display:none se elimina por completo del orden de tabulación y no ofrece ningún beneficio, mientras que un enlace de salto correctamente implementado recibe el foco al pulsar Tab y se vuelve visible, apoyando directamente un flujo lógico de foco hacia el contenido principal.
• Anidar elementos interactivos dentro de otros elementos interactivos (por ejemplo, un <button> dentro de una etiqueta <a>), lo que produce un comportamiento de tabulación inconsistente entre navegadores y puede hacer que el foco se pose en el mismo control lógico varias veces o que lo omita por completo.

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

WCAG 2.4.3 Orden de Foco es directamente relevante para la histórica legislación de accesibilidad de Turquía: la Circular Presidencial 2025/10, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025. Esta circular establece normas obligatorias de accesibilidad web para una amplia gama de entidades del sector público y privado que operan en Turquía, exigiendo la conformidad con directrices reconocidas internacionalmente, incluidas todas las pautas de éxito de Nivel A de WCAG 2.x, entre las que se encuentra 2.4.3.

La circular abarca un amplio conjunto de tipos de entidades. Las instituciones públicas, incluidos ministerios, municipios, universidades estatales y organismos gubernamentales, deben lograr la conformidad total en el plazo de un año a partir de la fecha de publicación de la circular. Las entidades del sector privado en las categorías cubiertas deben alcanzar el mismo nivel de conformidad en el plazo de dos años. Las categorías cubiertas del sector privado incluyen plataformas de comercio electrónico, 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, empresas de transporte privadas y escuelas privadas que operan bajo autorización del Ministerio de Educación Nacional (MoNE).

Para todas estas organizaciones, un orden de foco roto o ilógico no es simplemente una deficiencia de usabilidad: es un caso de incumplimiento normativo que puede exponer a la entidad a consecuencias legales y administrativas en virtud de las disposiciones de aplicación de la circular. Considera el portal de banca en línea de un banco turco donde el orden de foco en la pantalla de transferencia de fondos salta del campo de importe al botón de confirmación, pasando por alto el campo IBAN del beneficiario. Una persona usuaria que solo use teclado —quizá una clienta con discapacidad motora— podría iniciar inadvertidamente una transferencia sin rellenar correctamente todos los campos obligatorios. Este escenario representa simultáneamente un fallo de WCAG 2.4.3, un incumplimiento de los requisitos de la circular y un posible perjuicio financiero grave para la persona usuaria.

De forma similar, un sitio de comercio electrónico cubierto por la circular que use reordenamiento con CSS Grid para mostrar una página de producto visualmente atractiva, pero cuya secuencia de tabulación salte de las imágenes del producto a los enlaces del pie de página antes de llegar al botón «Añadir al carrito», estaría en violación directa de 2.4.3 y, por tanto, en incumplimiento de la circular. Los plazos de uno y dos años significan que las organizaciones deberían tratar la corrección del orden de foco como una prioridad en sus hojas de ruta de accesibilidad, no como una mejora aplazada. Dado que los problemas de orden de foco a menudo se derivan de decisiones arquitectónicas sobre la estructura del DOM y los patrones de interacción en JavaScript, abordarlos temprano en el proceso de desarrollo es sustancialmente menos costoso que adaptarlos después del lanzamiento.

El SDK de superposición de Accsible ayuda a las organizaciones en su camino hacia el cumplimiento proporcionando mejoras configurables de gestión del foco, pero es importante señalar que las soluciones de superposición funcionan mejor junto con —no en lugar de— una estructura HTML semántica adecuada y una gestión responsable del foco en la propia base de código de la aplicación. Lograr una conformidad sostenible y auditable con la Circular Presidencial 2025/10 requiere que el producto subyacente cumpla 2.4.3 mediante prácticas de desarrollo correctas.