Comience con una elección del usuario y un sistema de tokens
Use la preferencia del sistema como valor por defecto con prefers-color-scheme. Si ofrece un interruptor, emplee un control operable por teclado con un nombre accesible y exponga la elección activa programáticamente. Dé prioridad a la selección manual en ese contexto del navegador; no prometa que siga a alguien a otro dispositivo o a una sesión privada.
Nombre los colores por rol, no por apariencia: canvas, surface, text, muted text, border, link, accent, error, success, focus y disabled. Mapee cada rol en ambos temas. Esto evita que un gris pensado solo para claro se filtre en modo oscuro y hace que las correcciones sean reutilizables. Oscuro no es inherentemente más accesible ni universalmente preferido; es otra experiencia que hay que hacer usable.
Documente un orden, por ejemplo elección guardada primero y preferencia del sistema segundo, para que los equipos prueben el mismo resultado.
Incluya hover, focus, selected, invalid, disabled, loading, empty y visited-link, no solo los valores por defecto.
Mida el contraste en el tema renderizado
WCAG 2.2 Success Criterion 1.4.3 establece un mínimo de 4.5:1 para texto normal y imágenes de texto, y 3:1 para texto grande. No redondee: 4.499:1 no cumple 4.5:1. Las tipografías finas pueden parecer más débiles que su color calculado, así que use una familia más robusta o margen extra.
Compruebe cada primer plano renderizado y el fondo adyacente. Texto sobre fotos, degradados, paneles translúcidos o vídeo tiene fondos cambiantes, por lo que un único cálculo de token no puede probar su legibilidad. Use un respaldo opaco, una superposición adecuada o un emplazamiento distinto, y luego inspeccione en puntos de vista realistas.
Bajo WCAG 2.1 Success Criterion 1.4.11, la información visual necesaria para identificar un control activo, un estado obligatorio o un gráfico significativo necesita 3:1 frente a colores adyacentes.
Acompañe los cambios de color con texto, un ícono, patrón, posición u otra señal clara; los estados de error y seleccionado no deben depender de un tinte sutil.
Proteja el foco por teclado, formularios y cambios de estado
Recorra con Tab ambos temas. El foco debe ser visible en enlaces, botones, inputs, menús, diálogos, widgets personalizados y el control de tema. No elimine el outline del navegador a menos que su reemplazo esté probado en cada superficie y estado. Un outline desplazado suele ser más claro que un resplandor que se mezcla.
La Focus Appearance de WCAG 2.2 es un criterio AAA, no prueba de cumplimiento AA. Es un objetivo útil: un área indicadora al menos tan grande como un perímetro de 2 píxeles CSS y contraste 3:1 entre píxeles enfocados y no enfocados. Verifique también que estados de error, obligatorio, seleccionado e indisponible conserven su significado.
Pruebe por separado el texto de ayuda del input, el valor introducido, la etiqueta, el texto de ayuda, el texto de error, el borde inválido, la marca del checkbox, la selección del radio y el estado de envío.
Para checkout u otro flujo regulado, use el sandbox del proveedor y obtenga revisión cualificada de accesibilidad y seguridad cuando proceda. Esto es orientación educativa, no una evaluación de cumplimiento o seguridad.
Gestione imágenes, activos embebidos y la IU provista por el navegador
Revise logos, ilustraciones, capturas de pantalla, gráficos, íconos y texto incrustado en imágenes en ambos temas. Un logo claro reutilizado puede desaparecer y la leyenda de un gráfico puede fallar aun cuando el HTML circundante pase. Suministre un activo adecuado al propósito o un fondo estable. La imaginería que transmite instrucciones, estado o datos debe seguir siendo comprensible.
Declare soporte para esquemas light y dark, y luego estilice el contenido de la página para el tema seleccionado. La propiedad color-scheme alinea el canvas del navegador, las barras de desplazamiento, controles de formulario y otra IU del navegador. Coloque los metadatos correspondientes al principio del documento. SVG embebido puede responder al esquema padre; pruebe iframe y widgets de terceros de extremo a extremo.
Prefiera controles HTML semánticos. El comportamiento de forced-colors usa semánticas nativas, no un rol ARIA añadido a un elemento genérico.
Inspeccione estados de descarga, caché, carga lenta e imagen fallida, especialmente donde texto o señales de acción descansan sobre medios.
Respete forced-colors y pruebe el lanzamiento como un sistema
Forced-colors aplica una paleta limitada elegida por el usuario, como Windows High Contrast. Los navegadores pueden reemplazar colores, eliminar sombras y añadir backplates al texto. No bloquee la anulación. Haga correcciones específicas donde un componente pierde límites o significado, como un borde real donde una sombra aportaba la affordance. La emulación no puede representar todos los dispositivos, navegadores, extensiones, niveles de zoom o combinaciones de tecnología asistiva.
Ejecute la matriz de rutas e interacciones en configuraciones light, dark y forced-colors antes del lanzamiento. Chrome DevTools puede emular ambas condiciones; úselo para acelerar la revisión y luego navegue manualmente por los flujos prioritarios. Los escáneres encuentran candidatos pero no pueden determinar la accesibilidad por sí solos. SIU preflightea recursos y interacciones críticas del tema, registra una puerta de lanzamiento y mantiene una ruta de reversión probada para regresiones severas de presentación; no es monitoreo de tiempo de actividad.
Incluya landing, navegación, búsqueda, acceso a cuenta, formularios, páginas de error, pantallas autenticadas y flujos de conversión de material.
Guarde URLs probadas, versiones de navegador, configuraciones, excepciones, responsable y trigger de reversión para que la remediación arranque desde hechos.