Tu refresco de marca se lanza a las 9am. Marketing actualiza tres códigos hex en Figma. Al mediodía, tus botones se vuelven invisibles en modo oscuro, tus ratios de contraste fallan WCAG 2.2, y tus propiedades CSS personalizadas se convierten en un enredo de 47 variables que nadie se atreve a tocar. He reconstruido este fallo al menos una docena de veces — juntando matemáticas HSL, ajustes de luminosidad hardcodeados, rezando para que el próximo plugin de design token me salvara. Cada sistema se resquebrajaba en el momento en que llegaba el modo oscuro, o una auditoría de accesibilidad, o un cliente pedía 'solo un color de marca más'. La solución no es otro React hook o mixin Sass. Es una arquitectura de color que sobrevive el contacto con tu proceso de diseño real — una que trata la uniformidad perceptual, el nombrado semántico, y el cambio de modo como restricciones desde el commit uno, no parches post-lanzamiento.

2026 es diferente aunque. No porque el problema se hizo más fácil, sino porque las herramientas finalmente alcanzaron la complejidad. Entre espacios de color OKLCH aterrizando en cada navegador mayor, la arquitectura de color dinámico de Material Design 3 madurando, y las especificaciones de design tokens alcanzando estatus de recomendación candidata W3C, en realidad tenemos un stack coherente ahora. Este artículo te guía a través de cómo construir un sistema de color que maneje modo claro, modo oscuro, contraste alto, cumplimiento de accesibilidad, y theming — sin hacerte querer voltear una mesa.

Tabla de Contenidos

Por qué la mayoría de sistemas de color se desmoronan

La mayoría de sistemas de color fallan porque comienzan en el lugar equivocado. Los diseñadores eligen un color de marca primaria, generan una paleta en Figma, y entregan valores hex a los desarrolladores. Esos valores hex se esparcen por los archivos de componentes. Luego alguien pide modo oscuro y todo se desmorona.

El problema no son los colores en sí — es la arquitectura. O más bien, la falta de una. Una paleta de color no es un sistema de color. Una paleta te da un montón de muestras. Un sistema te da reglas para cómo esas muestras se aplican en contextos, temas, y requisitos de accesibilidad.

Aquí está lo que un sistema de color de producción realmente necesita:

  • Tokens primitivos — los valores de color sin procesar (tu paleta)
  • Tokens semánticos — qué colores significan (fondo, superficie, texto, error, etc.)
  • Tokens de componente — cómo se aplican colores a elementos UI específicos
  • Variantes de tema — cómo todo lo anterior cambia entre modos claro/oscuro/alto contraste
  • Garantías de accesibilidad — ratios de contraste incorporados en las relaciones de tokens, no verificados después del hecho

Si alguna de estas capas falta, eventualmente te golpearás contra un muro. Confía en mí en esto.

Fundamentos de teoría del color para la web

Antes de sumergirnos en la implementación, vamos a fundamentarnos en la teoría del color que realmente importa para el trabajo de UI. No voy a desmenuzar toda la rueda de color — puedes encontrar eso en cualquier lado. En su lugar, enfoquémonos en lo que confunde a la gente.

Uniformidad perceptual

Aquí hay algo que me molestó durante años antes de entenderlo: ¿por qué una paleta generada con valores de tonalidad HSL espaciados uniformemente se ve... desigual? La respuesta es uniformidad perceptual. HSL trata el espacio de color como matemáticamente uniforme, pero nuestros ojos no lo perciben así. Un cambio de luminosidad del 10% de 50% a 40% en azul se ve salvajemente diferente del mismo cambio en amarillo.

Esto es por qué OKLCH importa tanto. En OKLCH, un cambio de 10 unidades en luminosidad se ve como la misma cantidad de cambio sin importar la tonalidad. Esta es la base para generar paletas consistentes programáticamente.

La regla 60-30-10 aún se mantiene

Aun en 2026, el principio clásico del diseño interior se traduce perfectamente a UI:

  • 60% — Colores de superficie/fondo dominantes
  • 30% — Colores secundarios (tarjetas, barras laterales, secciones)
  • 10% — Colores acentuados (botones, enlaces, destacados)

Tu sistema de color debería hacer que este ratio sea fácil de lograr por defecto.

Cálido vs frío y peso percibido

Los colores cálidos (rojos, naranjas, amarillos) se sienten más pesados y más cercanos. Los colores fríos (azules, verdes, púrpuras) se retroceden. Esto afecta cómo los usuarios perciben la jerarquía de información. Tu color de acción primaria debe ser típicamente más cálido que tu fondo para crear peso visual natural.

Aprendiendo de la arquitectura de color de Material Design 3

Material Design 3 (M3) introdujo lo que ellos llaman "color dinámico" — y independientemente de si usas Material Design en sí, la arquitectura vale la pena estudiar. El equipo de Google esencialmente resolvió el problema del sistema de color a escala, y podemos robar sus mejores ideas.

El concepto de paleta tonal

M3 genera paletas tonales — 13 tonos del 0 (negro) al 100 (blanco) para cada color clave. Cada tono tiene un rol específico:

Tono Uso típico Modo claro Modo oscuro
0 Negro — —
10 Superficies oscuras — Variante de superficie
20 Elementos más oscuros — Superficie
30 Acento oscuro Contenedor en primario —
40 Primario Primario —
50 Rango medio — —
60 Acento más claro — —
70 Elementos claros — Contenedor primario
80 Acento claro Contenedor primario Primario
90 Superficies más claras Variante contenedor primario —
95 Muy claro Variante de superficie —
99 Casi blanco Superficie —
100 Blanco Fondo —

El genio de este enfoque: modo claro y modo oscuro usan la misma paleta tonal, solo mapeada diferente. El tono 40 podría ser tu color primario en modo claro, mientras que el tono 80 es tu primario en modo oscuro. Misma tonalidad, misma paleta, aplicación completamente diferente.

Roles de color clave

M3 define cinco roles de color clave que he encontrado funcionan bien incluso fuera de Material Design:

  1. Primario — Tu color de acción/marca principal
  2. Secundario — Color de soporte para elementos menos prominentes
  3. Terciario — Un acento adicional para interés visual
  4. Error — Color semántico para errores y acciones destructivas
  5. Neutro — La columna vertebral para superficies, fondos, y texto

Cada rol obtiene su propia paleta tonal. Eso es cinco paletas × 13 tonos = 65 colores base. Suena como mucho, pero solo expones una fracción de estos como tokens semánticos.

Eligiendo el espacio de color correcto: OKLCH vs HSL vs HEX

Esta decisión tiene consecuencias reales. Aquí está la comparación honesta:

Característica HEX/RGB HSL OKLCH
Soporte en navegador (2026) 100% 100% ~96%
Uniformidad perceptual No No Sí
Intuitivo de leer No Algo Sí
Generación de paleta fácil No Sí Sí
Mapeo de gama sRGB solo sRGB solo P3 + sRGB
Compatibilidad CSS color-mix() Sí Sí Sí
Soporte de herramientas de diseño Universal Universal Creciente

Mi recomendación para 2026: escribe en OKLCH, distribuye como OKLCH y fallback hex. Aquí está el por qué.

OKLCH te da tres ejes intuitivos:

  • L (Luminosidad): 0% a 100%
  • C (Croma): 0 a ~0.4 (intensidad de saturación)
  • H (Tonalidad): 0 a 360 grados
/* OKLCH es genuinamente agradable de trabajar */
:root {
  --color-primary: oklch(55% 0.2 250);     /* Un azul vívido */
  --color-primary-light: oklch(75% 0.15 250); /* Misma tonalidad, más claro, croma ligeramente menor */
  --color-primary-dark: oklch(35% 0.18 250);  /* Variante más oscura */
}

Observa cómo puedes ajustar la luminosidad y croma independientemente mientras mantienes la tonalidad constante. Intenta hacer eso en hex. Esperaré.

Para el ~4% de navegadores que no soportan OKLCH en 2026, usa @supports con fallbacks hex. Los números siguen disminuyendo aunque.

Design Tokens: La fuente de verdad

Los design tokens son representaciones nombradas, agnósticas de plataforma de decisiones de diseño. Son el contrato entre tu herramienta de diseño y tu codebase. En 2026, la especificación W3C Design Tokens Community Group se ha estabilizado lo suficientemente para construir con confianza.

Arquitectura de tokens: tres capas

Estructuro los tokens de color en tres capas. Esto no es arbitrario — es la arquitectura viable mínima que maneja theming sin volverse inmanejable.

Capa 1: Tokens primitivos (la paleta)

{
  "color": {
    "blue": {
      "10": { "$value": "oklch(15% 0.05 250)", "$type": "color" },
      "20": { "$value": "oklch(25% 0.08 250)", "$type": "color" },
      "30": { "$value": "oklch(35% 0.12 250)", "$type": "color" },
      "40": { "$value": "oklch(45% 0.18 250)", "$type": "color" },
      "50": { "$value": "oklch(55% 0.20 250)", "$type": "color" },
      "60": { "$value": "oklch(65% 0.18 250)", "$type": "color" },
      "70": { "$value": "oklch(75% 0.15 250)", "$type": "color" },
      "80": { "$value": "oklch(85% 0.10 250)", "$type": "color" },
      "90": { "$value": "oklch(92% 0.06 250)", "$type": "color" },
      "95": { "$value": "oklch(96% 0.03 250)", "$type": "color" },
      "99": { "$value": "oklch(99% 0.01 250)", "$type": "color" }
    }
  }
}

Capa 2: Tokens semánticos (el significado)

{
  "color": {
    "primary": { "$value": "{color.blue.50}", "$type": "color" },
    "on-primary": { "$value": "{color.blue.99}", "$type": "color" },
    "primary-container": { "$value": "{color.blue.90}", "$type": "color" },
    "on-primary-container": { "$value": "{color.blue.10}", "$type": "color" },
    "surface": { "$value": "{color.neutral.99}", "$type": "color" },
    "on-surface": { "$value": "{color.neutral.10}", "$type": "color" },
    "error": { "$value": "{color.red.50}", "$type": "color" },
    "on-error": { "$value": "{color.red.99}", "$type": "color" }
  }
}

Capa 3: Tokens de componente (la aplicación)

{
  "button": {
    "primary": {
      "background": { "$value": "{color.primary}", "$type": "color" },
      "text": { "$value": "{color.on-primary}", "$type": "color" },
      "hover-background": { "$value": "{color.primary-container}", "$type": "color" }
    }
  }
}

Herramientas que funcionan en 2026

Para la gestión de tokens y transformación, estas herramientas están battle-tested:

  • Style Dictionary 4.x — El estándar para transformar tokens a cualquier formato de plataforma
  • Tokens Studio for Figma — Sincroniza tokens entre Figma y tu codebase
  • Cobalt UI — Un compilador de tokens compatible con especificación W3C más nuevo que está ganando tracción

He tenido buenos resultados usando Tokens Studio para gestionar tokens en Figma, exportándolos como JSON de formato W3C, y usando Style Dictionary para compilarlos en propiedades CSS personalizadas, configuración Tailwind, y valores Swift/Kotlin. En Social Animal, hemos integrado este pipeline en nuestro proceso de compilación para múltiples proyectos de clientes.

Implementando con propiedades personalizadas CSS

Aquí es donde la teoría se encuentra con la realidad. Las propiedades personalizadas CSS (variables CSS) son la capa de tiempo de ejecución de tu sistema de color. Son lo que hace que theming, modo oscuro, y actualizaciones dinámicas sean posibles sin enviar JavaScript adicional.

La configuración base

/* Capa primitiva — raramente referenciada directamente en componentes */
:root {
  --palette-blue-50: oklch(55% 0.20 250);
  --palette-blue-80: oklch(85% 0.10 250);
  --palette-blue-90: oklch(92% 0.06 250);
  --palette-blue-10: oklch(15% 0.05 250);
  --palette-neutral-10: oklch(15% 0.01 250);
  --palette-neutral-90: oklch(92% 0.01 250);
  --palette-neutral-95: oklch(96% 0.005 250);
  --palette-neutral-99: oklch(99% 0.002 250);
  --palette-red-50: oklch(55% 0.22 25);
  --palette-red-80: oklch(85% 0.10 25);
  --palette-red-90: oklch(92% 0.06 25);
}

/* Capa semántica — esto es lo que los componentes referencian */
:root,
[data-theme="light"] {
  --color-primary: var(--palette-blue-50);
  --color-on-primary: var(--palette-blue-99, #ffffff);
  --color-primary-container: var(--palette-blue-90);
  --color-on-primary-container: var(--palette-blue-10);
  --color-surface: var(--palette-neutral-99);
  --color-on-surface: var(--palette-neutral-10);
  --color-surface-variant: var(--palette-neutral-95);
  --color-error: var(--palette-red-50);
  --color-on-error: white;
}

Usando `color-mix()` para variaciones dinámicas

Una de las mejores adiciones recientes de CSS para sistemas de color es color-mix(). En lugar de definir tokens separados para cada estado hover y variante de opacidad, puedes derivarlos:

.button-primary {
  background: var(--color-primary);
  color: var(--color-on-primary);
}

.button-primary:hover {
  /* Mezcla primario con blanco para un estado hover más claro */
  background: color-mix(in oklch, var(--color-primary) 85%, white);
}

.button-primary:active {
  /* Mezcla con negro para estado presionado */
  background: color-mix(in oklch, var(--color-primary) 90%, black);
}

/* Overlays de superficie semi-transparentes */
.overlay {
  background: color-mix(in oklch, var(--color-on-surface) 8%, transparent);
}

Esto es masivamente útil. En lugar de 15 variantes de opacidad de cada color, los computes en tiempo de ejecución. Menos tokens, más flexibilidad.

Construyendo modo oscuro que realmente funciona

El modo oscuro no es solo "intercambia blanco por negro". He visto ese enfoque producir resultados que cansan los ojos y fallan accesibilidad demasiadas veces. Aquí está cómo hacerlo correctamente.

La estrategia de remapeo

Recuerda la paleta tonal de la sección de Material Design? El modo oscuro remapea tokens semánticos a diferentes tonos en la misma paleta:

[data-theme="dark"] {
  --color-primary: var(--palette-blue-80);  /* Era 50, ahora 80 (más claro) */
  --color-on-primary: var(--palette-blue-20);  /* Era 99, ahora 20 (más oscuro) */
  --color-primary-container: var(--palette-blue-30);  /* Era 90, ahora 30 */
  --color-on-primary-container: var(--palette-blue-90);  /* Era 10, ahora 90 */
  --color-surface: var(--palette-neutral-10);  /* Era 99, ahora 10 */
  --color-on-surface: var(--palette-neutral-90);  /* Era 10, ahora 90 */
  --color-surface-variant: var(--palette-neutral-20);
  --color-error: var(--palette-red-80);
  --color-on-error: var(--palette-red-20);
}

¿Ves lo que está sucediendo? Las relaciones se voltean. Los colores primarios se vuelven más claros en modo oscuro (para que sean visibles contra superficies oscuras). Los colores de fondo se voltean al final oscuro de la paleta neutral. Cada par de primer plano/fondo mantiene su relación de contraste.

Respetando preferencias del sistema

@media (prefers-color-scheme: dark) {
  :root:not([data-theme="light"]) {
    /* Mismos valores de modo oscuro que arriba */
    --color-primary: var(--palette-blue-80);
    --color-surface: var(--palette-neutral-10);
    /* ... */
  }
}

El selector :not([data-theme="light"]) es el truco clave. Respeta la preferencia del sistema a menos que el usuario haya elegido explícitamente modo claro a través de un toggle. Aquí está la lógica del toggle:

function setTheme(theme) {
  if (theme === 'system') {
    document.documentElement.removeAttribute('data-theme');
    localStorage.removeItem('theme');
  } else {
    document.documentElement.setAttribute('data-theme', theme);
    localStorage.setItem('theme', theme);
  }
}

// En carga de página, aplica preferencia guardada
const saved = localStorage.getItem('theme');
if (saved) document.documentElement.setAttribute('data-theme', saved);

Para frameworks como Next.js (que usamos mucho en nuestra práctica de desarrollo Next.js), querrás inyectar este script en el <head> para prevenir flash de tema incorrecto. Astro lo maneja bien también con su directiva is:inline script — algo que aprovechamos en nuestro trabajo de desarrollo Astro.

Elevación de superficie en modo oscuro

Una cosa que Material Design acierta: en modo oscuro, las superficies elevadas deben ser ligeramente más claras, no más oscuras. Esto imita cómo funcionan las sombras — en una habitación oscura, una superficie más cercana recibe más luz ambiente.

[data-theme="dark"] {
  --color-surface-dim: oklch(12% 0.01 250);
  --color-surface: oklch(15% 0.01 250);
  --color-surface-bright: oklch(20% 0.01 250);
  --color-surface-container-low: oklch(17% 0.01 250);
  --color-surface-container: oklch(19% 0.01 250);
  --color-surface-container-high: oklch(22% 0.01 250);
}

Estos incrementos de luminosidad diminutos (2-3% en OKLCH) crean una jerarquía de elevación efectiva pero sutil.

Accesibilidad y cumplimiento de contraste WCAG

Esta es la parte donde muchos sistemas de color parchan retroactivamente problemas en lugar de prevenirlos. Vamos a prevenirlos.

Requisitos de contraste WCAG 2.2 y 3.0

WCAG 2.2 (el estándar actual) usa la fórmula de ratio de contraste:

Nivel Texto normal (< 24px) Texto grande (≥ 24px / 18.66px negrita) Componentes UI
AA 4.5:1 3:1 3:1
AAA 7:1 4.5:1 N/A

WCAG 3.0 (aún en borrador, pero relevante para prepararse para el futuro) usa APCA (Advanced Perceptual Contrast Algorithm), que es más precisamente perceptual. APCA mide contraste diferente — tiene en cuenta polaridad (texto claro en oscuro vs texto oscuro en claro) y tamaño de texto más granularmente.

Para 2026, recomendaría apuntar a WCAG 2.2 AA como tu mínimo, con APCA como una verificación suplementaria.

Incorporando contraste en tus pares de tokens

El enfoque más efectivo: cada token semántico de primer plano debe ser definido en relación con su token de fondo, con contraste garantizado.

Aquí está cómo valido esto en el paso de compilación:

// contrast-check.mjs — ejecuta esto en tu pipeline CI/CD
import { wcagContrast } from 'culori';

const pairs = [
  { fg: 'on-primary', bg: 'primary', minRatio: 4.5 },
  { fg: 'on-primary-container', bg: 'primary-container', minRatio: 4.5 },
  { fg: 'on-surface', bg: 'surface', minRatio: 4.5 },
  { fg: 'on-surface', bg: 'surface-variant', minRatio: 3.0 },
  { fg: 'on-error', bg: 'error', minRatio: 4.5 },
];

function validateContrast(tokens, theme) {
  const failures = [];
  for (const pair of pairs) {
    const ratio = wcagContrast(tokens[pair.fg], tokens[pair.bg]);
    if (ratio < pair.minRatio) {
      failures.push(
        `[${theme}] ${pair.fg}/${pair.bg}: ${ratio.toFixed(2)} (necesita ${pair.minRatio})`
      );
    }
  }
  return failures;
}

Ejecuta esto contra ambos tokens de tema claro y oscuro. Si algún par falla, la compilación falla. Sin excepciones. He visto equipos saltar esta verificación "solo por ahora" y terminar enviando interfaces inaccesibles durante meses.

La consulta de medios `forced-colors`

No olvides el modo Windows High Contrast. Anula completamente tus colores, y necesitas asegurarte de que tu UI sea usable:

@media (forced-colors: active) {
  .button {
    border: 2px solid ButtonText;
  }
  
  .icon {
    forced-color-adjust: auto; /* Deja que el sistema lo maneje */
  }
}

Uniendo todo: un sistema completo

Aquí está el flujo de trabajo práctico en el que me he asentado después de iterar a través de muchos proyectos:

  1. Comienza con 1-3 colores de marca. Define tu primario, secundario, y opcionalmente terciario tonalidades.

  2. Genera paletas tonales en OKLCH. Usa una herramienta como Huetone o construye un script simple que genere 11 pasos de luminosidad por tonalidad.

  3. Define mapeamentos de tokens semánticos. Mapea tonos a roles semánticos para ambos temas claro y oscuro. Usa la tabla de mapeo de tonos de M3 como punto de partida.

  4. Valida todos los pares de contraste. Cada token on-* debe cumplir WCAG 2.2 AA contra su superficie correspondiente.

  5. Exporta como JSON de design tokens W3C. Esta es tu única fuente de verdad.

  6. Compila a propiedades CSS personalizadas usando Style Dictionary o Cobalt UI.

  7. Implementa cambio de tema con atributos data-theme y prefers-color-scheme.

  8. Añade validación de contraste a CI. Nunca envíes un cambio de color sin verificaciones de contraste automatizadas.

Si estás construyendo un sitio potenciado por headless CMS y necesitas ayuda implementando un sistema de color de producción, ese es exactamente el tipo de trabajo que hacemos en Social Animal. Revisa nuestro pricing o ponte en contacto para discutir tu proyecto.

Integración de muestra Tailwind v4

Si estás usando Tailwind CSS v4 (que usa configuración basada en CSS), aquí está cómo los design tokens se traducen:

/* tokens.css — importado por tu configuración Tailwind */
@theme {
  --color-primary: var(--color-primary);
  --color-on-primary: var(--color-on-primary);
  --color-surface: var(--color-surface);
  --color-on-surface: var(--color-on-surface);
  --color-error: var(--color-error);
}

Luego en tu markup:

<button class="bg-primary text-on-primary hover:bg-primary/85">
  Comienza
</button>

Limpio, semántico, y automáticamente consciente de tema.

Preguntas frecuentes

¿Cuántos colores debería tener un sistema de color de diseño web? Un sistema bien estructurado típicamente tiene 3-5 roles de color clave (primario, secundario, terciario, error, neutral), cada uno con 11-13 variaciones tonales. Eso son aproximadamente 40-65 tokens primitivos. Pero solo expondrás 15-25 tokens semánticos que los componentes realmente referencian. Más no es mejor — la claridad lo es.

¿Cuál es la diferencia entre design tokens y variables CSS? Los design tokens son decisiones de diseño agnósticas de plataforma almacenadas como datos (usualmente JSON). Las propiedades CSS personalizadas son un formato de salida para esos tokens. El mismo archivo de token podría también generar constantes de color Swift, valores Kotlin, o estilos Figma. Los tokens son la fuente de verdad; las variables CSS son una expresión de esa verdad.

¿Es OKLCH listo para producción en 2026? Sí. El soporte en navegador es alrededor del 96% globalmente a principios de 2026, cubriendo todos los navegadores evergreen. Para el restante ~4% (principalmente navegadores incrustados más antiguos), proporciona fallbacks hex usando @supports o un plugin PostCSS como postcss-oklab-function. El riesgo es mínimo.

¿Cómo aseguro que mi sistema de color cumple estándares de accesibilidad WCAG? Incorpora verificación de contraste en tu pipeline de design tokens. Cada par de primer plano/fondo debe validarse contra mínimos WCAG 2.2 AA (4.5:1 para texto normal, 3:1 para texto grande y componentes UI). Herramientas como la biblioteca JavaScript culori, Stark para Figma, o la extensión de navegador axe pueden ayudar. La clave es automatizar estas verificaciones para que se ejecuten en cada cambio.

¿Debería usar directamente el sistema de color de Material Design 3? No tienes que adoptar Material Design como tu sistema de diseño para beneficiarte de su arquitectura de color. El concepto de paleta tonal, la estructura de tokens semánticos, y la estrategia de remapeo luz/oscuro son excelentes independientemente de tu estilo visual. Toma lo que necesitas de la arquitectura; aplica tus propias estéticas de marca.

¿Cómo manejo modo oscuro con propiedades CSS personalizadas? Usa un atributo data-theme en el elemento root combinado con consultas de medios prefers-color-scheme. Las propiedades CSS personalizadas semánticas se remapean a diferentes valores primitivos para cada tema. Los componentes nunca cambian — solo los valores de tokens cambian. Este es el enfoque más limpio y evita duplicar estilos de componentes.

¿Qué herramientas debería usar para gestionar design tokens en 2026? Tokens Studio for Figma maneja el lado del diseño. Style Dictionary 4.x o Cobalt UI manejan el paso de compilación/transformación. Almacena tu JSON de tokens en control de versiones junto con tu código. Para equipos más grandes, considera una plataforma de gestión de design tokens dedicada como Specify o Supernova, pero el stack de código abierto funciona muy bien para la mayoría de equipos.

¿Cuál es la diferencia entre métodos de contraste WCAG 2.2 y APCA? WCAG 2.2 usa un simple ratio de contraste de luminancia (p. ej., 4.5:1). APCA, propuesto para WCAG 3.0, es más precisamente perceptual — considera que texto claro en fondos oscuros necesita diferente contraste que texto oscuro en fondos claros, y escala requisitos por tamaño y peso de fuente. En 2026, apunta a WCAG 2.2 AA para cumplimiento y usa APCA como una verificación de calidad adicional.