Da a cada estado una segunda señal visible
El criterio 1.4.1 de WCAG 2.2 establece que el color no debe ser el único medio visual para transmitir información, indicar una acción, solicitar una respuesta o distinguir un elemento. Por tanto, un error no puede expresarse solo volviendo rojo el borde. Añade un mensaje preciso, un icono cuyo significado también esté disponible como texto u otro tratamiento visual persistente. La misma regla cubre éxito, aviso, selección, obligatoriedad y valores modificados.
- Acompaña el color de error con «Introduce una dirección de correo válida», no solo con un contorno rojo.
- Acompaña el color de éxito con una confirmación que identifique la acción o el campo completado.
- Acompaña el color de aviso con una etiqueta o icono y explica si se puede continuar de forma segura.
Separa etiquetas, instrucciones y mensajes de validación
Una etiqueta persistente identifica lo que recoge un control; una instrucción explica el formato esperado; un mensaje de validación indica qué debe cambiar. No reúnas esas funciones en un placeholder ni en un asterisco coloreado. WCAG exige etiquetas o instrucciones cuando el contenido requiere entrada, y la identificación de errores exige describir en texto los errores detectados. Sitúa el mensaje junto al control, relaciónalo programáticamente y conserva el valor introducido siempre que pueda corregirse.
- Usa una etiqueta visible que permanezca después de escribir, en lugar de depender del placeholder.
- Indica las restricciones antes del envío, como el formato de fecha o la longitud mínima de contraseña.
- Tras validar, identifica el campo afectado y describe la corrección sin revelar datos sensibles.
Prueba por separado el texto y los límites del componente
El contraste del texto y el contraste no textual son comprobaciones diferentes. Según WCAG 2.2, el texto normal suele requerir al menos 4,5:1 y el texto grande que cumple las condiciones, al menos 3:1. La información visual necesaria para identificar componentes y estados suele requerir 3:1 frente a los colores adyacentes. Mide el mensaje sobre su fondo y después el borde de entrada, el indicador seleccionado, la marca de error y el foco según la información comunicada.
- Mide por separado la ayuda y el error; un borde intenso no compensa palabras con poco contraste.
- Compara un límite de entrada necesario con la superficie vecina cuando ese límite identifica el control.
- Comprueba iconos, marcas y señales de estado contra los colores contiguos, no contra otro fondo de la página.
Mantén el foco visible en todos los estados
El foco de teclado no equivale a hover, selección o validación. Un campo no válido que tiene foco debe mostrar a la vez dónde se dirigirá la entrada y por qué el valor es incorrecto. Conserva un indicador de foco propio en vez de sustituirlo por el borde de error. Pruébalo en estados normal, error, aviso y éxito, y junto a controles desactivados. Evita cambios de disposición al variar el grosor; un outline o espacio reservado mantiene estable el contenido.
- Usa un foco con área y contraste suficientes para los requisitos WCAG elegidos por el proyecto.
- Mantén la señal de foco visible cuando también haya borde de error, fondo relleno o selección.
- Comprueba orden y visibilidad con teclado, zoom, alto contraste y diseños responsivos estrechos.
Trata desactivado como una decisión de comportamiento
Los controles inactivos están exentos de varios requisitos de contraste WCAG, pero el bajo contraste por sí solo explica mal por qué una acción no está disponible. Un botón de envío inactivo puede ocultar requisitos pendientes. Cuando sea práctico, permite activar la acción y explica la validación después; cuando desactivar sea necesario, conserva una etiqueta legible, impide correctamente la interacción y explica el requisito junto al control. Nunca distingas activo e inactivo únicamente mediante color.
- Usa el estado disabled nativo solo cuando el control no pueda operarse realmente en el contexto actual.
- Explica el requisito previo, como aceptar términos o completar un campo obligatorio, antes de la acción no disponible.
- No simules la desactivación solo con gris: teclado, puntero y semántica de accesibilidad deben coincidir.
Revisa todo el recorrido de validación
Revisar muestras no basta sin interacción. Prueba el formulario intacto, el foco, una entrada válida, una entrada inválida, el envío, el rechazo del servidor, la corrección y el éxito. En formularios largos, añade un resumen de varios errores sin quitar los mensajes locales. Mueve el foco deliberadamente solo si ayuda a comprender el resultado. Confirma que los anuncios en vivo son breves y no se repiten con cada tecla. Documenta juntos colores, pares de contraste, textos, iconos y asociaciones programáticas.
- Verifica cada estado con teclado, zoom, lector de pantalla y al menos un modo de colores forzados.
- Registra los pares exactos de primer plano y fondo para repetir las pruebas tras cambiar tokens.
- Vuelve a probar errores asíncronos y del servidor, que a menudo eluden los estilos de validación local.
Fuentes primarias
Las afirmaciones de este artículo se comprueban con estas especificaciones publicadas.