¿Cuántas veces te pasó que, por asegurarte de que completen todo en un formulario antes de enviarlo, deshabilitás el botón… sin indicar qué deben hacer para que se habilite? Suena medio a trabalenguas, pero, acá te ayudo a desenredar un poco la cuestión.

Primero lo primero: ¿qué es un botón?

Nielsen Norman Group define un botón como “un elemento fundamental de la interfaz que, al hacer click o tap, ejecuta una acción. Cuando están correctamente diseñados, los botones setean expectativas y ayudan a las personas a entender cómo interactuar con el sistema.”

Estados de un botón

La buena práctica es que un componente de botón tenga diferentes estados para dar feedback a la persona usuaria y comunicarle qué está pasando. Los estados más comunes son:

• enabled: es el estado por default y el que indica que el botón puede ser clickeado.
• focus: aparece al navegar el sistema con teclado, se caracteriza por tener una línea que lo rodea e indica que lo estamos seleccionando.
• hover: es propio de desktop y es el cambio de color que sucede cuando nos movemos por encima del componente para denotar que podemos hacer click sobre el mismo.
• pressed: aplica tanto a desktop como mobile, es el cambio de color cuando lo presionamos y nos permite entender que algo está sucediendo.
• disabled: el que nos reune en este artículo, normalmente se usa un gris o el mismo color más claro para indicar que no podemos ejecutar la acción.

¿Por qué deshabilitar un botón es una pésima idea?

Como mencionaba al comienzo, a veces nos parece lógico deshabilitar el botón en un formulario o el botón primario de una pantalla hasta que la persona usuaria cumpla con todos los requisitos para poder ejecutar una acción. Nos parece obvio lo que hay que hacer para que el botón se habilite. Tomemos de ejemplo el formulario para crear un juego de preguntas y respuestas en el que para que se habilite el botón debemos:

• completar la pregunta,
• completar, al menos, 2 opciones de respuestas, y
• elegir una de las opciones como respuesta correcta.

Recién cuando la persona complete todos esos pasos, se le habilita el botón de iniciar partida.

Esta solución, sin embargo, le puede traer múltiples problemas a nuestras personas usuarias:

• es confuso: las personas pueden cuestionarse qué está pasando que el botón no está habilitado: ¿habrá pasado algo? ¿no habrá terminado de cargar? ¿qué me faltó completar?
• genera problemas de comunicación: ¿le estamos diciendo a la persona usuaria qué hacer para habilitar el botón o esperamos que lo adivinen o deduzcan? En nuestro caso puntual, son muchas acciones a realizar antes de habilitar el botón.
• mala accesibilidad: salvo que le agreguemos los atributos de manera manual, en web un botón deshabilitado por default no tiene estado de foco. Esto es un problema grave para las personas usuarias de tecnologías asistivas o que naveguen con teclado porque nunca se enterarán de la existencia del botón y no podrán entender el sentido de la pantalla o cómo continuar, ¿de qué me sirve un formulario sin botón?
• flujo interrumpido: en lugar de permitir una experiencia fluida y sin inconvenientes, forzamos a la persona usuaria a pensar, a cuestionarse o buscar alternativas de solución, generando una mala experiencia.

Entonces, si deshabilitamos el botón para evitar que se ingrese información errónea o para que se cumplan todos los requisitos para proseguir con el flujo pero no habilitamos el botón, ¿cómo van a saber nuestras personas usuarias qué les falta o en qué se esán equivocando?

Retomando el ejemplo, veamos que cambios complementarios debemos hacer para habilitar el botón y que la experiencia sea más intuitiva:

1. Agregamos una breve explicación debajo del título detallando los pasos a seguir.

2. Al habilitar el botón, si quiero iniciar y falta un campo, el foco se posará en el primer input que falte con su error correspondiente para que la persona entienda qué está pasando.

3. Marcamos la primera opción como correcta por default cosa de siempre tener una opción marcada y que la persona pueda, opcionalmente, elegir otra opción. Esto ataja el error y evita dar más explicaciones.

La solución ideal

Si algo sabemos en UX es que la solución perfecta no existe, hay soluciones que pueden servir mejor o peor acorde a las particularidades de cada situación. Ahora, si algo vimos es que deshabilitar un botón por default no está para nada bueno.

¿Qué podemos hacer entonces? Lo importante es que de nuestra parte sabemos muy bien qué necesita hacer la persona usuaria para ejecutar la acción deseada. Por lo que podemos listar estos requerimientos y asegurarnos de comunicarlos de manera clara, siempre dando accionables para ejecutar dichas acciones o enmendar sus errores de manera lógica y predecible.

Algunos tips antes de cerrar

• Incluí los estados de error con mensajes claros y concisos sobre qué hacer si la persona aprieta un botón y necesita recuperarse de algo que falló o que faltó. Acá la buena práctica es llevar el foco al primer elemento con error y su respectivo mensaje aclarando el problema.
• No uses un tooltip para explicar qué hay que hacer para habilitar el botón. Si tan claro es lo que hay que hacer, no escondas esa unformación en un tooltip haciendo que la persona tenga que buscarlo o que se lo encuentre por error. Los tooltips no son elementos accesibles por default, por lo que, si se van a usar de manera visual, hay que construir bien la relación e interacción entre HTML, CSS y JS para que el mismo pueda utilizarse con el lector de pantalla, problemas que se ahorran si desde el comienzo el flujo está pensado de otra manera que simplifique la comprensión e interacción para todo tipo de persona usuaria.
• Si te preocupa que al apretar un botón más de una vez se envíe la solicitud o se envíe la información múltiples veces, se puede deshabilitar al botón mientras está cargando, siempre dando feedback a la persona de lo que sucede.
• Si no te queda alternativa e igual vas a deshabilitar el botón por motivos de fuerza mayor, sabé que existe el atributo ARIA-disabled=true para que el botón siga recibiendo foco al navegar con teclado y que los lectores de pantalla mencionen su existencia y su estado actual.

¿Y vos? ¿Sabías cómo manejar accesiblemente los estados de los botones? Contame en los comentarios 💬 y dejame algunos aplausos si te sirvió el artículo👏.