Preferencias de media queries y control del usuario
Adapta la interfaz a las preferencias de movimiento, contraste, colores forzados y esquema de color, con valores accesibles y controles claros.
Quieres la documentación estructurada de Plataforma?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Las características de medios de CSS permiten que una página se adapte a las preferencias o los estados predeterminados de accesibilidad y apariencia que expone un sistema operativo, navegador u otro agente de usuario. Consultas como prefers-reduced-motion, prefers-contrast, forced-colors y prefers-color-scheme ayudan a que un sitio empiece con una presentación acorde con esos estados. Deben tratarse como datos de entrada para un diseño usable, no como sustitutos de valores predeterminados legibles, controles semánticos ni una forma explícita de elegir la apariencia.
La regla práctica es sencilla: respeta la preferencia, conserva la tarea y facilita encontrar y revertir cualquier modificación propia del sitio. Una persona sensible al movimiento debe poder entender un cambio de estado; quien usa la paleta del sistema debe poder distinguir los controles; y quien prefiere una interfaz oscura no debería tener que aceptar un tema oscuro para todo el sitio con poco contraste. La guía sobre interacciones con punteros explica otra forma de adaptar las interfaces a las personas, mientras que la validación de interacciones del navegador y el diseño de privacidad para flujos de trabajo en el navegador describen principios más amplios de pruebas y elección.
Las preferencias orientan el diseño, pero no resuelven toda la accesibilidad
Las consultas de medios son reglas condicionales de CSS. Una consulta comprueba una característica de medios, como el esquema de color preferido por el usuario o si el navegador aplica una paleta de colores forzados, y permite que una hoja de estilos elija las declaraciones correspondientes. Este es el mismo mecanismo general que permite adaptar la disposición al ancho de la ventana gráfica, pero la condición representa una preferencia de presentación y no una dimensión física de la pantalla. El navegador evalúa la consulta y aplica las reglas coincidentes cuando cambia el entorno pertinente.
Estas características exponen un conjunto limitado de valores definidos por la plataforma web. No explican por qué una persona eligió una opción, qué tecnología de asistencia usa ni qué presentación le funcionará mejor en todos los contextos. Una aplicación no debería intentar inferir esos datos privados. Puede responder a la preferencia que expone el navegador y ofrecer una interfaz coherente sin etiquetar a la persona ni atribuirle una capacidad. Una preferencia es una señal de diseño útil, no un perfil de usuario.
La distinción importa porque una media query no puede corregir todos los problemas de accesibilidad. Una regla de movimiento reducido no puede añadir la etiqueta que le falta a un control. Un esquema de color oscuro no garantiza por sí solo que el texto sea legible. Adaptarse a los colores forzados no sustituye una semántica HTML significativa. Toda presentación necesita contraste suficiente, foco visible, estados comprensibles y controles que puedan manejarse con los métodos de interacción que admite el producto.
Usa las consultas de medios como una adaptación progresiva. Empieza con una experiencia predeterminada completa y cambia solo las partes que deban responder a la preferencia. Conserva el contenido, la jerarquía y la posibilidad de completar la tarea en todos los temas. Por ejemplo, si una animación comunica el progreso, reducir el movimiento no debería hacerlo desaparecer; un indicador estático o un mensaje de estado breve puede transmitir la misma información. Si un color identifica un error, el mensaje y los iconos también deben ayudar a entenderlo.
Para los cambios visuales, prefiere CSS, porque el navegador puede volver a evaluar los estilos sin esperar al código de la aplicación. JavaScript es apropiado cuando una preferencia debe afectar un comportamiento de la aplicación que CSS no puede controlar, como decidir si se inicia una secuencia animada opcional. Mantén ese comportamiento acotado y permite detenerlo o cambiarlo. No uses JavaScript para reconstruir una preferencia que CSS puede gestionar directamente ni guardes una elección obtenida del navegador como si fuera una decisión deliberada en la configuración del sitio.
El movimiento reducido debe conservar el significado y el control
La característica prefers-reduced-motion puede coincidir cuando el usuario ha solicitado reducir el movimiento no esencial de la interfaz. Una hoja de estilos puede usar @media (prefers-reduced-motion: reduce) para eliminar o acortar transiciones, efectos de paralaje, desplazamiento animado, movimiento de reproducción automática y otros efectos que no sean necesarios para completar la tarea. El valor correspondiente no-preference indica que el agente de usuario no tiene ninguna solicitud de reducción del movimiento que aplicar; no autoriza a animar todas las interacciones ni permite suponer que el movimiento resulte cómodo para todo el mundo.
Empieza por identificar qué movimiento es decorativo y cuál comunica información necesaria. Una tarjeta que rebota solo para llamar la atención normalmente puede quedarse quieta. Una secuencia de carga quizá necesite un indicador de progreso estable o un mensaje de texto en lugar de un bucle animado. Una transición de gráfico puede actualizarse directamente al nuevo valor y mantener visibles las etiquetas y el contexto anterior. Un panel plegable puede abrirse sin una animación deslizante larga, sin dejar de exponer programáticamente su estado expandido. El objetivo no es ocultar el cambio, sino comunicarlo sin movimiento innecesario.
Aplicar la regla de forma global puede ser un punto de partida útil, pero los componentes no deberían depender de una única anulación global de la duración como única adaptación. El movimiento puede provenir de transiciones CSS, fotogramas clave, bibliotecas de animación de JavaScript, contenido multimedia incrustado o contenido que se reproduce automáticamente. Revisa la experiencia completa y aplica reglas por componente cuando haga falta. Una regla que fija en casi cero la duración de todas las animaciones todavía puede dejar actualizaciones de fotogramas que distraen, parpadeos o movimiento causado por scripts. También puede eliminar accidentalmente tiempos que ayudan a percibir una interacción. Prueba el resultado, no solo si coincide un selector.
Hay movimientos que el usuario solicita directamente, como iniciar un vídeo con un botón de reproducción o abrir una animación de gráfico. La preferencia de movimiento reducido no debería desactivar en silencio un control esencial. Considera, en cambio, una presentación estática alternativa, un estado inicial en pausa o una acción explícita de reproducción con un control visible para detener o pausar. El criterio de conformidad 2.2.2 de WCAG 2.2 se aplica al contenido que se mueve, parpadea o se desplaza, comienza automáticamente, dura más de cinco segundos y aparece junto a otro contenido: ofrece una forma de pausarlo, detenerlo u ocultarlo, salvo cuando el movimiento sea esencial.
Si el producto incorpora su propio ajuste de movimiento, presenta opciones comprensibles, como «Reducir el movimiento» o «Permitir animaciones de la interfaz». Explica el efecto práctico junto al ajuste en lugar de mostrar jerga de implementación. No obligues a abrir la configuración del sistema solo para detener un efecto opcional del sitio. A la vez, el ajuste del sitio no debe anular en silencio la solicitud del sistema operativo. Una prioridad prudente es respetar por defecto la reducción del sistema y dejar que una decisión explícita del sitio afecte solo sus efectos opcionales, con una forma sencilla de volver a la configuración del sistema.
Las preferencias de contraste requieren alternativas visuales claras
La característica prefers-contrast permite que los estilos respondan a una indicación del agente de usuario según la cual se prefiere más contraste, menos contraste o un tratamiento de contraste específico. Los valores exactos que admite un navegador dependen de la plataforma y de su implementación; antes de depender de un valor concreto, consulta la compatibilidad actual. La responsabilidad de diseño va más allá de apuntar a una consulta: el texto ordinario y los controles deben seguir siendo perceptibles en las condiciones que admita la página, y la información no debe depender solo de una diferencia sutil de tono.
Para la preferencia more, algunas adaptaciones útiles son aumentar la separación entre texto y fondo, definir bordes más claros en los controles, hacer más visibles los indicadores de foco y diferenciar mejor los estados contiguos. Una pestaña seleccionada no debería identificarse únicamente por un pequeño cambio de tono. Combina el cambio de color con un subrayado, una forma, un grosor u otro indicador visible. Los controles deshabilitados deben seguir siendo comprensibles sin confundirse con el texto que los rodea. Los mensajes de error y éxito deben acompañar el color con una etiqueta o un icono para que su significado siga disponible para personas con distintas formas de percepción del color.
La preferencia less puede ser pertinente para quienes encuentran incómodo un contraste intenso. No significa que el texto esencial deba volverse tenue ni que los controles deban desaparecer en el fondo. Define una paleta alternativa moderada que conserve el texto legible, los límites visibles y el foco. Revisa por separado el texto pequeño, los trazos finos, el texto de marcador de posición y los estados seleccionados y de desplazamiento del puntero. Una paleta equilibrada en un encabezado grande puede fallar en un formulario compacto o en un botón deshabilitado.
El valor custom, cuando se admite, puede indicar una preferencia de contraste elegida por el usuario que no encaja en las categorías más sencillas more o less. No lo trates como una instrucción para inventar un modo universal de «contraste personalizado». Es posible que el navegador no exponga los colores elegidos mediante esta característica de medios. Mantén la página legible con valores predeterminados propios, bien probados, y ofrece temas seleccionables por el usuario cuando la aplicación pueda proporcionar alternativas significativas.
No dependas de una consulta de preferencias para cumplir las necesidades básicas de contraste. Quizá las personas no sepan dónde activar una opción del sistema operativo, quizá el navegador no la exponga o quizá el contenido se vea en un entorno que transforma los colores. Comprueba el texto, los elementos gráficos esenciales, los anillos de foco y los límites de los controles según los criterios de accesibilidad aplicables, tanto en el tema predeterminado como en los modos de preferencia admitidos. Los cambios de contraste no deben borrar la identidad de la marca ni producir una segunda paleta que nadie haya revisado con tamaños de contenido reales.
Los colores forzados requieren colores del sistema y moderación
La característica forced-colors indica si el agente de usuario está imponiendo una paleta de colores limitada. Este modo es distinto de una preferencia de alto contraste: el navegador puede reemplazar los colores especificados por el autor con colores elegidos por el usuario o el sistema, de modo que los primeros planos y los fondos sigan una paleta coordinada. Una consulta como @media (forced-colors: active) permite que una hoja de estilos haga ajustes puntuales cuando la presentación normal depende de distinciones visuales que la paleta forzada modifica.
En este modo, conserva la capacidad del navegador para aplicar la paleta. Las palabras clave de colores del sistema como Canvas, CanvasText, LinkText, ButtonFace y ButtonText expresan relaciones con los colores activos del sistema en lugar de fijar un valor RGB claro u oscuro. Cuando su semántica sea adecuada, prefiere los controles nativos. En los controles personalizados, comprueba que los bordes, los indicadores de foco, la selección y los estados sigan siendo perceptibles después del ajuste de colores del agente de usuario. Un borde intencionalmente transparente en el tema normal quizá deba hacerse visible para que el contorno del control siga siendo claro.
La propiedad forced-color-adjust controla si un elemento queda sujeto a los ajustes de colores forzados. Normalmente conviene mantener el comportamiento predeterminado. Al establecer forced-color-adjust: none, el elemento queda excluido de esos ajustes. Úsalo solo en un elemento concreto cuando la aplicación ajuste por sí misma sus colores para atender las necesidades de color y contraste de la persona, y prueba el resultado en el modo de colores forzados. Excluir una página entera puede frustrar la paleta elegida y crear combinaciones ilegibles. Por lo general, es mejor conservar la estructura y usar colores del sistema en los elementos que deban adaptarse.
No des por hecho que las imágenes decorativas o los fondos seguirán disponibles en el modo de colores forzados. La información que comunica una imagen de fondo CSS puede perderse cuando los fondos se suprimen o recolorean. Para la información esencial, usa texto real, nombres accesibles, bordes o un gráfico en línea apropiado con una alternativa visible. Si el significado de un icono depende de su relleno, verifica que siga visible su trazo o contorno. Prueba el foco del teclado y los estados seleccionados en un entorno real de colores forzados, porque una captura del tema normal no mostrará todos los ajustes.
Los colores forzados no son una señal para crear un tema independiente, fijo en blanco y negro, que compita con la configuración del sistema. La paleta del sistema operativo ya es una decisión visible para el usuario y a menudo incluye colores que no son simplemente blancos o negros. Deja que la plataforma haga su trabajo y añade los mínimos ajustes CSS necesarios para que la jerarquía del contenido y los controles sigan siendo utilizables. Evita anular globalmente los colores del sistema o usar forced-color-adjust: none como solución rápida para conservar la fidelidad visual.
El esquema de color debe admitir una elección explícita en el sitio
La característica prefers-color-scheme puede seleccionar estilos para una preferencia clara u oscura. Permite que una página empiece con una paleta acorde con la decisión del navegador o del sistema operativo, incluso si la persona cambia esa preferencia mientras la página permanece abierta. En algunos entornos, un tema oscuro puede reducir la cantidad de superficies brillantes en pantalla; un tema claro puede adaptarse mejor a otros flujos de trabajo. Ninguno es superior en todos los casos: ambos requieren decisiones de color intencionales y pruebas.
La propiedad CSS color-scheme comunica qué esquemas admite un elemento o un documento. Declarar compatibilidad con los esquemas claro y oscuro puede ayudar al agente de usuario a mostrar controles integrados, campos de formulario y otras superficies que proporciona el navegador con un esquema compatible. La declaración no garantiza que toda la página sea accesible ni sustituye los estilos propios del contenido del sitio. Coordina la propiedad con las paletas realmente disponibles para que los campos nativos no usen un esquema mientras la interfaz circundante usa otro.
Al usar un control de tema del sitio, distingue «sistema» de las decisiones explícitas «claro» y «oscuro». El valor inicial puede seguir la preferencia del sistema; después, una decisión deliberada puede tener prioridad hasta que la persona la cambie. Muestra el control en una zona de configuración previsible, etiquétalo en lenguaje sencillo y facilita volver a «sistema». Evita cambiar automáticamente un tema que la persona haya elegido de forma explícita solo porque más adelante cambie la preferencia del sistema operativo.
Guarda una elección del sitio solo cuando la persistencia aporte algo a la función y el usuario entienda qué se recordará. Guarda el valor de la decisión explícita, no una instantánea de la preferencia del navegador en la primera carga. Si el valor es «sistema», sigue la preferencia actual del sistema. Esta distinción evita que un tema que coincidía en un momento dado se convierta en una modificación obsoleta después de que la persona cambie la configuración del dispositivo. También permite explicar correctamente el comportamiento en la interfaz.
Los controles de tema necesitan nombres accesibles, manejo con teclado, foco visible y un estado seleccionado claro. Un control segmentado puede ofrecer las opciones Sistema, Claro y Oscuro sin ocultar el valor actual en un menú. Si se usa un interruptor compacto, su etiqueta debe dejar claro cuál será el estado resultante y no limitarse a decir «alternar». El color no debe ser la única señal de qué opción está seleccionada. Confirma que el foco, los errores, los enlaces, los gráficos y los cuadros de diálogo tengan colores adecuados en todos los esquemas admitidos, y que un cambio de tema personalizado no muestre brevemente la paleta equivocada antes de aplicarse.
Los cambios de preferencia no deben interrumpir una tarea abierta
Las consultas de medios se evalúan según el entorno actual y no solo una vez al cargar la página. CSS puede responder cuando una persona cambia el tema del sistema operativo o una preferencia de accesibilidad mientras el sitio sigue abierto. Si el comportamiento de la aplicación debe reaccionar, el código JavaScript que usa matchMedia() puede comprobar si una consulta coincide en ese momento y escuchar el evento change. La notificación de cambio de MediaQueryList debe actualizar el comportamiento correspondiente y, después, retirar su escucha cuando el componente o la página ya no la necesite.
Limita la respuesta de JavaScript. Una actualización del tema puede cambiar los colores de las etiquetas de un gráfico, si estos se generan en Canvas y no con CSS. Una actualización de movimiento reducido puede detener una animación no esencial controlada por una biblioteca de componentes. En ambos casos, actualiza únicamente la presentación o el comportamiento afectados. No recargues la página, descartes trabajo sin guardar, cierres un cuadro de diálogo ni restablezcas la aplicación solo porque haya cambiado una preferencia. Las respuestas solo con CSS suelen ser más sencillas y tienen menos probabilidades de interrumpir una tarea en curso.
Una elección explícita del sitio añade una segunda fuente de estado, así que define la prioridad en vez de dejar que la decida el orden de los eventos. Un modelo útil es este: una elección explícita del sitio controla su apariencia; «sistema» delega en la preferencia actual del navegador; y un modo de accesibilidad como los colores forzados sigue respetándose, con independencia de la paleta del sitio, cuando lo aplica el agente de usuario. En cuanto al movimiento, el ajuste de animación del sitio puede controlar sus efectos opcionales, pero no debe iniciar una secuencia automática que contradiga la solicitud de movimiento reducido. Explica claramente las opciones disponibles y facilita volver al comportamiento del sistema.
Aplica los cambios sin ocultar el contexto. Si hay un formulario abierto a medio completar, al cambiar el tema deben conservarse los valores de los campos, los mensajes de validación, el foco y la posición de desplazamiento. Si se activa el movimiento reducido durante una transición animada, deja el componente en un estado estable en lugar de abandonarlo a medio camino. Si se elige una paleta personalizada mientras hay un menú emergente abierto, comprueba que el menú, la capa de fondo y el anillo de foco se actualicen juntos. Un cambio de preferencia debería mejorar la experiencia actual, no obligar a empezar de nuevo.
Algunos comportamientos de la plataforma o del navegador pueden surtir efecto de inmediato, mientras que otros propios de la aplicación pueden esperar al siguiente renderizado. No prometas actualizaciones instantáneas si un gráfico asíncrono o un componente incrustado no puede ofrecerlas. Informa si una acción se retrasa o requiere reiniciar, y conserva la posibilidad de cancelarla. La mayoría de los cambios de presentación no deberían necesitar una recarga; si alguno realmente la necesita, explica por qué antes de que el usuario confirme el cambio.
Prueba la experiencia completa y evita regresiones
Construye una matriz de regresión basada en tareas reales, no solo una galería de capturas. Incluye la apariencia predeterminada, las preferencias clara y oscura, el movimiento reducido, los valores de contraste pertinentes que admitan los navegadores de destino y los colores forzados en una plataforma donde esté disponible ese modo. Prueba combinaciones posibles, como la preferencia oscura con movimiento reducido o un tema elegido en el sitio mientras están activos los colores forzados. La matriz exacta depende del producto, pero cada modo que la interfaz afirme admitir debe producir un resultado observable y contar con una comprobación repetible.
Para cada flujo de trabajo representativo, verifica el inicio, el estado activo, la finalización y la recuperación. Abre y envía un formulario, navega por un menú, revisa un gráfico, cierra un cuadro de diálogo y vuelve de un error. Confirma que el modo actual no oculte el indicador de foco, debilite los límites de los botones, vuelva indistinguibles los estados seleccionados y no seleccionados ni elimine información que antes comunicaba una animación. Repite las rutas usando solo el teclado. Si la tarea depende de un lector de pantalla u otra tecnología de asistencia, comprueba por separado los nombres, roles, valores y anuncios; la cobertura visual de media queries no verifica el árbol de accesibilidad.
Las pruebas visuales automatizadas pueden detectar declaraciones ausentes o cambios inesperados en la disposición, y las pruebas unitarias pueden verificar la prioridad entre la elección del sistema y una elección explícita del sitio. Por sí solas, no pueden determinar si un anillo de foco es fácil de ver, si una animación resulta molesta o si una paleta es cómoda. Combina la automatización con comprobaciones manuales mediante los ajustes de accesibilidad del navegador o del sistema operativo. Registra el navegador, la plataforma, el modo de preferencia, la tarea y los resultados esperados y observados, para poder reproducir una regresión futura sin recopilar preferencias personales de quienes visitan el sitio.
Incluye pruebas de cambios, además de las de carga inicial. Empieza con un esquema y cambia a otro con un formulario parcialmente completado. Activa el movimiento reducido mientras se ejecuta una transición. Cambia el contraste mientras un control tiene el foco en pantalla. Entra o sal del modo de colores forzados cuando la plataforma lo permita. Comprueba que la interfaz se actualice sin perder el foco, los datos introducidos, la selección ni una vía clara para volver atrás. Estas situaciones ejercitan la coordinación de estados que puede pasar desapercibida en una captura de pantalla tomada tras una carga nueva.
Por último, revisa el contenido que depende del color, el movimiento o la forma. Los mensajes de estado deben indicar el resultado; los gráficos deben incluir etiquetas o una alternativa de datos; la animación no debe ser la única forma de descubrir que una tarea terminó; y los iconos que comunican una acción deben tener un nombre accesible. Un cambio de tema no debería reducir el interlineado ni el tamaño del texto hasta alterar el orden de lectura previsto. La mejor prueba de regresión consiste en verificar si una persona aún puede completar la misma tarea, entender el resultado y recuperarse de un error con todas las preferencias admitidas.
Fuentes públicas
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.