Principio 2/2.4 Navegable/2.4.7-A
De WCAG Wiki
< Principio 2 | 2.4 Navegable
2.4.7-A. Foco visible
- Nivel: AA
- Versión: 2.0
- Principio: 2_Operable
- Pauta: 2.4_Navegacion_clara
- Grupo: Teclado
- Subgrupo: Foco_visible
Discapacidades afectadas
Este criterio puede afectar a distintas personas con discapacidad. A continuación se indican las más relevantes.
-
Motriz –
Barrera grave
-
Baja visión –
Barrera moderada
-
Visual total –
Barrera leve
Enunciado del criterio (Observatorio de Accesibilidad Web)
- Se debe poder identificar visualmente cuál es el elemento de interacción que tiene el foco del teclado en cada momento.
Comprensión del criterio
Descripción resumida
Todos los elementos interactivos deben mostrar un indicador visual claro cuando reciben el foco mediante teclado, permitiendo a las personas usuarias orientarse y avanzar de forma segura en la navegación.
Objetivo
Asegurar que las personas que navegan mediante teclado pueden localizar en todo momento el elemento activo o seleccionado y actuar sobre él sin perder la orientación.
Importancia de cumplir el criterio
Si no hay foco visible, la navegación por teclado puede volverse imposible, provocando barreras graves para usuarios con discapacidad motriz y dificultades visuales.
Referencias WCAG
- Understanding Success Criterion 2.4.7: Focus Visible — W3C
- WCAG Quick Reference – 2.4.7 Focus Visible
- Guía Técnica WCAG — Principio Operable
Recursos de apoyo
- Pseudoclases CSS
:focusy:focus-visible - Buenas prácticas diseño accesible para foco
Evaluación del criterio
Tipo de evaluación
Evaluación Manual
Procedimiento de evaluación
- Paso 1. Navegar por teclado en la página (Tab, Shift+Tab, Enter, Espacio).
- Paso 2. Confirmar que todos los elementos interactivos muestran un foco visible al activarse.
- Paso 3. Verificar que el foco es claramente perceptible (contorno, color, grosor, forma).
- Paso 4. Revisar que no se ha eliminado el foco mediante estilos CSS.
- Paso 5. Probar interacción en componentes dinámicos (menús, modales, pestañas).
Resultado esperado
El usuario que navega mediante teclado puede identificar fácilmente qué elemento tiene el foco en todo momento.
Ejemplo ilustrativo
✅ Ejemplo: foco visible en botón
<button class="btn">Enviar</button>
<style>
.btn:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 3px;
}
</style>
Otras herramientas de evaluación
- Navegación con teclado
- Modo alto contraste / forced colors
- AXE / WAVE / Accessibility Insights
- Prueba con lectores de pantalla
Ejemplos accesibles y no accesibles creados por alumnos
<!DOCTYPE html>
⚠️ PROBLEMA 3.3.2-C: Este formulario NO tiene etiquetas ni instrucciones claras
Reserva de Hotel
⚠️ Problemas de este formulario:
- No hay etiquetas
<label>para ningún campo - Algunos placeholders son ambiguos ("Código" - ¿qué código?)
- No se indica qué campos son obligatorios
- No hay instrucciones sobre el formato esperado
- El select dice "Selecciona" pero ¿seleccionar qué?
- Un campo no tiene ni placeholder ni etiqueta (campo de email)
- No hay indicación de formato de fecha específico
- No se explica para qué sirve cada campo
<!DOCTYPE html>
✅ ACCESIBLE 3.3.2-C: Este formulario tiene etiquetas e instrucciones claras
Reserva de Hotel
Complete el siguiente formulario para reservar su estadía
Nota: Los campos marcados con * son obligatorios
✅ Implementación correcta:
- Cada campo tiene una etiqueta
<label>clara asociada - Los campos obligatorios están claramente marcados con *
- Hay instrucciones específicas sobre formato y contenido esperado
- Los selectores tienen opciones descriptivas, no ambiguas
- Se explica el propósito de cada campo cuando no es obvio
- Se proporcionan ejemplos en los placeholders
- Hay una nota inicial explicando la convención de campos obligatorios
- Se usan atributos ARIA apropiados (aria-required, aria-describedby)
Comentarios
A continuación se muestran comentarios sobre el criterio 2.4.7-A. Foco visible
Loading comments...
