Un botón bloqueado elimina la acción de diagnóstico
Desactivar Enviar hasta que todos los campos parezcan válidos parece una medida de protección. Evita una solicitud inválida y da a la interfaz un estado simple: incompleto significa no disponible. El coste es que el usuario pierde la acción más clara para preguntar al producto qué está mal.
Según lo comprobado el 6 de octubre de 2026, el HTML Standard define dos efectos relevantes. Un control de formulario desactivado impide que se despachen eventos de clic en cola y queda excluido de la validación de restricciones. Si el control de envío está desactivado, el navegador no puede convertir el intento de envío en un evento de validación. El producto ha eliminado su propio disparador de diagnóstico.
No es solo una cuestión de accesibilidad. Una persona puede pasar por alto un campo obligatorio fuera de la zona visible, malinterpretar un formato aceptado o ver un valor que parece completo mientras el analizador de la aplicación lo rechaza. Un botón gris comunica que no se puede continuar, pero normalmente no explica por qué.
El contrato más sólido es simple: permite que el usuario intente la acción, valida en ese límite y devuelve una ruta precisa hacia cada problema. El servidor sigue decidiendo si la solicitud es aceptable. La interfaz decide si el fallo resulta comprensible y recuperable.
Mantén disponible la acción y valida al enviar
Enviar es un momento útil porque la intención del usuario no ofrece dudas. Está pidiendo continuar. En ese momento, el cliente puede ejecutar las mismas reglas visibles en todo el formulario, dirigir la atención al resultado y conservar todo lo que ya se introdujo.
Usa restricciones nativas cuando expresen el requisito real: required, un tipo de input apropiado, minlength, maxlength o un pattern defendible. Usa validación personalizada cuando la regla abarque varios campos o dependa de datos del dominio. En ambos casos, mantén la validación del servidor como autoridad. El código del cliente puede mejorar la respuesta, pero no puede proteger un endpoint frente a una solicitud modificada.
No esperes al envío para ofrecer todas las indicaciones. La guía de WCAG 2.2 sobre etiquetas o instrucciones indica que los inputs deben tener etiquetas o instrucciones cuando el contenido requiere entrada del usuario. Coloca formatos poco habituales, reglas de contraseña, unidades y estado obligatorio junto al campo antes de que la persona tenga que fallar.
La validación inline puede ayudar después de visitar un campo, sobre todo cuando una corrección pasa a ser válida. Evita declarar incorrecto un campo intacto al cargar la página. Eso convierte un formulario vacío en un muro de errores antes de que el usuario actúe. También entra en conflicto con la técnica de W3C para aria-invalid, que indica que no se debe establecer en true antes de realizar la validación.
Devuelve un mapa de errores, no un cambio de color
Cuando falle la validación, identifica los campos y describe cada error mediante texto. Ese es el núcleo del Criterio de Conformidad 3.3.1 de WCAG 2.2. Un borde rojo por sí solo puede mostrar que algo cambió sin explicar qué valor esperaba el sistema.
Para un formulario con varios campos, muestra un resumen de errores encima. Dale un encabezado, mueve allí el foco del teclado y convierte cada mensaje en un enlace al campo correspondiente. El patrón de resumen de errores de GOV.UK usa exactamente esa estructura y mantiene la redacción del resumen coherente con los mensajes inline. La coherencia importa: dos descripciones del mismo fallo obligan al usuario a comparar el producto consigo mismo.
Junto al campo, añade el mensaje al lado del input y conéctalo programáticamente. La técnica ARIA21 de W3C muestra aria-invalid="true" para un campo fallido y aria-describedby apuntando a su texto de error. Elimina aria-invalid cuando el valor pase la validación y no dejes una asociación obsoleta después de que desaparezca el mensaje.
La gestión del foco forma parte del modelo de errores. Mover el foco al resumen comunica a una persona que usa teclado o lector de pantalla la magnitud del problema y le ofrece una ruta. Enlazar cada elemento del resumen evita una búsqueda manual. Cuando el enlace mueve el foco a un campo, su etiqueta, valor actual, indicación y error deben aportar contexto suficiente para corregirlo.
Separa el estado de validación del estado de la solicitud
Hay un momento en el que desactivar Enviar puede ser útil: después de iniciar un envío válido, cuando una solicitud duplicada resultaría perjudicial. Ese es un estado de solicitud, no un estado de validación.
Haz observable la transición. Cambia la etiqueta visible o añade texto de estado cercano, comunica el progreso mediante una región live apropiada cuando sea necesario y conserva el foco de forma predecible. Si la solicitud falla, vuelve a activar la acción, conserva los valores introducidos y muestra el error del servidor en el mismo sistema de errores. Un botón que permanece desactivado después de un fallo de red crea un callejón sin salida.
No dependas del botón desactivado como único control frente a envíos duplicados. Las redes reintentan, los usuarios abren varias pestañas y los clientes pueden llamar directamente a un endpoint. Usa una clave de idempotencia u otra estrategia de deduplicación en el servidor cuando la operación lo requiera.
Modela el componente con estados distintos: edición, envío con errores de validación, enviando, fallido y completado. Cada estado debe definir si la acción está disponible, adónde se mueve el foco, qué mensaje se anuncia y si se conservan los valores. Es más fácil de probar que una colección de condiciones que, por casualidad, cambian la opacidad del botón.
Prueba la ruta de fallo como una ruta de producto
Un formulario no está terminado cuando funciona el happy path. Revísalo con un campo obligatorio vacío, un valor mal formado, una regla de dominio que solo conoce el servidor, una solicitud lenta y una solicitud fallida. Repite con navegación por teclado y en un viewport estrecho donde el campo inválido pueda quedar fuera del área visible.
Comprueba que Enter pueda enviar desde un campo de texto cuando ese comportamiento sea apropiado. Comprueba que el primer fallo de validación genere un resultado visible y programático. Sigue cada enlace del resumen. Corrige un error y confirma que los demás siguen siendo precisos. Vuelve a enviar sin perder valores. Después haz que falle la solicitud y verifica que la acción vuelva a estar disponible.
Instrumenta el límite sin tratar la telemetría como prueba de usabilidad. Los fallos repetidos de validación en un campo pueden revelar instrucciones poco claras. El abandono después de un estado desactivado puede revelar un callejón sin salida. Ninguna métrica explica por sí sola la causa, así que combínala con revisión de sesiones, evidencia de soporte o pruebas moderadas que respeten la privacidad del usuario.
Lo que esto no cambia
Un botón Enviar habilitado no es una licencia para mandar al servidor datos obviamente incompletos con cada pulsación. La validación puede seguir ejecutándose localmente y la solicitud solo debe salir del navegador después de superar las comprobaciones del cliente.
Tampoco es una prohibición universal de la progresión condicionada. Un paso puede no estar disponible de verdad hasta que termine una operación previa o exista una selección externa obligatoria. En ese caso, explica la condición incumplida junto a la acción, mantén la explicación perceptible sin hover y haz explícita la ruta para resolverla.
La regla más acotada resulta más útil: no uses un control de envío desactivado para ocultar la validación. Deja que el usuario exprese su intención, convierte el fallo en un mapa claro de errores, conserva su trabajo y reserva la desactivación temporal para una solicitud que realmente está en curso.
Escrito por Dandelion Labs