Un botón visible puede desaparecer cuando hace falta
Un pie fijo puede ocultar un botón justo cuando una persona llega a él con el teclado. El botón sigue existiendo, el navegador le da foco y la página puede parecer correcta en una captura tomada un instante antes. El fallo está en la transición entre estados.
Según la revisión del 21 de septiembre de 2026, Focus Not Obscured (Minimum) de WCAG 2.2 trata ese caso en el nivel AA: el contenido creado por el autor no debe ocultar por completo el componente que recibe foco del teclado. Es una condición de ingeniería que merece comprobarse antes de publicar, aunque el trabajo de accesibilidad haya comenzado por colores y etiquetas.
Este artículo propone un método práctico de revisión para equipos de producto. No presenta mejoras de conversión medidas ni certifica un sitio. Los ejemplos son estados hipotéticos de una interfaz, elegidos porque permiten reproducir el fallo en una vista previa desechable.
Probar un recorrido, no un componente aislado
Imaginemos un formulario de compra con una barra fija que resume el pedido. El botón de pago pasa las pruebas visuales de la biblioteca. Tiene un contorno de foco. Pero la página también carga un aviso de consentimiento, y ambos elementos dejan menos espacio útil del que cada componente esperaba.
La prueba útil comienza antes de cerrar las capas. Hay que recorrer el flujo real con el teclado y registrar qué control recibe foco, qué lo tapa y qué acción permite verlo. Después se repite hacia atrás. Un diseño que solo funciona al avanzar sigue impidiendo revisar una respuesta anterior.
Conviene mantener un inventario de estados junto a la funcionalidad: consentimiento pendiente, error de validación visible, ayuda expandida y diálogo de confirmación abierto. Son casos sugeridos, no una suposición de que todos los productos incluyen esos controles. Se eligen los estados que la aplicación realmente admite. Cada uno necesita un responsable y un recorrido esperado con teclado.
Una captura debe acompañar la secuencia que la produjo. Sin ella, no puede saberse si el elemento tenía foco, si el puntero estaba encima o si solo quedó visible después de mover la página con el ratón. Los pasos de reproducción convierten una observación de diseño en un defecto corregible.
Separar el contorno del elemento que identifica
Focus Visible trata la indicación visible del foco del teclado. Focus Not Obscured trata el propio componente. Están relacionados, pero responden preguntas distintas. Un contorno cuidadosamente diseñado no rescata un control escondido debajo de otro panel.
La distinción debe aparecer en los comentarios de revisión. “El contorno necesita más contraste” pide un cambio de estilo. “El campo activo queda debajo del pie” pide cambiar la disposición o el desplazamiento. Reunir ambos bajo “problema de accesibilidad” facilita corregir lo equivocado y cerrar la incidencia.
El criterio mínimo permite visibilidad parcial. El criterio mejorado de nivel AAA exige que el componente enfocado no quede oculto. Un equipo puede elegir ese comportamiento más exigente sin afirmar que cumple todos los demás requisitos AAA. La condición de aceptación elegida debe quedar explícita.
Reservar al desplazamiento el espacio que ocupa la interfaz
La técnica C43 de W3C muestra cómo usar padding y scroll padding para mantener el contenido enfocado fuera de un aviso fijo. También cambia la disposición en tamaños pequeños, en vez de conservar una capa fija a cualquier precio. Fijar un panel es una decisión de diseño, no una exigencia del navegador.
En una implementación concreta, primero debe identificarse qué elemento se desplaza realmente. Un panel de administración puede desplazar su zona central mientras el documento exterior permanece quieto. Aplicar un desplazamiento al contenedor equivocado puede dejar intacta la superposición. Hay que inspeccionar la pantalla completa, no copiar una declaración a los estilos globales y dar el trabajo por terminado.
Después deben considerarse los cambios de contenido. Un aviso traducido puede ocupar más líneas; un error puede aumentar la altura del pie; una persona puede ampliar el texto. Se reserva espacio según la disposición real, o el componente vuelve al flujo normal cuando queda poca superficie útil. Son alternativas para evaluar, no una receta universal.
Tras cambiar la disposición, se repite la misma secuencia con teclado. También se comprueba qué ocurre al cerrar la capa. El espacio que continúa reservado cuando su propietario desaparece puede generar otro defecto. La regresión debe cubrir tanto la presencia como la retirada, porque ambos estados llegan a los lectores.
Un modal implica un compromiso de interacción
Convertir una capa en modal puede impedir que el teclado navegue detrás, pero solo si realmente se comporta como un modal. El patrón de diálogo de ARIA Authoring Practices describe el traslado del foco al interior, la contención de la secuencia Tab, el cierre con Escape y la gestión del foco al cerrar.
No conviene elegir un modal únicamente para superar una prueba de superposición. La pregunta es si la tarea exige terminar o cerrar el panel antes de continuar. Una ayuda opcional y una confirmación destructiva tienen propósitos distintos. Una interrupción innecesaria puede resolver la geometría y dificultar el flujo.
Cuando sea posible, se reutiliza el componente de diálogo existente. Deben revisarse el punto de apertura y el destino tras el cierre, además del diálogo. Si el control original desapareció después de completar una operación, hace falta elegir deliberadamente el siguiente destino. Depender del orden accidental del documento es frágil.
Conservar evidencia pequeña y repetible
Para cada recorrido importante se guardan la ruta, el navegador y tamaño de ventana, el estado inicial, la secuencia de teclado y el resultado observado. Se incluye el identificador real de la compilación. Una prueba correcta sobre la vista previa de la semana pasada no demuestra el comportamiento de la versión que se publica hoy.
El defecto se asigna al componente o integración responsable de la obstrucción. Si varios equipos pueden añadir avisos fijos de forma independiente, resulta más útil acordar una disposición compartida que aumentar repetidamente los márgenes de formularios aislados. Ese acuerdo debe indicar qué regiones pueden superponerse, cuáles desplazan contenido y cómo comunican el espacio ocupado.
La automatización ayuda a conservar una regresión reproducida, pero el equipo sigue necesitando inspeccionar el resultado. Un programa que confirma que un elemento existe o tiene foco no demuestra por sí solo que una persona pueda verlo. La comprobación debe corresponder al fallo concreto que se quiere evitar.
Qué no cambia
Esta revisión cubre una parte limitada de la usabilidad con teclado. No demuestra un orden de foco significativo, nombres accesibles correctos, comportamiento completo con lectores de pantalla ni conformidad general con WCAG. Las técnicas enlazadas orientan la implementación; no sustituyen la evaluación de todos los requisitos aplicables.
Tampoco afirma cuánto ingreso recupera una corrección del foco. La evidencia inmediata es más sencilla: una persona puede localizar el control que está a punto de usar, en un estado que el producto admite. Es una propiedad concreta que un equipo de ingeniería puede reproducir y mantener entre versiones.
Escrito por Dandelion Labs