Colores de botones: texto, relleno, borde, hover y focus

Tratar cada estado como una pareja de color completa

Empieza por roles semánticos de estado, no por una muestra de marca. Un botón primario relleno incluye etiqueta, relleno, posible borde, icono y superficie circundante. Los estados de sobrevuelo y activación pueden cambiar el relleno; el foco añade un indicador que toca tanto el control como la página. Un botón secundario o con contorno crea otro grupo de colores adyacentes. Registra cada primer plano, fondo y límite. No deduzcas que un sobrevuelo más oscuro cumple porque cumplía el estado inicial: hay que recalcular el contraste del texto, la visibilidad del límite y la relación del foco para el estado realmente renderizado.

• Enumera los estados inicial, de sobrevuelo, activo, con foco, deshabilitado, en carga y seleccionado que el componente realmente pueda mostrar.
• Registra etiqueta, icono, relleno, borde, indicador de foco y superficie alrededor para cada variante.
• Trata primary, secondary, destructive y quiet como contratos separados, no como una muestra recoloreada.
• Conserva la semántica button nativa para que teclado y nombre accesible no dependan de la paleta.

Medir texto, límite y foco según su función

El texto de la etiqueta se evalúa contra el relleno renderizado. El criterio 1.4.3 de WCAG 2.2 exige generalmente al menos 4,5:1 para texto normal y 3:1 para texto grande según definiciones y excepciones. El contraste no textual cubre información visual necesaria para identificar componentes y estados; cuando relleno o borde aportan esa información, se comprueban respecto de colores adyacentes bajo 1.4.11. Los indicadores de foco tienen requisitos separados y deben percibirse en el estado enfocado. Una sola relación no certifica los tres trabajos, pues cada comparación utiliza píxeles y significado distintos.

Implementar estados sin perder el foco

El ejemplo usa colores explícitos para medir cada pareja. Es ilustrativo, no una paleta universalmente conforme: propiedades de fuente, superficies vecinas, renderizado y variantes todavía requieren pruebas. :focus-visible presenta un indicador fuerte de estilo teclado en navegadores compatibles, y la política de soporte debe mantener un fallback apropiado. El contorno está desplazado para no fusionarse con el borde, pero puede tocar varios fondos en un diseño denso. Nunca elimines el contorno del agente de usuario salvo que el reemplazo sea al menos igual de visible en todos los estados y contextos donde overflow pueda recortarlo.

.button {
  color: #ffffff;
  background: #4338ca;
  border: 2px solid #4338ca;
}

.button:hover { background: #3730a3; }
.button:active { background: #312e81; }
.button:focus-visible {
  outline: 3px solid #6d28d9;
  outline-offset: 3px;
}

.button[disabled] {
  color: #64748b;
  background: #e2e8f0;
  border-color: #cbd5e1;
}

Diseñar deliberadamente el sobrevuelo, la activación, la carga y la deshabilitación

El sobrevuelo es una respuesta para el puntero y no sustituye el foco de teclado. El estado activo o pulsado puede durar poco, pero la etiqueta no debe desaparecer durante la activación. Durante la carga, el control conserva un nombre accesible y comunica el progreso sin depender solo de un cambio cromático; el indicador no debería desplazar el diseño. Algunos criterios contemplan excepciones para controles deshabilitados, aunque volverlos extremadamente tenues dificulta comprender las acciones o el motivo del bloqueo. Pregunta si realmente debe deshabilitarse el control y ofrece validación o texto explicativo junto a él cuando falta un requisito recuperable.

• Recalcula el contraste de etiqueta después de cada cambio de relleno; más oscuro no siempre es mejor.
• Mantén el sobrevuelo como respuesta para el puntero y un foco separado y visible para la navegación por teclado.
• Combina la carga con un estado programático y un nombre accesible estable, no solo con una animación de color.
• Deshabilita únicamente acciones no disponibles y explica cerca los requisitos que puedan corregirse.
• Aplica semántica como aria-pressed para los estados seleccionado o pulsado cuando el botón funcione como conmutador.

Contar con alfa, gradientes, iconos y superficies anidadas

Los rellenos y bordes translúcidos no tienen un color final independiente de la página. Compónlos sobre cada superficie permitida antes de calcular contraste. En un botón con gradiente revisa posiciones relevantes detrás de etiqueta e icono, no solo extremos. Los iconos que comunican la acción necesitan visibilidad suficiente y un nombre accesible mediante texto visible u otro mecanismo; los decorativos no deben generar anuncios redundantes. Cuando el botón está dentro de banner, tarjeta, diálogo, sobre imagen o contenedor deshabilitado, usa ese color circundante para borde y foco. Los tokens compartidos solo son válidos en sus contextos documentados.

Ejecutar una matriz de componentes antes de publicar

Renderiza cada variante sobre cada superficie con etiquetas, iconos, ajuste de línea y localización reales. Navega mediante teclado, puntero, tacto y tecnología de asistencia adecuada. Inspecciona el foco con zoom normal y aumentado, incluidos botones cerca de bordes donde overflow recorta el contorno. Prueba alto contraste o forced-colors y verifica que la semántica nativa exponga controles y estados. Los chequeos automáticos ayudan con parejas deterministas, pero gradientes, alfa, fondos dinámicos, animación y recorte necesitan inspección renderizada. Guarda la matriz junto a los tokens para repetir la evidencia cuando cambie la paleta.

• Renderiza variantes primary, secondary, quiet, destructive, icon-only y toggle que existan.
• Ejercita los estados inicial, de sobrevuelo, activo, con foco, en carga, deshabilitado, junto a errores y seleccionado.
• Prueba todas las superficies, incluidas tarjetas, diálogos, banners, tablas y regiones sobre imágenes.
• Repite contraste y foco tras cambiar tipografía, espacio, borde, sombra o tokens compartidos.