Clases de color de Tailwind CSS: formularios y estados

Las clases de color de Tailwind CSS actúan sobre propiedades distintas: text-* colorea el texto, bg-* la superficie y border-* el borde. Elige la combinación completa, define los estados de interacción y comprueba el resultado renderizado. El número de un tono no es una puntuación de contraste ni garantiza que un control se entienda.

Trabajaremos con un formulario ficticio para invitar a una persona a un espacio de trabajo: correo, botón Enviar invitación y respuesta al envío. Las recetas y muestras propuestas son recomendaciones de diseño. Permiten tomar decisiones concretas sin convertir una paleta en una afirmación de conformidad de accesibilidad.

Separa texto, superficie y borde

Empieza con tres preguntas: qué necesita leer la persona, qué área contiene ese contenido y qué límite identifica el control. Las referencias de color del texto, color de fondo y color del borde documentan las utilidades correspondientes. Anota cada responsabilidad junto al formulario antes de escoger una familia cromática.

Para el panel de invitaciones, prueba una superficie blanca, texto oscuro y un campo de correo identificable. Una receta inicial puede usar bg-white text-slate-900 en el panel y border border-slate-500 en el campo. Revísala dentro de tu proyecto con su tipografía, los estilos existentes y la página que rodea el formulario.

Usa border para establecer un ancho visible y border-slate-500 para elegir su color. Mantén ambas decisiones separadas durante la revisión. Si desaparece el límite del campo, inspecciona también el ancho y el estilo calculados. Cambiar de tono no resuelve una propiedad ausente ni demuestra por sí mismo que el control resulte identificable.

Una nota útil de entrega distingue superficie del panel, límite del campo y texto introducido. Añade una razón breve a cada elección, por ejemplo: «el campo debe identificarse sobre el panel blanco». Esa indicación permite comprobar el resultado mejor que una petición genérica de oscurecer todo el formulario.

Elige combinaciones, no números de tono

Compara muestras completas en lugar de cuadrados aislados. Coloca el correo realista, la frase de ayuda y la etiqueta de la acción sobre sus fondos previstos. La documentación de colores de Tailwind ofrece una paleta compartida por distintas utilidades; no certifica todas las parejas de primer plano y fondo que puedas formar.

La muestra de paleta de EmviUI ilustra roles con nombre, pero contiene referencias incoherentes, incluidas etiquetas Red bajo muestras verdes. No copies esas etiquetas como mapa de código; inspecciona los valores seleccionados en tu archivo. Prepara una franja de revisión con tres usos: texto normal sobre el panel, etiqueta de la acción principal sobre su relleno y mensaje de error junto al campo. Conserva los tamaños y pesos que tendrá la interfaz. Una muestra grande en una presentación puede ocultar un problema evidente en una línea pequeña de ayuda.

Anota para cada propuesta el primer plano, el fondo y el estado. Incorpora el resultado medido después de revisar la combinación renderizada. Si el tema modifica un color con nombre, importa ese valor calculado. Dos proyectos pueden compartir una clase y mostrar superficies diferentes debido a su configuración o a las reglas que las rodean.

No trates blue-600 y red-600 como pruebas visuales equivalentes. Esas etiquetas identifican entradas de una escala, no un resultado común de accesibilidad. Nuestra recomendación es elegir pocas parejas para este formulario y conservar sus mediciones junto al diseño. Repítelas si cambian la marca, la superficie o la transparencia.

Si necesitas nombrar decisiones reutilizables para muchas pantallas, continúa con la guía de tokens en diseño web. Para esta tarea, termina primero un formulario legible y comprensible antes de ampliar su vocabulario de colores a toda una biblioteca.

Distingue el foco de la validación

Representa el foco y el error como información independiente. El foco señala dónde interactúa la persona; la validación indica un problema con el valor introducido. Un correo incorrecto puede conservar el foco de teclado. El diseño propuesto debe mostrar ambas cosas a la vez sin que una oculte la otra.

Reserva un indicador propio alrededor del campo para el foco y utiliza el borde y el mensaje de error para explicar la validación. En nuestra muestra, «Introduce un correo completo» permanece debajo del campo. Añade un contorno exterior al activar el control. No sustituyas la instrucción por un brillo rojo difícil de interpretar.

La documentación de variantes de estado de Tailwind explica utilidades condicionales como hover: y focus-visible:. Aplícalas al elemento previsto e inspecciona el resultado con el teclado. La respuesta al puntero aporta una señal útil, pero no demuestra cómo se presenta el foco ni cómo funciona la validación.

Crea cuatro muestras: neutra, con foco, incorrecta e incorrecta con foco. Mantén el mismo tamaño y el mismo correo para comparar las señales sin distracciones. En la cuarta, confirma que el texto de error siga siendo legible y el indicador de foco permanezca visible junto al borde rojo.

Describe el comportamiento aparte del estilo. Decide cuándo se valida, cómo se conserva el correo después de un envío fallido y cuál es el siguiente paso. Las utilidades de color no validan direcciones ni envían invitaciones. Son la capa visual de una interacción que la aplicación todavía debe implementar y comprobar.

Para organizar estas muestras en el archivo de diseño, consulta las variantes de Figma para estados de interfaz. Mantén clara la diferencia entre la apariencia de un estado y el evento real que lo activa en la aplicación.

Mide la combinación renderizada

Mide el texto normal frente a su fondo real. Contraste mínimo de WCAG establece 4,5:1 para texto normal y 3:1 para texto que cumple la definición de gran tamaño, con excepciones. Guarda el resultado unido a una pareja concreta, como «texto de ayuda sobre blanco», en vez de atribuirlo a toda la paleta.

Separa esa medición de la identificación del control. Contraste no textual de WCAG aborda la información visual necesaria para identificar controles y estados, con 3:1 frente a colores adyacentes y excepciones. La señal relevante puede ser el borde u otro rasgo; el criterio no exige lo mismo a cualquier separador decorativo.

Nuestra ficha de revisión propuesta tiene cuatro columnas: muestra, señal de primer plano, superficie adyacente y resultado. Añade otra fila si la señal toca una superficie diferente. Por ejemplo, revisa el campo dentro del panel blanco y dentro de una notificación teñida sin suponer que una medición sirve para ambos contextos.

Comprueba los rellenos transparentes sobre la superficie que habrá realmente debajo. Una propuesta bg-blue-500/10 tiene una función distinta de un relleno sólido para la acción principal. Revisa su aspecto compuesto. Inspecciona también la opacidad del padre, las capas superpuestas y el texto heredado si el resultado difiere del diseño previsto.

Los diagramas de este artículo explican el proceso; no certifican las mediciones de tu aplicación. Conserva los valores comprobados, el estado y la fecha para saber qué repetir cuando cambie un color. Así, una revisión futura puede contrastar una muestra concreta en lugar de discutir únicamente si parece suficientemente oscura.

Explica el estado sin depender del color

Escribe el estado primero y utiliza después el color para reforzarlo. «Invitación enviada a alex@example.test» comunica algo distinto de «No se pudo enviar la invitación; inténtalo de nuevo». Una marca verde o roja aislada obliga a deducir tanto el resultado como las posibilidades de recuperación.

La explicación de Uso del color de WCAG requiere otro medio visual cuando el color transmite significado. Nuestra propuesta combina una frase comprensible con un icono distinguible y una acción cuando procede. Comprueba que las palabras sigan siendo útiles si dejas de mirar el color de su contenedor.

Compara tres mensajes: invitación pendiente, enviada y solicitud fallida. Usa el mismo destinatario en todas las muestras. El primero puede decir «Enviando invitación»; el segundo confirma la dirección; el tercero explica si se puede reintentar. Son mensajes de producto propuestos, no pruebas de que una petición se haya completado.

Distingue una advertencia de un error que bloquea el envío. Si ya existe una invitación para esa dirección, explica el siguiente paso en vez de reutilizar exactamente el tratamiento de un correo mal formado. Una redacción precisa reduce la cantidad de diferencias cromáticas que la persona necesita aprender.

En una tabla de invitaciones, conserva una etiqueta explícita de estado en cada fila. Un punto de color puede acompañarla. Prueba la traducción más larga en el ancho real de la columna y comprueba que permanezca visible al cambiar la distribución. La revisión de color debe incluir el contenido que se intenta comunicar.

Revisa una muestra de campos de EmviUI

La web de EmviUI ofrece un kit de interfaz y un sistema de diseño editables en Figma. La muestra real de campos que aparece debajo permite comparar tratamientos neutros, atenuados y rojos. Es un recurso de diseño, no una captura del formulario Tailwind funcionando ni una prueba de contraste.

Úsala para acordar qué texto corresponde al valor, cuál es la ayuda y qué cambia cuando el campo requiere atención. Los ejemplos inferiores combinan borde rojo, icono de alerta y texto de apoyo rojo. Sustituye las frases genéricas por instrucciones relacionadas con la invitación y con la corrección que se necesita.

Después añade las pruebas de tu implementación: inspecciona los colores elegidos, acuerda el indicador de foco, mide las combinaciones y prueba la interacción en el navegador. El kit acelera la consistencia visual; el equipo sigue teniendo que comprobar el comportamiento de la aplicación y el contexto de la página completa.

También inspeccionamos la imagen del repositorio llamada accessibility-web-colors. Su cuadrícula de porcentajes no demuestra las relaciones WCAG de estos controles, por lo que no la incluimos. La muestra de campos permite explicar una decisión visible sin presentar afirmaciones de medición que la imagen no sostiene.

Para decidir qué lógica mantener en utilidades y qué concentrar en reglas de componente, consulta Tailwind CSS frente a CSS para estilos de interfaz. Asigna un responsable claro a la receta del campo y evita que un cambio local entre en conflicto con otra regla.

Repite una revisión de color verificable

Antes de publicar el formulario, prepara una ficha breve de aceptación centrada en la invitación. Anota el fondo real de la página, el tema, el estado del campo y el mensaje esperado. Incluye entrada normal, foco, correo incorrecto, petición fallida y resultado correcto. Reutiliza las mismas muestras después de modificar la paleta.

Primero interpreta el formulario sin depender del tono: identifica campo, acción y resultado mediante sus etiquetas y su estructura. Después recorre los controles con el teclado y observa el foco. Mide a continuación las parejas de texto y las señales no textuales relevantes en sus estados renderizados.

Por último, compara las etiquetas originales y traducidas en el ancho real. Una explicación más larga no debe ocultar la acción ni sacar una palabra importante del contenedor. Guarda el mensaje esperado y el fallo observado para comprobar la corrección. Una revisión útil debe poder repetirse por otra persona del equipo.

1. Guarda colores calculados y superficie adyacente de cada muestra.
2. Anota relaciones medidas y el requisito que comprueba cada una.
3. Revisa error y foco simultáneos; después prueba la recuperación.
4. Repite la tarea completa si cambia el tema o alguna opacidad.