Por qué evito los modales

Este post nace de una charla que tuve con un junior dev. Me mostró un sistema de gestión que armó y me pidió feedback de varias secciones. Lo central de esa charla terminó siendo el exceso de modales: estaban en todos lados, para todo. Acá va lo que le dije.

Los modales rompen el flujo y la continuidad de navegación del usuario. Por eso mi consejo es no usarlos como comodín para mostrar información adicional.

De acuerdo. El modal aparece casi siempre como atajo de diseño:
"no sé bien dónde meter esto, lo flotamos arriba de todo". Es un
patrón que tapa decisiones de arquitectura. La factura la paga
el usuario, que pierde contexto cada vez que aparece uno.

Antes de meter algo en un modal hay que hacer un análisis fuerte. La jerarquía que uso es: primero pensá si puede ser una página propia, después si puede ser una sección colapsable, y recién al final, si nada de lo anterior aplica, considerás un modal. Saltearse ese análisis es lo que termina con sistemas llenos de modales sin sentido.

Esa jerarquía cambia la pregunta que te hacés antes de abrir nada.
Empezás cada decisión preguntándote si lo que tenés justifica
realmente un modal, y descubrís que la mayoría de las veces la
respuesta es no.

Forms y CRUD

Con "información adicional" incluyo meter un form completo dentro de un modal. Generalmente eso se puede evitar, pero si tu página tiene modales para editar cosas, hay algo que no está bien planteado. Muchas ediciones se pueden resolver inline, y otras directamente piden una página entera.

Cada campo abajo del fold es un campo que el usuario no sabe que
existe hasta que scrollea. Y si el form valida al guardar, los
errores aparecen en inputs fuera del viewport, así que el modal
hace scroll para mostrarte el primer error y vos perdés el resto
del formulario. Un anti-patrón redondo.

Steppers son tu amigo

Si después de toda esa evaluación seguís pensando que sí o sí va un form en un modal, pongamos agregar un cliente o cualquier CRUD parecido, y tiene varios inputs, agrupalos en steps. Un modal con scroll interno trae problemas, sobre todo de validación: ¿cómo le mostrás al usuario que faltó completar algo que está fuera del viewport?

No le tengas miedo a la granularidad. Incluso un solo input por step es válido si eso permite foco claro y validación inmediata. Si hay campos opcionales, dejá que el usuario los saltee sin pelearle. La regla es: menos por paso = mejor experiencia.

Stepper resuelve dos cosas a la vez: limita la cantidad de inputs
visibles al mismo tiempo (menos abrumador) y te da puntos
naturales para validar antes de avanzar. Si el usuario se equivoca
en el step 2, le mostrás el error ahí mismo, no después de haber
completado los siete pasos. Y los campos opcionales con skip
explícito evitan que el form se sienta como un interrogatorio.

El problema en mobile

Yendo a lo visual: el problema real arranca cuando bajás a viewports chicos. Tablet zafa más o menos, salvo cuando aparece el teclado on-screen. Pero mobile se vuelve un desafío: el teclado te come fácil un 40% de la pantalla. Y si el usuario tiene el celular en landscape, el teclado ocupa entre 70% y 80%. Abrir un modal arriba de eso es una locura. Sumale que un modal bien hecho no va pegado al borde del celular: necesita un mínimo de padding al borde, y de nuevo, padding interno. Todo eso recorta todavía más el espacio útil para lo que realmente importa: el contenido.

Y otro problema visual: el horizontal shift. Cuando abrís un modal en una página alta, lo normal es bloquear el scroll del fondo. En desktop eso hace que desaparezca la scrollbar vertical de la página, y al cerrar el modal vuelve a aparecer. Es un saltito desprolijo e inevitable. Lo que no siempre es inevitable es el modal mismo.

Y en mobile el modal compite con el navegador del browser, que
también ocupa espacio. Entre la barra de URL, el teclado y los
márgenes mínimos del modal, te queda una ventana usable
ridículamente chica. La gente termina diseñando "modales mobile"
que son básicamente páginas full-screen, lo cual ya admite la
realidad: lo que necesitabas era una página.

Accesibilidad: no es divertido

Después está todo el tema de accesibilidad. Un modal hecho bien necesita focus trap (que el tab no se escape al fondo), ESC para cerrar, restaurar el foco al elemento que lo abrió cuando cerrás, anunciar al screen reader con role="dialog" y aria-labelledby, mover el foco al primer input al abrir, bloquear el scroll del fondo sin romper iOS, y testearlo con teclado y lector de pantalla, no solo con mouse.

Nunca es divertido tener todo eso en cuenta. Pero si lo querés hacer bien, no es opcional. Y es otra razón más para preguntarse: ¿de verdad necesito un modal acá?

La a11y es la prueba de fuego. Si tu modal no funciona con
teclado o screen reader, dejaste afuera a toda la gente que
navega así. Y eso aplica también al backdrop: si lo único que
lo cierra es clickear "X" con el mouse, ya estás fallando.

Cuándo sí: acciones destructivas

En mi experiencia, los modales sirven cuando hay que llamar la atención sobre acciones destructivas o confirmaciones importantes. Eliminar un cliente, reportar un comentario, cambiar el estado de un elemento. Ese tipo de cosas.

Acá la fricción está puesta a propósito. Querés que el usuario
frene, lea y decida. Para todo lo demás (acciones reversibles,
pequeños cambios de estado) un toast con undo le saca al usuario
el peso de tener que confirmar algo que en realidad se puede
deshacer en un click.

Una regla que aplico: si el modal NO está bloqueando una decisión
irreversible, probablemente no debería ser un modal.