Principio 2/2.4 Navegable/2.4.11-A
De WCAG Wiki
< Principio 2 | 2.4 Navegable
2.4.11-A. Foco no oculto (mínimo)
- Nivel: AA*
- Versión: 2.2
- 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)
- Cuando un componente de la interfaz de usuario recibe el foco mediante teclado, dicho componente no puede estar completamente oculto por contenido generado por el autor.
Comprensión del criterio
Descripción resumida
Los elementos que reciben foco deben permanecer visibles. Ningún elemento fijo, ventana emergente, banner o overlay puede ocultar totalmente el control enfocado.
Objetivo
Garantizar que las personas que utilizan el teclado pueden localizar en todo momento cuál elemento tiene el foco, manteniendo orientación y control de la interacción.
Importancia de cumplir el criterio
Si el foco queda oculto, el usuario puede perder la posición en la página, bloquearse y no poder continuar usando la interfaz.
Referencias WCAG
- Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum) — WCAG 2.2
- WCAG Quick Reference — 2.4.11
- WAI-ARIA Authoring Practices — Gestión del foco y capas superpuestas
Recursos de apoyo
- Buenas prácticas para banners, modales y overlays
- Pseudoclase
:focus-visiblepara indicar foco - Patrones WAI-ARIA para navegación con foco en interfaces dinámicas
Evaluación del criterio
Tipo de evaluación
Evaluación Manual
Procedimiento de evaluación
- Paso 1. Navegar con teclado (Tab, Shift+Tab, Enter, Space).
- Paso 2. Verificar que ningún contenido superpuesto oculta por completo el foco.
- Paso 3. Revisar overlays, banners, barras fijas, tooltips y notificaciones.
- Paso 4. Probar con zoom (200%–400%) y modo móvil para detectar superposiciones.
- Paso 5. Confirmar que el foco permanece visible en componentes dinámicos.
Resultado esperado
El elemento enfocado nunca queda completamente oculto. El usuario puede ver siempre dónde está el foco.
Ejemplo ilustrativo
✅ Ejemplo accesible: banner que no tapa el foco
<div role="region" style="position:sticky;bottom:0;background:#eee;padding:1rem;"> <button>Aceptar cookies</button> </div>
Otras herramientas de evaluación
- Prueba con teclado
- Zoom 200% y 400%
- Modo responsive
- AXE / WAVE / Accessibility Insights
- Lectores de pantalla (confirmar foco narrado)
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.11-A. Foco no oculto (mínimo)
Loading comments...
