La capa visual es la parte fácil
Un modal no se define por un fondo oscuro y una tarjeta centrada. Se define por un contrato de interacción: el resto de la página deja de estar disponible, el foco entra en el diálogo, la navegación con teclado permanece dentro y el foco vuelve a un lugar intencional cuando el diálogo se cierra.
Según la revisión del 28 de septiembre de 2026, el patrón de diálogo modal de WAI-ARIA Authoring Practices describe ese contrato de forma directa. El HTML Standard ofrece un mecanismo del navegador para volver inerte el contenido del fondo. Ninguna fuente promete que un componente con el rol correcto se comporte bien por sí solo.
Esto importa porque un modal suele proteger los momentos de mayor riesgo de un producto: eliminar un registro, confirmar un pago, conceder acceso o cambiar una configuración de cuenta. El componente puede parecer terminado mientras envía a una persona que usa teclado o tecnología de asistencia hacia controles situados detrás de la capa.
La revisión práctica no es “¿se muestra el diálogo?”. Es “¿puede una persona entrar, comprender, operar, salir y continuar sin perder su lugar?”.
Decidir dónde entra el foco
Abrir un diálogo cambia el contexto. El foco debe entrar en él, pero “enfocar el primer botón” no es una regla completa.
El patrón APG recomienda elegir el destino inicial según el contenido y la consecuencia del diálogo. Si contiene varios párrafos o una explicación estructurada, enfocar un encabezado estático con `tabindex="-1"` puede permitir que la persona encuentre la información antes que las acciones. Si la acción es difícil de revertir, la opción menos destructiva puede ser el destino inicial más seguro. Si el diálogo es breve y rutinario, la acción más probable puede ser adecuada.
La elección debe formar parte de la API o de los criterios de aceptación. Dejarla al orden del DOM permite que un cambio visual modifique la interacción. Un icono de cierre añadido antes del título puede convertirse en la primera parada, aunque primero deba leerse un error.
Hay que probar el destino inicial en el punto donde se abre el diálogo real. Las vistas previas del componente son útiles, pero no reproducen el estado de la página, la posición de desplazamiento, el mensaje de validación o el control de apertura que existen en producción.
También debe revisarse qué queda visible después del movimiento del foco. Enfocar un control cercano al final de un diálogo largo puede desplazar fuera de la vista el título y el contexto. En ese caso, un elemento estático cerca del comienzo suele ser un mejor punto inicial que el primer control interactivo.
Hacer que el fondo no esté disponible, no solo más oscuro
Un fondo semitransparente cambia la apariencia. No necesariamente elimina de la navegación los enlaces, botones y campos que están detrás.
El modelo `inert` de HTML vuelve un elemento y sus descendientes del árbol plano indisponibles para recibir foco, activarse, seleccionar texto, editarse y aparecer en el árbol de accesibilidad. Un `dialog` nativo abierto con `showModal()` participa en el comportamiento modal del navegador y vuelve inerte el resto del documento mientras está activo.
Esto es más fuerte que añadir `aria-hidden="true"` a un contenedor. Ocultar una región del árbol de accesibilidad no impide por sí mismo que el teclado alcance un descendiente enfocable. Puede producir una combinación peor: el foco llega a un lugar que la tecnología de asistencia ya no expone.
En una implementación personalizada, el aislamiento del fondo debe verificarse como un comportamiento, no suponerse a partir de un grupo de atributos. Hay que recorrer los límites con Tab y Shift+Tab, intentar activar un control de fondo, comprobar el puntero e inspeccionar el árbol de accesibilidad. Si el framework ofrece un componente de diálogo maduro, conviene preferirlo a reconstruir la contención del foco para cada funcionalidad.
No debe marcarse un diálogo como modal si no se comporta como tal. La guía APG advierte que `aria-modal="true"` puede volver inaccesible el contenido exterior para algunas personas que usan tecnología de asistencia. Una afirmación modal inexacta puede ocultar la salida mientras la propia lógica de foco de la aplicación sigue escapando al fondo.
Tratar la contención de Tab como una máquina de estados
Dentro de un diálogo modal, Tab avanza por los controles disponibles. Desde el último vuelve al primero. Shift+Tab realiza la transición inversa. Escape cierra el diálogo cuando el producto permite descartarlo.
Los casos difíciles cambian durante la interacción. Una validación puede añadir botones, una solicitud puede desactivar una acción y un selector anidado puede abrirse. La lista de elementos navegables es un estado de ejecución, no una constante.
La contención debe probarse después de cada cambio de estado admitido. Si un botón de envío se desactiva mientras tiene foco, hay que decidir adónde se mueve el foco y qué escucha la persona. Si aparece un resumen de errores, hay que decidir si el foco se traslada allí o permanece en el campo. Si un modal anidado es inevitable, debe verificarse qué capa controla Escape y cuál restaura el foco.
No conviene usar valores positivos de `tabindex` como reparación. Crean un segundo orden de navegación que debe mantenerse separado del orden visual y del DOM. Es mejor corregir la estructura o el comportamiento del componente.
Una matriz de regresión pequeña basta para repetir la revisión: abrir con teclado, recorrer hacia delante, recorrer hacia atrás, provocar la validación, cerrar con el control visible, cerrar con Escape cuando esté permitido y repetir en una ventana estrecha.
Restaurar el foco al siguiente lugar útil
Cuando un diálogo se cierra, el patrón APG normalmente devuelve el foco al elemento que lo abrió. Esto conserva la ubicación de la persona y hace previsibles las acciones repetidas.
Sin embargo, el control puede dejar de existir. Puede eliminarse una fila, completarse un paso de configuración o reemplazarse la pantalla original. Devolver el foco a un elemento separado del documento no es una estrategia de recuperación. Dejarlo caer sobre el cuerpo de la página tampoco.
El destino alternativo debe definirse desde el flujo. Después de eliminar una fila, el foco puede pasar a la siguiente o a un encabezado estable que anuncie la vista actualizada. Después de crear un elemento, ese nuevo elemento puede ser el destino lógico. Tras completar una tarea de varios pasos, el control de la siguiente tarea puede resultar más útil que el activador desaparecido.
Por eso la restauración no puede vivir por completo dentro de un diálogo genérico. El componente puede recordar quién lo abrió, pero la funcionalidad conoce el significado del éxito y sabe si ese control sobrevive.
La cancelación y el fallo deben formar parte del mismo contrato. Cerrar sin aplicar cambios normalmente debe devolver el foco al activador original. Un error del servidor que mantiene abierto el diálogo no debe enviar el foco a la página que está detrás.
Revisar el producto ensamblado
Un componente reutilizable puede superar sus propias pruebas y aun así fallar tras integrarse. Los portales cambian la ubicación del diálogo en el DOM. Los atajos globales pueden interceptar Escape. Las notificaciones pueden robar anuncios. Una transición de ruta puede desmontar el activador antes de que se ejecute el cierre.
Conviene revisar un recorrido real para información, entrada de datos, confirmación y acciones destructivas. Deben registrarse el activador, el destino inicial, los límites, los métodos de cierre y el destino de restauración.
Las pruebas automatizadas pueden confirmar la contención y la restauración. No pueden decidir si el destino es el lugar más útil para continuar. Los flujos de alto impacto necesitan una breve revisión con teclado.
Qué no cambia
Un contrato de foco correcto no demuestra accesibilidad completa. El diálogo todavía necesita un nombre accesible, instrucciones claras, errores comprensibles, contraste suficiente, disposición adaptable y pruebas con las tecnologías de asistencia relevantes.
Tampoco significa que toda capa deba convertirse en modal. Un popover, un disclosure, un panel lateral o una expansión en línea pueden conservar mejor el contexto cuando la persona no necesita detener todo lo demás. La modalidad es una decisión de producto con costes de interacción, no un estilo visual predeterminado.
El estándar útil es más limitado: si la interfaz afirma que hay una interrupción modal, el fondo realmente no está disponible, el foco tiene una ruta intencional a través de la interrupción y el cierre devuelve a la persona a un lugar que todavía tiene sentido.
Escrito por Dandelion Labs