Crear una paleta de modo oscuro sin limitarse a invertir colores

Empieza por los roles y no por invertir muestras

La inversión automática modifica cada canal de manera mecánica, pero el significado de una interfaz no está codificado en esos números. Una página blanca puede volverse negra mientras las tarjetas elevadas, los separadores, los controles desactivados, las ilustraciones y los estados pierden sus relaciones. Define primero roles semánticos: lienzo, superficie elevada, texto principal, texto secundario, borde, acento, peligro y foco. Asigna valores oscuros a cada rol de forma independiente. Así el código de los componentes permanece estable y la jerarquía visual se puede revisar. Un token con función documentada también resulta más claro que un nombre ambiguo como dark-gray-3.

• Utiliza al menos dos niveles de superficie para separar tarjetas y capas del lienzo sin depender únicamente de las sombras.
• Separa el texto principal del secundario y mide cada rol sobre todas las superficies donde puede aparecer.
• Reserva los acentos para acciones y énfasis, evitando que la decoración compita con los controles interactivos.
• Nombra los tokens por su función, como text-muted o border-subtle, para cambiar valores sin reescribir componentes.

Construye deliberadamente la escala de superficies

Las superficies oscuras necesitan suficiente separación para expresar contención, pero los saltos grandes de luminancia producen franjas y ruido visual. Empieza con el lienzo más oscuro y añade valores algo más claros para tarjetas, menús y diálogos. Un borde puede reforzar el límite cuando los rellenos vecinos son parecidos. Las sombras siguen siendo válidas, aunque se perciben menos sobre un fondo oscuro y no deberían ser la única señal. Prueba composiciones anidadas reales: un diálogo sobre la página, un menú sobre una tarjeta y un campo dentro de un panel. La comparación relevante siempre ocurre entre colores renderizados adyacentes.

Crea tokens explícitos y declara el esquema

Los tokens centralizados permiten inspeccionar el modo oscuro. En este ejemplo explícitamente oscuro, color-scheme: dark indica a los agentes de usuario compatibles que representen controles de formulario y otras piezas nativas con un esquema oscuro, mientras las propiedades personalizadas guardan las decisiones de la aplicación. Se declara únicamente el esquema oscuro porque los tokens mostrados no incluyen reemplazos para un tema claro. La declaración no demuestra accesibilidad ni sustituye las pruebas de componentes. Los valores son un punto de partida, no una paleta universal: tipografía, peso, suavizado, colores vecinos y estados reales afectan al resultado. El bloque de código es idéntico en todas las traducciones.

:root {
  color-scheme: dark;
  --surface-0: #101318;
  --surface-1: #181C22;
  --text-primary: #F2F4F7;
  --text-muted: #B8C0CC;
  --border: #46505E;
  --accent: #8AB4F8;
  --focus: #FFD166;
}

Mide por separado texto, controles y foco

Los requisitos WCAG describen contenidos y estados concretos, no una puntuación única para toda la paleta. El texto ordinario suele necesitar una relación de contraste mínima de 4,5:1 según el criterio 1.4.3, mientras que el texto grande que cumple sus condiciones tiene un umbral de 3:1. Los objetos gráficos esenciales y la información visual necesaria para identificar controles se tratan en contraste no textual. La apariencia del foco dispone de requisitos propios en WCAG 2.2. Mide el primer plano contra el color que queda inmediatamente detrás en estados hover, pulsado, seleccionado, desactivado, de validación y de superposición.

• Mide el texto principal y atenuado sobre cada superficie permitida, no solamente sobre el lienzo general.
• Comprueba iconos y límites cuando sean necesarios para identificar el control o comprender su estado actual.
• Evalúa el indicador de foco frente a los colores que toca, incluidos el componente y la superficie circundante.
• Después de aplicar opacidad o mezcla, calcula el contraste del color compuesto final que ve la persona.
• Prueba por separado los estados seleccionado, hover, activo, error y desactivado además del estado predeterminado.

Controla los acentos sin borrar su función

Un acento saturado que funcionaba sobre blanco puede vibrar visualmente sobre una superficie casi negra o fallar cuando se usa como texto. Considera relleno, texto, icono y borde como parejas diferentes. Un enlace sobre fondo oscuro puede necesitar un acento más claro, mientras que el texto de un botón con relleno de acento quizá requiera un primer plano oscuro. El significado de los estados también debe comunicarse mediante texto, iconos, posición o patrones cuando el color no puede ser la única pista. Mantén los efectos decorativos detrás del contenido y examina los píxeles reales. En gradientes, prueba el punto menos favorable y no solo los extremos.

Revisa el tema como un sistema completo

Termina con una matriz de componentes y no con la revisión de una captura. Renderiza títulos, texto, enlaces, botones, campos, tablas, avisos, gráficos, menús y diálogos sobre cada superficie compatible. Recorre la interfaz con teclado e inspecciona el foco con zoom normal y aumentado. Prueba forced colors o los ajustes de alto contraste cuando estén disponibles y confirma que la semántica nativa sigue comunicando el estado. Los controles automáticos ayudan con parejas estables, pero las capas, los gradientes, el antialiasing y los estados dinámicos requieren inspección humana. Registra las combinaciones probadas junto a los tokens para repetir el mismo análisis tras cambios futuros.

• Inventaría cada token semántico y documenta las superficies o componentes en los que puede utilizarse.
• Genera una matriz de estados predeterminado, hover, foco, activo, seleccionado, desactivado y validación.
• Ejecuta cálculos deterministas para parejas de colores sólidos y conserva los resultados con la revisión de diseño.
• Realiza pruebas de teclado, zoom y dispositivos reales antes de publicar y repítelas cuando cambien tokens compartidos.