Personalización y preferencias: la interfaz que se adapta a cada persona

Durante dos décadas, la accesibilidad web ha funcionado sobre todo como una única interfaz que debe servir a todo el mundo. Esa interfaz común seguirá siendo la base, pero la tendencia de fondo es otra: que cada persona pueda adaptar la presentación y, cada vez más, la complejidad del contenido a sus necesidades. En la lección sobre HTML y CSS moderno viste las consultas prefers-* y forced-colors; aquí damos el paso siguiente: cómo diseñar una arquitectura de personalización que respete las preferencias del sistema, qué trabajos del W3C apuntan a personalizar también el significado, cómo encaja la accesibilidad cognitiva y qué errores convierten la personalización en un problema.

Por qué la talla única no basta

Las necesidades de accesibilidad a veces chocan entre sí. Una persona con baja visión puede necesitar texto grande y contraste máximo; una persona con fotofobia o con ciertas dificultades de lectura puede leer mejor con fondo oscuro o con menos contraste. Quien tiene una discapacidad intelectual puede necesitar menos opciones en pantalla; una persona experta que usa lector de pantalla quiere todas las opciones accesibles sin pasos extra. WCAG resuelve parte de ese conflicto fijando mínimos comunes y exigiendo que el contenido aguante las adaptaciones que hace el usuario: 1.4.4 Cambio de tamaño del texto, 1.4.10 Reajuste de los elementos del contenido (reflow), 1.4.12 Espaciado del texto y 1.3.4 Orientación son, en el fondo, criterios de personalización: no piden que la web se adapte sola, sino que no se rompa cuando la persona la adapta.

Tres capas de personalización

Conviene pensar la personalización en tres capas, de la más general a la más específica, y diseñar para que se sumen y no se contradigan:

1. Sistema operativo y navegador. Es la capa preferente porque la persona la configura una vez y se aplica a todo: tamaño de texto, modo oscuro, reducción de movimiento, aumento de contraste, colores forzados, subtítulos. La web debe leerla mediante las consultas de medios y no anularla.
2. Ajustes del sitio o la aplicación. Útiles para lo que el sistema no ofrece o para cambiar algo solo en un servicio: densidad de la información, ocultar contenido animado decorativo, elegir un modo de lectura simplificado, recordar el idioma. Deben ser accesibles ellos mismos, persistir entre sesiones y no duplicar lo que ya ofrece el sistema.
3. Herramientas de la persona. Extensiones, modos de lectura del navegador, lectores de pantalla, magnificadores y, cada vez más, asistentes de IA que resumen o reformulan. La web no las controla, pero sí puede facilitarlas con semántica correcta y contenido bien estructurado.

La diferencia con un overlay, del que hablaremos en la lección sobre IA, es clara: aquí los ajustes del sitio complementan las preferencias del sistema y se construyen sobre un código ya accesible; el overlay pretende sustituir ambas cosas con un panel genérico.

Respetar el sistema y permitir cambiarlo

El patrón técnico recomendable es: por defecto, seguir la preferencia del sistema; si la persona elige otra cosa en el sitio, recordar su elección y aplicarla por encima. Con propiedades personalizadas de CSS y la función light-dark(), disponible en los navegadores principales desde 2024, se resuelve con poco código:

:root {
  color-scheme: light dark;            /* sigue al sistema */
  --texto: light-dark(#1a1a1a, #f2f2f2);
  --fondo: light-dark(#ffffff, #121212);
}
:root[data-tema="claro"]  { color-scheme: light; }   /* elección del usuario */
:root[data-tema="oscuro"] { color-scheme: dark; }
body { color: var(--texto); background: var(--fondo); }

@media (prefers-reduced-motion: reduce) {
  :root:not([data-movimiento="si"]) * { animation: none; transition: none; }
}

<fieldset>
  <legend>Tema de colores</legend>
  <label><input type="radio" name="tema" value="sistema" checked> Como mi dispositivo</label>
  <label><input type="radio" name="tema" value="claro"> Claro</label>
  <label><input type="radio" name="tema" value="oscuro"> Oscuro</label>
</fieldset>

Observa los detalles: la opción por defecto es «Como mi dispositivo», el control es un grupo de botones de opción nativos con <legend>, y la reducción de movimiento del sistema solo se anula si la persona lo pide de forma explícita. Comprueba siempre el contraste en ambas paletas (1.4.3 Contraste (mínimo), 1.4.11 Contraste no textual) y que el ajuste se guarda en el perfil de la persona si ha iniciado sesión, no solo en el navegador.

Personalizar el significado: WAI-Adapt y accesibilidad cognitiva

Las preferencias de presentación cambian cómo se ve el contenido; el siguiente paso es cambiar cómo se entiende. El grupo de arquitecturas de plataformas accesibles del W3C trabaja en WAI-Adapt, un conjunto de especificaciones en desarrollo que proponen añadir al código información semántica adicional para que el agente de usuario pueda adaptar el contenido. Su módulo más avanzado se centra en los símbolos: permite asociar palabras y controles a conceptos de un vocabulario de símbolos para que una persona usuaria de comunicación aumentativa y alternativa vea los pictogramas que conoce. Otras líneas de trabajo exploran marcar el contenido esencial frente al secundario o indicar ayudas disponibles. Su estado y su sintaxis pueden cambiar: en el radar de la lección sobre procesos de normalización estarían en «Vigilar».

En paralelo, la accesibilidad cognitiva ha ganado peso normativo en España. La Ley 6/2022 (PDF, se abre en una ventana nueva), de 31 de marzo, modificó el Texto Refundido de la Ley General de derechos de las personas con discapacidad (RDL 1/2013 (PDF, se abre en una ventana nueva)) para establecer y regular la accesibilidad cognitiva como parte de la accesibilidad universal, incluida la comprensión de entornos, productos y servicios. Para un servicio digital, eso refuerza lo que ya conoces de lectura fácil (UNE 153101 EX) y de los patrones de la nota del W3C Making Content Usable: lenguaje claro, pasos cortos, ayuda visible, prevención de errores. La personalización añade una vía: ofrecer, por ejemplo, una versión resumida o simplificada de un trámite elegida por la persona.

Límites, privacidad y equidad

• Pregunta por preferencias, no por diagnósticos. «¿Prefieres textos más breves?» es aceptable; «¿Tienes una discapacidad cognitiva?» no lo es. Los datos de salud son categoría especial en el Reglamento General de Protección de Datos (artículo 9) y no son necesarios para adaptar una interfaz.
• No detectes tecnologías de apoyo. Intentar averiguar si alguien usa lector de pantalla para servirle una versión distinta es poco fiable, invade la privacidad y crea webs paralelas que se quedan desactualizadas.
• Mantén la paridad funcional. Un modo simplificado no puede ocultar opciones, plazos ni derechos: debe ofrecer lo mismo de otra forma o enlazar claramente al resto.
• Ajustes accesibles y descubribles. El acceso a las preferencias debe estar en un lugar consistente (piensa en 3.2.6 Ayuda coherente) y operable con teclado y lector de pantalla.

Resumen

• La personalización complementa la conformidad: criterios como 1.4.4, 1.4.10, 1.4.12 y 1.3.4 garantizan que el contenido aguante las adaptaciones de la persona.
• Diseña en tres capas: preferencias del sistema primero, ajustes del sitio que las complementan y persisten, y herramientas de la persona facilitadas por buena semántica.
• Sigue al sistema por defecto, permite cambiarlo con controles nativos y prueba siempre en colores forzados, zoom y ambas paletas.
• WAI-Adapt (en desarrollo) y la Ley 6/2022 de accesibilidad cognitiva apuntan a adaptar también la comprensión, siempre con paridad funcional.
• Pregunta por preferencias y no por diagnósticos, y no detectes tecnologías de apoyo.