WCAG 2.4.7: Enfoque visible

Qué significa esta regla

WCAG 2.4.7 Focus Visible exige que cada elemento interactivo en una página web — enlaces, botones, campos de formulario, widgets personalizados y cualquier otro componente operable mediante teclado — muestre un indicador de foco visible cuando recibe el foco del teclado. En términos sencillos, cuando una persona usuaria pulsa la tecla Tab para desplazarse por una página, debe poder ver exactamente qué elemento está activo en ese momento.

El criterio no exige un estilo visual específico para el indicador de foco. Solo requiere que se produzca algún cambio visible. Dicho esto, un indicador apenas perceptible — por ejemplo, un contorno punteado de un píxel que se confunde con el fondo — puede cumplir técnicamente con 2.4.7 pero aun así incumplir el criterio más exigente WCAG 2.4.11 (Focus Appearance) introducido en WCAG 2.2. Bajo 2.4.7 por sí solo, cualquier cambio visual discernible es suficiente.

Qué se considera un cumplimiento: Un indicador de foco cumple si una persona con visión que navega con la tecla Tab por la página puede identificar qué elemento tiene el foco sin depender de anuncios del lector de pantalla u otras señales no visuales. Implementaciones aceptables habituales incluyen los contornos predeterminados del navegador, reglas CSS personalizadas de outline o box-shadow, cambios en el subrayado o cambios en el color de fondo aplicados en :focus o :focus-visible.

Qué se considera un incumplimiento: Se produce un fallo cuando una persona desarrolladora elimina el anillo de foco predeterminado del navegador — normalmente mediante outline: none o outline: 0 en CSS — y no lo sustituye por un indicador personalizado equivalente. También se producen fallos cuando un componente personalizado (construido con elementos <div> o <span>) se hace enfocable mediante teclado con tabindex pero no recibe ningún cambio de estilo visible al tener el foco.

Excepciones oficiales: WCAG señala que el criterio se aplica solo a interfaces operables mediante teclado. Los componentes que son puramente decorativos o que se excluyen explícitamente del orden de tabulación (mediante tabindex='-1') no están obligados a mostrar un indicador de foco, porque no pueden recibir el foco a través de la navegación normal con teclado.

Por qué es importante

La visibilidad del foco es fundamental para la accesibilidad mediante teclado, y la accesibilidad mediante teclado es la puerta de entrada al acceso para una amplia variedad de grupos de personas con discapacidad. Aproximadamente el 26% de las personas adultas en Estados Unidos viven con algún tipo de discapacidad según los CDC, y muchas de ellas dependen de teclados o tecnologías de asistencia que emulan el teclado en lugar de dispositivos apuntadores.

Las personas con discapacidad motora — incluidas personas con afecciones como ELA, parálisis cerebral, lesiones por esfuerzo repetitivo o enfermedad de Parkinson — dependen con frecuencia de teclados, dispositivos de conmutación, controladores de soplo y succión o software de seguimiento ocular. Todos estos métodos de entrada dependen del modelo de foco de teclado del navegador. Si el indicador de foco es invisible, estas personas no pueden determinar dónde se encuentran en la página, no pueden activar el control correcto y pueden quedar completamente excluidas de tareas críticas como enviar un formulario, completar una compra o navegar por un menú.

Las personas con baja visión que no usan lector de pantalla pero pueden ampliar la pantalla también dependen del foco visible. Cuando hacen zoom en una parte de la página, el anillo de foco visible les indica qué elemento está activo y guía su interacción.

Las discapacidades cognitivas y relacionadas con la atención también se benefician de indicadores de foco claros. Las personas con TDAH o dificultades de memoria a menudo pierden la referencia de su posición en una página compleja; un indicador de foco prominente proporciona un ancla visual fiable.

Un escenario concreto del mundo real: pensemos en una persona con esclerosis múltiple que navega por un sitio de comercio electrónico usando solo el teclado porque la precisión con el ratón se ha vuelto difícil. Recorre con la tecla Tab la página de producto hasta llegar al botón "Add to Cart". Si la persona desarrolladora ha suprimido el anillo de foco, la persona usuaria no ve ninguna indicación de dónde está el foco. Pulsa Enter y o bien no ocurre nada (el foco cayó en un elemento no interactivo) o se desencadena la acción equivocada. El resultado es frustración, abandono de la tarea y pérdida de ingresos para la empresa, todo ello evitable con una sola regla CSS.

Más allá de la discapacidad, los indicadores de foco benefician a todas las personas usuarias en situaciones en las que el uso del ratón es incómodo: personas usuarias avanzadas que navegan con atajos de teclado, personas que usan portátiles sin ratón externo y personas que rellenan formularios largos. El foco visible también mejora el SEO de forma indirecta al fomentar HTML semántico y un orden de tabulación adecuado, ambos aspectos que los rastreadores de motores de búsqueda valoran.

Reglas relacionadas de Axe-core

WCAG 2.4.7 requiere pruebas manuales porque las herramientas automatizadas no pueden determinar de forma fiable si un indicador de foco es visible. Axe-core y motores similares pueden detectar que existe una regla CSS como outline: none, pero no pueden evaluar el resultado visual renderizado en todos los temas, modos de alto contraste y motores de renderizado de navegadores. Lo siguiente explica el panorama de pruebas:

• Se requiere prueba manual — supresión de focus-visible: Axe-core no incluye una regla dedicada que marque de forma concluyente fallos de 2.4.7, porque hacerlo requeriría renderizar la página, recorrer con Tab cada elemento y realizar un análisis de contraste a nivel de píxel sobre el indicador de foco, una tarea que va más allá del análisis estático o a nivel de DOM. En su lugar, las personas evaluadoras deben recorrer manualmente la página con la tecla Tab y confirmar visualmente que cada elemento interactivo muestra un cambio de foco.
• Señal parcial de css-orientation-lock y comprobaciones de estilos: Algunas configuraciones de axe-core marcan la presencia de outline: 0 o outline: none en las hojas de estilo como una advertencia de buena práctica, pero esto es una heurística, no una comprobación de infracción definitiva, porque la regla puede verse anulada por un estilo de foco personalizado válido en otra parte de la cascada.
• Por qué la automatización se queda corta: Un indicador de foco puede estar oculto solo en ciertos estados (por ejemplo, cuando un modal está abierto), solo para ciertos tipos de elementos o solo en determinados temas de color. Estos fallos condicionales requieren que una persona evaluadora navegue por cada elemento interactivo en el entorno realmente renderizado y confirme su visibilidad. Herramientas como axe DevTools Pro pueden ayudar resaltando elementos a los que se les aplica outline: none, pero la determinación final de cumplimiento/incumplimiento debe hacerla una persona.

Cómo hacer las pruebas

1. Preanálisis automatizado: Ejecuta axe DevTools (extensión del navegador o CLI) o Google Lighthouse en la página. Busca cualquier advertencia de buenas prácticas o experimental relacionada con estilos de foco. Aunque estas no confirman de forma definitiva un fallo de 2.4.7, sacan a la luz elementos que merece la pena inspeccionar. En Lighthouse, revisa la categoría "Accessibility" para ver hallazgos relacionados con el foco. Exporta el informe y anota todos los elementos interactivos marcados.
2. Prueba manual de tabulación con teclado: Desconecta o aparta el ratón. Pulsa Tab repetidamente desde la parte superior de la página y navega por cada elemento interactivo — enlaces, botones, campos de entrada, menús desplegables, modales, pestañas, acordeones y selectores de fecha. En cada parada, confirma que el elemento enfocado se distingue visualmente de sus vecinos sin foco. Registra cualquier elemento en el que la llegada del foco no produzca ningún cambio visible.
3. Prueba de tabulación inversa: Usa Shift+Tab para navegar hacia atrás por la página y repite la comprobación visual. Algunas implementaciones solo rompen la visibilidad del foco en una dirección debido a problemas de especificidad en CSS.
4. Prueba con NVDA + Firefox: Abre Firefox con NVDA en ejecución. Usa el modo Browse (teclas de flecha) y luego cambia al modo Forms (Enter) para interactuar con los controles de formulario. Confirma que cada elemento que NVDA anuncia como enfocado también muestra un indicador visible en pantalla; esto es útil para detectar discrepancias entre el foco del AT y el foco del navegador.
5. Prueba con VoiceOver + Safari (macOS/iOS): Activa VoiceOver y usa Tab o VO+Flecha derecha para desplazarte por los elementos interactivos. Verifica visualmente que el anillo de foco en pantalla coincide con lo que anuncia VoiceOver.
6. Prueba con JAWS + Chrome: Usa JAWS en modo cursor virtual y luego en modo aplicación. Recorre con Tab los controles interactivos y confirma que el indicador de foco visible aparece en cada elemento enfocado.
7. Prueba en modo de alto contraste: Activa el modo de alto contraste de Windows (o Aumentar contraste en macOS) y repite la prueba con Tab. Algunos indicadores de foco dependen de colores que desaparecen en temas de alto contraste; el indicador debe seguir siendo visible en estos modos.
8. Inspección CSS: Abre las DevTools del navegador, selecciona un elemento interactivo, dale foco pulsando Tab hasta que esté activo e inspecciona los estilos calculados. Verifica que ninguna regla establezca outline: none o outline: 0 sin un estilo de foco compensatorio. Comprueba también :focus-visible frente a :focus para asegurarte de que el foco activado por teclado está cubierto.

Cómo solucionarlo

Supresión global de outline sin reemplazo — Incorrecto

<!-- CSS resets that remove all focus indicators globally -->
<style>
  * {
    outline: none; /* Removes focus ring from every element */
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>

Supresión global de outline sin reemplazo — Correcto

<!-- Remove the global outline: none reset.
     Provide a custom focus style that is visually clear. -->
<style>
  /* Respect users who prefer reduced motion */
  :focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>
<!-- Now both elements show a high-contrast blue outline when focused via keyboard -->

Botón personalizado basado en div sin estilo de foco — Incorrecto

<!-- A div styled as a button, made focusable, but missing :focus CSS -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  /* No :focus or :focus-visible rule defined */
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>

Botón personalizado basado en div sin estilo de foco — Correcto

<!-- Add :focus-visible to the custom component so keyboard
     users see a clear indicator when this element is focused -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  .fake-btn:focus-visible {
    outline: 3px solid #ffcc00;
    outline-offset: 3px;
  }
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>
<!-- The yellow outline appears only on keyboard focus, not on mouse click -->

Anillo de foco oculto dentro de una superposición modal — Incorrecto

<!-- Modal applies overflow:hidden and a stacking context that clips
     the default outline, making it invisible -->
<style>
  .modal-body {
    overflow: hidden; /* Clips outlines that extend beyond the element */
    border-radius: 8px;
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Anillo de foco oculto dentro de una superposición modal — Correcto

<!-- Use box-shadow instead of outline so it renders
     inside the stacking context and is never clipped -->
<style>
  .modal-body {
    overflow: hidden;
    border-radius: 8px;
  }
  .modal-body button:focus-visible {
    /* box-shadow is not clipped by overflow:hidden --
       it stays within the element's own box -->
    box-shadow: 0 0 0 3px #005fcc;
    outline: none; /* Remove default to avoid double ring */
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Errores comunes

• Añadir outline: none a un reset CSS base sin auditar qué elementos afecta. Muchos resets populares (por ejemplo, versiones antiguas de normalize.css o utilidades de Bootstrap) suprimen los anillos de foco de forma global. Siempre hay que acompañar esto con una regla explícita de :focus-visible que restaure la visibilidad para las personas usuarias de teclado.
• Depender únicamente de :focus cuando :focus-visible es más apropiado — o viceversa. Usar solo :focus aplica el indicador también en los clics de ratón, lo que puede resultar extraño. Usar solo :focus-visible sin un respaldo de :focus puede dejar a los navegadores antiguos sin ningún indicador. Haz pruebas en todos los navegadores objetivo.
• Aplicar outline: none dentro de una sobrescritura de tema de una librería de componentes sin entender la cascada. Una sola sobrescritura en un archivo de tema puede borrar silenciosamente los indicadores de foco de todos los componentes que heredan de ella, incluidos widgets de terceros.
• Usar un color de foco con contraste insuficiente respecto al elemento o al fondo de la página. Un contorno gris claro sobre un fondo blanco técnicamente añade un contorno pero puede ser imperceptible. Aunque 2.4.7 no exige una relación de contraste específica, 2.4.11 sí lo hace, y los indicadores de foco con bajo contraste son una fuente habitual de fallos en auditorías incluso cuando las personas desarrolladoras creen haber cumplido.
• Establecer overflow: hidden o clip-path en un contenedor, lo que recorta el contorno predeterminado del navegador. La solución es cambiar a indicadores de foco basados en box-shadow, que se renderizan dentro del propio cuadro del elemento y no se recortan por las reglas de overflow del elemento padre.
• Olvidar los indicadores de foco en elementos interactivos dentro de componentes SVG o Canvas. Tooltips personalizados de gráficos, botones de iconos basados en SVG y herramientas de dibujo basadas en canvas a menudo no tienen estilos de foco nativos. Estos requieren roles ARIA explícitos, tabindex y CSS de :focus-visible o retroalimentación visual controlada por JavaScript.
• Eliminar la visibilidad del foco solo en el CSS de producción (por ejemplo, mediante un posprocesador o una etapa de build) mientras se mantiene visible en el entorno de desarrollo. Esto hace que el equipo de desarrollo apruebe su QA local mientras entrega una accesibilidad rota a las personas usuarias finales.
• Aplicar un indicador de foco solo al elemento <a> pero no a elementos role='link' de tipo span usados para enlaces de navegación en SPA. Cada elemento enfocable mediante teclado — independientemente de su etiqueta nativa — necesita un estado de foco visible.
• Ocultar los anillos de foco solo en ciertos anchos de viewport mediante media queries, asumiendo que las personas usuarias de móvil siempre tocan la pantalla. Las personas usuarias de tablet con teclados Bluetooth y las personas en orientación apaisada que dependen de la entrada por teclado se quedan sin ningún indicador de foco.
• Usar JavaScript para llamar a .blur() inmediatamente después de un foco programático para evitar que aparezca el anillo de foco. Este es un error crítico que elimina por completo la visibilidad del foco y nunca debe usarse como atajo de diseño.

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 una amplia gama de entidades que operan en Turquía. La circular exige la conformidad con WCAG 2.2 en Nivel AA para las organizaciones cubiertas, lo que convierte a WCAG 2.4.7 Focus Visible en un requisito directamente exigible y no solo en una recomendación de buena práctica.

Las entidades cubiertas por la circular incluyen instituciones y organismos públicos, plataformas de comercio electrónico, bancos y proveedores de servicios financieros, hospitales y organizaciones sanitarias, empresas de telecomunicaciones con 200,000 o más personas abonadas, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). Para todas estas organizaciones, no proporcionar indicadores de foco visibles en sus interfaces digitales es un problema de incumplimiento normativo, no solo una carencia de usabilidad.

El Erişilebilirlik Logosu (Logotipo de Accesibilidad), emitido por el Ministerio de Familia y Servicios Sociales, sirve como marca oficial de certificación que las entidades cubiertas pueden mostrar para demostrar conformidad. Obtener el Logotipo de Accesibilidad requiere superar una auditoría formal en WCAG 2.2 Nivel AA. WCAG 2.4.7 es uno de los criterios AA que las personas auditoras evaluarán, normalmente mediante pruebas manuales con teclado como se describe en la sección de pruebas anterior. Una organización cuyo sitio suprima los anillos de foco o no implemente foco visible en componentes personalizados no superará la auditoría requerida para el logotipo.

Para las plataformas turcas de comercio electrónico en particular, la visibilidad del foco tiene implicaciones comerciales directas: los sitios accesibles llegan a una base de personas usuarias más amplia, incluidas clientas y clientes con discapacidad motora que compran exclusivamente mediante teclado o acceso por conmutador, y el cumplimiento de la Circular Presidencial 2025/10 protege a las organizaciones frente a acciones administrativas. Incorporar patrones de foco visible en la librería de componentes desde el principio — en lugar de adaptarlos después de una auditoría — es la vía más rentable para mantener el Erişilebilirlik Logosu y cumplir las obligaciones de accesibilidad de Turquía.