WCAG 2.4.13: Apariencia del foco

Qué significa esta regla

WCAG 2.4.13 Apariencia del foco es un criterio de nivel AAA introducido en WCAG 2.2 que establece requisitos precisos y medibles para la apariencia visual de los indicadores de foco del teclado. Mientras que el criterio de nivel inferior 2.4.11 (Foco no oculto, Nivel AA) garantiza que el elemento enfocado no esté completamente oculto, y 2.4.7 (Foco visible, Nivel AA) simplemente requiere que exista algún indicador de foco, 2.4.13 va más allá al definir qué tan visible debe ser ese indicador.

Para cumplir este criterio, el indicador de foco del teclado debe satisfacer todas las condiciones siguientes:

• Área mínima: El indicador de foco debe tener un área de al menos el perímetro del componente sin foco multiplicado por 2 píxeles CSS. En términos prácticos, para un botón rectangular típico, esto significa que el contorno de foco debe tener un área igual o mayor que el perímetro del botón por 2px: un anillo de foco de al menos 2px de grosor alrededor de todo el borde cumple el requisito.
• Relación de contraste del indicador de foco: Los píxeles que forman el indicador de foco deben tener una relación de contraste de al menos 3:1 entre sus estados enfocado y desenfocado. Así, si un botón tiene un fondo blanco en su estado por defecto, el anillo de foco dibujado a su alrededor debe contrastar al menos 3:1 con ese fondo blanco.
• Sin reducción de contraste para el contenido incluido: El indicador de foco no debe reducir el contraste del texto u otro contenido dentro del componente enfocado por debajo de 4.5:1 (para texto menor de 18pt / 14pt en negrita) o 3:1 (para texto grande y contenido no textual).

Las tres condiciones deben cumplirse simultáneamente para que un componente apruebe. Un indicador de foco que sea lo suficientemente grande pero tenga un contraste insuficiente falla. De igual manera, un indicador de alto contraste que sea demasiado pequeño también falla.

La especificación WCAG define una excepción notable: si el indicador de foco por defecto del navegador (el valor por defecto del agente de usuario) cumple los requisitos, la persona autora no necesita añadir un estilo personalizado. Sin embargo, los valores por defecto del navegador varían significativamente: los navegadores basados en Chromium generalmente proporcionan un contorno azul, mientras que Safari puede representar un anillo que carece de contraste suficiente en ciertos esquemas de color. Las personas autoras deben verificar que el indicador por defecto cumple el umbral o proporcionar un estilo personalizado sólido.

El criterio se aplica a todos los componentes interactivos y enfocables: enlaces, botones, campos de formulario, menús select, casillas de verificación, botones de opción, componentes de widgets personalizados construidos con roles ARIA y cualquier elemento hecho enfocable mediante tabindex. También se aplica a indicadores de foco creados únicamente mediante CSS en pseudo-elementos o mediante cambios de clase controlados por JavaScript.

Por qué es importante

La visibilidad del foco es una señal de navegación fundamental para una amplia variedad de personas usuarias. Cuando los indicadores de foco son finos, de bajo contraste o están ausentes por completo, estas personas pierden su orientación espacial dentro de una página: no pueden saber dónde están ni a dónde pueden ir después.

Personas que usan solo teclado, incluidas personas con discapacidades motoras como temblores, parálisis o lesiones por esfuerzo repetitivo, dependen por completo del teclado para navegar. Para estas personas, un indicador de foco invisible o apenas visible no es solo una molestia; hace que toda la interfaz sea inutilizable. Según la Organización Mundial de la Salud, aproximadamente 1.3 mil millones de personas viven con alguna forma de discapacidad, y las discapacidades motoras representan una de las categorías más grandes entre quienes evitan o no pueden usar un ratón.

Personas con baja visión que usan software de magnificación pero no un lector de pantalla completo también dependen del anillo de foco para orientarse. A niveles de zoom altos, un contorno por defecto de 1px puede quedar recortado por la ventana gráfica o simplemente ser invisible contra un fondo de color similar. Estas personas a menudo navegan con el teclado precisamente porque la puntería precisa con el ratón es difícil con alta magnificación.

Discapacidades cognitivas y relacionadas con la atención, como TDAH, trastornos de ansiedad y lesiones cerebrales traumáticas, pueden dificultar el seguimiento de la información visual a lo largo de una página. Un indicador de foco muy visible y claramente diferenciado reduce la carga cognitiva de la navegación al proporcionar un ancla inequívoca para la posición actual de la persona usuaria.

Discapacidades situacionales también importan: una persona desarrolladora que prueba en la pantalla de un portátil con bajo brillo al aire libre, o una persona mayor con disminución de la sensibilidad al contraste relacionada con la edad, pueden tener dificultades con anillos de foco finos o de bajo contraste incluso sin un diagnóstico clínico.

Considere un escenario del mundo real: el formulario en línea de un banco para transferir fondos contiene diez campos de entrada y cuatro botones de acción. Una persona usuaria con enfermedad de Parkinson recorre el formulario con el teclado. Si el indicador de foco es un contorno punteado por defecto de 1px en gris claro sobre un fondo blanco, la persona no puede seguir de forma fiable qué campo está editando en ese momento. Puede enviar accidentalmente una transferencia a la cuenta equivocada porque no pudo ver que el foco había pasado del campo de destinatario. Un contorno de foco sólido y de alto contraste habría evitado esto por completo.

Más allá de la accesibilidad, un indicador de foco claro es una mejora de usabilidad para todas las personas usuarias. Las personas usuarias avanzadas que navegan con frecuencia por formularios y menús mediante el teclado —un patrón común entre desarrolladores, profesionales de entrada de datos y personas usuarias de lectores de pantalla— se benefician de una orientación rápida y fiable. También existe una señal indirecta para SEO: los sitios con una buena accesibilidad tienden a tener tasas de rebote más bajas y mayor finalización de tareas, ambos factores que se correlacionan con factores de posicionamiento positivos.

Reglas relacionadas de Axe-core

WCAG 2.4.13 requiere pruebas manuales porque las herramientas automatizadas no pueden evaluar completamente el tamaño y el contraste de un indicador de foco en todos los contextos posibles de renderizado del navegador. Axe-core no tiene una única regla automatizada que marque directamente fallos de 2.4.13. Las razones son técnicas:

• Por qué la automatización es insuficiente: Calcular el área exacta en píxeles de un indicador de foco requiere simular el foco del teclado en cada elemento interactivo, medir la geometría del contorno renderizado (que depende del navegador, el sistema operativo, el nivel de zoom y el CSS), calcular la relación de contraste de los píxeles del indicador frente a sus vecinos y verificar que ninguno de estos viole el requisito de contraste del contenido incluido. Ningún motor de accesibilidad automatizado actual realiza de forma fiable todos estos pasos en todos los componentes. Axe-core puede marcar la ausencia de cualquier estilo de foco (relacionado con 2.4.7) pero no puede medir si el estilo que sí está presente cumple los umbrales de área y contraste de 2.4.13.
• Cobertura parcial mediante reglas relacionadas con el foco: La regla focus-visible de axe-core comprueba si los elementos tienen algún indicador de foco visible. Si un elemento tiene outline: none o outline: 0 sin un indicador visual alternativo, esta regla lo marcará. Sin embargo, aprobar esta regla no garantiza el cumplimiento de 2.4.13: un elemento puede tener un contorno técnicamente visible que siga siendo demasiado fino o de muy bajo contraste.
• Las pruebas manuales son el método de referencia: Las personas evaluadoras deben inspeccionar visualmente cada componente interactivo en estado enfocado, medir o estimar las dimensiones del contorno y verificar las relaciones de contraste usando un analizador de contraste de color. Por ello, WCAG lista 2.4.13 como un criterio que solo se prueba manualmente a efectos de axe-core.

Cómo hacer las pruebas

1. Escaneo automatizado (solo señal parcial): Ejecute axe DevTools o Lighthouse en la página. Busque cualquier fallo relacionado con focus-visible o focus-order-semantics. Aunque estos no marcarán directamente violaciones de 2.4.13, pueden sacar a la luz elementos donde el estilo de foco se ha suprimido por completo, lo cual es un fallo previo. En Chrome DevTools, abra el panel de Accesibilidad y use el modo de inspección "Tab" para recorrer los elementos enfocables.
2. Prueba visual de navegación con teclado: Desconecte o aparte el ratón. Presione Tab para moverse por cada elemento interactivo de la página. Para cada elemento enfocado, inspeccione visualmente el indicador de foco. Pregúntese: ¿Hay un anillo u otro indicador claramente visible? ¿Parece tener al menos 2px de grosor? ¿Contrasta fuertemente con el fondo circundante? Anote cualquier elemento en el que dude o tenga dificultades para ver dónde está el foco.
3. Medición de contraste: Use el WebAIM Contrast Checker o la herramienta de escritorio Colour Contrast Analyser. Con el foco en un componente, tome una captura de pantalla. Muestree el color de los píxeles del indicador de foco y el color del fondo inmediatamente adyacente. Verifique que la relación de contraste sea de al menos 3:1.
4. Medición de dimensiones: Use las DevTools del navegador (Chrome o Firefox). Seleccione un elemento enfocado e inspeccione sus estilos calculados. Compruebe outline-width, outline-offset y cualquier box-shadow usado como anillo de foco. Multiplique el perímetro del elemento (2 × ancho + 2 × alto) por 2px para calcular el área mínima. Verifique que el área renderizada del indicador cumple o supera este valor.
5. Prueba con lector de pantalla + teclado (NVDA + Firefox): Abra la página en Firefox con NVDA en ejecución. Navegue usando Tab y las teclas de flecha. Confirme que el indicador visual de foco se mueve en sincronía con el foco anunciado por NVDA. Preste especial atención a los widgets personalizados (carruseles, modales, acordeones) donde la gestión del foco puede manejarse mediante JavaScript.
6. VoiceOver + Safari (macOS/iOS): Active VoiceOver con Command + F5. Use Tab para navegar por los elementos interactivos. Verifique que el cursor de VoiceOver (el recuadro de contorno negro) no sustituye a un indicador de foco CSS adecuado: la propia página debe proporcionar uno de forma independiente.
7. Prueba en modo de alto contraste: En Windows, active el modo de alto contraste (Configuración → Facilidad de acceso → Alto contraste). Recargue la página y repita la prueba de navegación con teclado. Algunos estilos de foco en CSS son sobrescritos por el sistema operativo en modo de alto contraste; verifique que siga apareciendo un indicador visible. Use la media query CSS forced-colors: active para ajustar estilos de forma condicional si es necesario.

Cómo corregir

Contorno por defecto del navegador eliminado — Incorrecto

<!-- Many stylesheets globally suppress the default focus outline -->
<style>
  * {
    outline: none; /* Removes ALL focus indicators site-wide */
  }
  a:focus, button:focus {
    outline: 0; /* Redundant removal; no replacement provided */
  }
</style>
<button>Submit Payment</button>

Contorno por defecto del navegador eliminado — Correcto

<!-- Remove the default only when providing a superior custom indicator -->
<style>
  /* Only suppress default outline when :focus-visible applies, then provide a strong replacement */
  :focus-visible {
    outline: 3px solid #0057b8; /* 3px ensures area requirement is met for typical elements */
    outline-offset: 2px;       /* Offset separates indicator from element edge for clarity */
  }
  /* Respect forced-colors (Windows High Contrast) by using system keywords */
  @media (forced-colors: active) {
    :focus-visible {
      outline: 3px solid ButtonText;
    }
  }
</style>
<button>Submit Payment</button>

Anillo de foco de bajo contraste sobre fondo de color — Incorrecto

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus {
    outline: 2px solid #3399ff; /* Light blue outline on dark blue background: contrast ratio ~1.4:1 — fails */
  }
</style>
<button class='cta-button'>Book Now</button>

Anillo de foco de bajo contraste sobre fondo de color — Correcto

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus-visible {
    /* White outline contrasts strongly against the dark blue button (contrast ~8:1) */
    outline: 3px solid #ffffff;
    outline-offset: 2px;
    /* A dark offset box-shadow behind the white ring ensures contrast against light page backgrounds */
    box-shadow: 0 0 0 5px #0057b8;
  }
</style>
<button class='cta-button'>Book Now</button>

Widget interactivo personalizado basado en div sin estilo de foco — Incorrecto

<style>
  .tab-item { cursor: pointer; padding: 12px 20px; }
  /* No :focus or :focus-visible style defined for custom tab */
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Widget interactivo personalizado basado en div sin estilo de foco — Correcto

<style>
  .tab-item {
    cursor: pointer;
    padding: 12px 20px;
    border-radius: 4px;
  }
  /* Explicit :focus-visible style — outline-width 3px with offset meets area threshold */
  .tab-item:focus-visible {
    outline: 3px solid #d4550a; /* 3:1+ contrast against white background */
    outline-offset: 3px;
  }
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Box-shadow fino usado como indicador de foco — Incorrecto

<style>
  .form-input:focus {
    outline: none;
    /* 1px box-shadow spread: likely too small in area for most input sizes */
    box-shadow: 0 0 0 1px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Box-shadow fino usado como indicador de foco — Correcto

<style>
  .form-input:focus-visible {
    outline: none;
    /*
      3px spread provides sufficient area around a typical 300px-wide input.
      #005fcc on white background yields ~5.9:1 contrast — passes both 2.4.13 (3:1) and 1.4.3 (4.5:1).
    */
    box-shadow: 0 0 0 3px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Errores comunes

• Usar outline: none en un reset de CSS sin proporcionar ningún indicador de foco de reemplazo. Muchos resets de CSS populares (versiones antiguas de Normalize.css, resets personalizados) eliminan los contornos de forma generalizada. Siempre acompañe la eliminación con un reemplazo :focus-visible que cumpla los requisitos de tamaño y contraste.
• Proporcionar un estilo de foco solo para :focus pero no para :focus-visible, lo que provoca anillos de foco al hacer clic con el ratón en botones que molestan a las personas usuarias videntes que usan ratón, lo que lleva a que las personas desarrolladoras los eliminen por completo en lugar de usar la pseudo-clase correcta.
• Elegir un color de anillo de foco que coincida estrechamente con el color de fondo del componente. Por ejemplo, un anillo azul claro #99ccff sobre un fondo blanco #ffffff tiene una relación de contraste de aproximadamente 1.5:1, muy por debajo del 3:1 requerido.
• Usar outline-width: 1px en componentes pequeños como botones de icono o casillas de verificación. Un anillo de 1px alrededor de un icono de 24×24px tiene un área de aproximadamente 96 píxeles cuadrados, pero el área mínima requerida para un elemento de 24×24 es (24+24+24+24) × 2 = 192 píxeles cuadrados, exactamente 2px de grosor. Un contorno de 1px falla este cálculo.
• Olvidar probar la apariencia del foco en widgets ARIA personalizados como role='combobox', role='listbox' o role='slider'. Estos componentes a menudo tienen un foco gestionado por JavaScript que pasa por alto las pseudo-clases CSS nativas a menos que se manejen explícitamente.
• Aplicar un estilo de foco solo a las etiquetas a y button mientras se descuidan input, select, textarea y cualquier elemento con tabindex='0'.
• Sobrescribir estilos de foco en lo profundo de una biblioteca de componentes o widget de terceros sin darse cuenta de que la sobrescritura elimina el indicador visible. Los culpables comunes incluyen kits de UI como Bootstrap 4 (que establecen box-shadow en un resplandor sutil) que pueden no cumplir el umbral de 2.4.13.
• No probar la apariencia del foco en el modo de alto contraste de Windows. Algunas técnicas de contorno y box-shadow en CSS se renderizan de forma invisible en modo de alto contraste. Use el bloque @media (forced-colors: active) para garantizar una alternativa visible basada en colores del sistema.
• Usar outline-offset con un valor negativo muy grande para mover el contorno dentro del borde del elemento. Esto puede hacer que el indicador se superponga con el fondo del elemento, reduciendo el contraste efectivo por debajo de 3:1.
• Suponer que el indicador de foco en un contenedor padre es suficiente para los elementos interactivos hijos. Cada elemento enfocable debe cumplir el criterio de forma independiente; una fila resaltada en una tabla no satisface el requisito para un enlace en una celda dentro de esa fila.

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 vinculantes de accesibilidad web y móvil para un amplio conjunto de entidades que operan en Turquía. La circular adopta WCAG 2.2 como su estándar técnico de referencia y exige conformidad en el Nivel AA para las entidades cubiertas. WCAG 2.4.13 Apariencia del foco es un criterio de nivel AAA y, por lo tanto, no está directamente exigido por la circular para el cumplimiento estándar.

Sin embargo, el alcance de la circular es amplio. Las entidades cubiertas incluyen instituciones públicas y organismos gubernamentales, bancos y proveedores de servicios financieros, hospitales y organizaciones sanitarias, operadores de telecomunicaciones con 200,000 o más abonados, plataformas de comercio electrónico, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). Para todas estas organizaciones, demostrar conformidad de nivel AAA en los criterios aplicables —incluido 2.4.13— señala un compromiso con una accesibilidad de primer nivel que supera el mínimo legal.

Existen razones prácticas y de reputación para que las entidades turcas cubiertas implementen voluntariamente 2.4.13. Los bancos y proveedores de servicios financieros, en particular, atienden a clientes con discapacidades motoras que dependen de la navegación por teclado para realizar transacciones seguras. El portal de banca en línea de un banco turco que cumple 2.4.13 no solo supera los requisitos normativos, sino que también reduce el riesgo de errores de usuario y demuestra responsabilidad social corporativa. Del mismo modo, los hospitales y portales de salud donde las personas pacientes reservan citas o acceden a historiales médicos deben garantizar que todas las personas usuarias —incluidas personas mayores con control motor fino reducido o baja visión— puedan navegar por esas interfaces con confianza.

Los operadores de telecomunicaciones con grandes bases de abonados se encuentran entre los servicios digitales de mayor tráfico en Turquía. Sus portales de clientes y aplicaciones de autoservicio llegan a millones de personas usuarias, incluida una proporción significativa de personas mayores y personas con discapacidad. Implementar voluntariamente 2.4.13 en todas estas plataformas garantiza un acceso equitativo para todas las personas abonadas y posiciona favorablemente al operador ante cualquier endurecimiento normativo futuro que pudiera extender la conformidad obligatoria a criterios AAA.

Para las organizaciones que buscan lograr una conformidad completa con WCAG 2.2 AAA —ya sea impulsadas por requisitos de contratación pública, exportación a mercados de la UE sujetos al Acta Europea de Accesibilidad o políticas internas de accesibilidad— implementar 2.4.13 es un componente necesario. El SDK de overlay de Accsible proporciona funciones configurables de mejora del foco que pueden ayudar a las organizaciones a mostrar indicadores de foco sólidos y conformes en todas sus interfaces, complementando las correcciones de CSS a nivel de autor descritas en este artículo.