Diseño inclusivo: más allá del cumplimiento WCAG, pensar en todas las personas

Hace un par de años revisamos la web de una academia de idiomas que acababa de pasar una auditoría de accesibilidad con buena nota. Contraste correcto, textos alternativos en todas las imágenes, navegación por teclado impecable. Y aun así, en la primera sesión de pruebas, una alumna con dislexia tardó casi diez minutos en entender cómo se matriculaba en un curso. El proceso cumplía cada criterio técnico, pero estaba escrito en un lenguaje administrativo, repartía la información en cuatro pantallas y le pedía recordar un código de grupo que había visto dos pasos antes.

Esa escena resume bien lo que quiero contar aquí. Las pautas WCAG son una base imprescindible y conviene cumplirlas con rigor. Pero el diseño inclusivo hace una pregunta más amplia: quién se está quedando fuera de lo que diseñamos, y qué aprendemos si lo diseñamos con esas personas delante.

En el estudio lo vivimos casi como una forma de mirar. Cuando un proyecto arranca pensando en la diversidad real de quienes lo van a usar, las decisiones salen más claras, la marca se percibe más cercana y la web funciona mejor para todo el mundo, incluidas las personas que nunca se considerarían «usuarios con necesidades especiales».

01WCAG es el suelo; el diseño inclusivo es la casa

Las WCAG (Web Content Accessibility Guidelines) son las pautas del W3C para que el contenido web sea accesible. La versión vigente es la WCAG 2.2, publicada en octubre de 2023, con criterios organizados en tres niveles (A, AA y AAA). El nivel AA es el que suelen exigir las normas europeas y españolas. Si quieres repasar los fundamentos, los contamos en qué es la accesibilidad web.

WCAG funciona como una lista de comprobación: un texto tiene contraste suficiente o no lo tiene, un botón se alcanza con teclado o no. Esa precisión es su gran virtud, porque permite auditar y comparar. También marca su alcance: describe lo que tiene que funcionar, y deja a criterio del equipo cómo se vive la experiencia.

El diseño inclusivo, tal como lo formuló el equipo de Microsoft en su Inclusive Design Toolkit y lo desarrolló Kat Holmes en su libro Mismatch (2018), parte de una idea sencilla: la discapacidad aparece en el desajuste entre una persona y su entorno. Si el entorno (la web, la app, el formulario) está pensado para un único tipo de cuerpo, de mente y de situación, genera desajustes. Si se diseña reconociendo la variedad humana, los reduce.

Las dos columnas se necesitan. Lo que funciona es usar WCAG como red de seguridad y el diseño inclusivo como brújula.

02El espectro de personas: permanente, temporal y situacional

La herramienta más útil que conozco para salir del «usuario medio» es el espectro de personas del toolkit de Microsoft. Propone pensar cada capacidad en tres escalas:

• →Permanente: una persona con un solo brazo, ceguera o sordera.
• →Temporal: alguien con el brazo escayolado, una infección de oído o la vista cansada tras una operación de cataratas.
• →Situacional: un padre con un bebé en brazos, un conductor que no puede mirar la pantalla, alguien en un bar ruidoso o al sol en una terraza.

El ejercicio cambia la conversación con cualquier cliente. Cuando hablamos de diseñar para personas con una sola mano, a veces se percibe como un nicho. Cuando lo planteamos como «tu web tiene que poder usarse con una mano mientras la otra sujeta un café o la correa del perro», todo el equipo lo entiende al momento. Y la solución es la misma: botones grandes en la zona del pulgar, acciones principales sin gestos complejos, nada que dependa de pulsar dos cosas a la vez.

Hay una cifra que ayuda a dimensionarlo. Según la Organización Mundial de la Salud, unas 1.300 millones de personas, alrededor del 16 % de la población mundial, viven con una discapacidad significativa. A eso súmale todas las limitaciones temporales y situacionales de un día cualquiera y el «caso extremo» pasa a ser una parte enorme de tu público.

Clave: cuando resuelves bien el caso de una persona con una limitación permanente, sueles resolver a la vez el de muchas más personas que viven esa misma limitación de forma temporal o por su contexto.

Es el famoso efecto bordillo (curb-cut effect): los rebajes de las aceras se pidieron para las sillas de ruedas y hoy los agradecen carritos, maletas y repartidores. En digital ocurre con los subtítulos, que nacieron para personas sordas y hoy se activan en el metro o en la oficina con el móvil en silencio.

03Más allá de la discapacidad: las otras diversidades

Pensar en todas las personas incluye dimensiones que WCAG apenas toca. En los proyectos del estudio repasamos al menos estas cinco.

Diversidad cognitiva y neurodivergencia

Dislexia, TDAH, autismo, deterioro cognitivo leve, ansiedad o simplemente cansancio. El W3C publicó en 2021 una guía específica, Making Content Usable for People with Cognitive and Learning Disabilities, que recoge patrones muy concretos: un objetivo por página, pasos visibles, posibilidad de volver atrás sin perder datos, instrucciones cerca del lugar donde se aplican, evitar límites de tiempo innecesarios. WCAG 2.2 incorporó algunos de ellos, como el criterio de autenticación accesible (3.3.8), que evita obligar a memorizar o transcribir códigos, o el de entrada redundante (3.3.7), que pide no volver a solicitar un dato que la persona ya ha dado en el mismo proceso.

Diversidad lingüística

En la Costa del Sol esto lo vemos cada semana: webs que tienen que servir a residentes británicos, escandinavos, alemanes y a público local. Inclusión aquí significa un lenguaje claro en todos los idiomas, traducciones hechas por personas que conocen el contexto y una interfaz que aguanta textos un 30 % más largos en alemán que en inglés sin romperse. La norma ISO 24495-1:2023 sobre lenguaje claro es una buena referencia para definir qué significa «claro» en un proyecto.

Diversidad de edad

Las personas mayores son uno de los grupos que más usan internet para trámites, salud y banca, y uno de los que más fricción encuentra. Le dedicamos una guía propia sobre UX para personas mayores, porque combina cambios en la visión, la destreza y la confianza digital.

Diversidad de identidad y de vida

Formularios que solo admiten «Sr./Sra.», campos de nombre que rechazan apellidos compuestos, tildes o la letra ñ, apartados de «familia» que asumen padre y madre. Son detalles pequeños que hacen sentir a una persona que esa web no está pensada para ella.

Diversidad de contexto técnico

Móviles de gama baja, pantallas pequeñas, datos limitados, conexiones lentas en zonas rurales, navegadores antiguos en ordenadores de bibliotecas. Una web ligera, que carga lo esencial primero, es una web más inclusiva.

04Cómo se aplica en un proyecto: seis pasos

El diseño inclusivo se nota sobre todo en el proceso. Este es el orden que seguimos cuando lo incorporamos de verdad a un proyecto web.

1. 01Mapea las exclusiones antes de diseñar. En el taller inicial, además de definir a quién quieres llegar, lista quién podría quedarse fuera: por capacidad, idioma, edad, dispositivo o situación. Es un ejercicio de media hora que cambia el briefing.
2. 02Recluta a personas de los extremos para investigar. Habla con dos o tres personas que vivan esas exclusiones: alguien que use lector de pantalla, alguien mayor, alguien que navegue en otro idioma. Microsoft lo llama «aprender de la diversidad»: los extremos revelan problemas que en el centro pasan desapercibidos.
3. 03Diseña soluciones que sirvan a uno y se extiendan a muchos. Busca la solución que resuelve el caso permanente y comprueba a quién más ayuda. Si solo sirve a un grupo, quizá sea una opción adicional; si ayuda a casi todos, va al diseño principal.
4. 04Escribe en lenguaje claro desde el primer wireframe. Frases cortas, palabras comunes, un dato por frase. El texto es diseño, y en accesibilidad cognitiva pesa tanto como el color.
5. 05Construye sobre HTML semántico y preferencias del sistema. Respeta los ajustes que la persona ya ha elegido en su dispositivo: tamaño de texto, movimiento reducido, alto contraste, modo oscuro.
6. 06Prueba con personas diversas, no solo con herramientas. Los validadores automáticos detectan solo una parte de los problemas de accesibilidad. El resto aparece cuando una persona real intenta completar una tarea. En nuestra guía de test de usabilidad paso a paso explicamos cómo organizarlo.

05Lo técnico que sostiene la inclusión

Gran parte de la inclusión se decide en el código, y casi siempre son decisiones sencillas. Este fragmento recoge tres que aplicamos por defecto: respetar el movimiento reducido, adaptarse al modo de alto contraste de Windows y dejar un foco visible y generoso.

/* Movimiento: animaciones suaves solo si la persona no ha pedido reducirlo */
@media (prefers-reduced-motion: no-preference) {
  .hero__title { animation: fade-up 600ms ease-out both; }
}
/* Modo de colores forzados (alto contraste en Windows) */
@media (forced-colors: active) {
  .button { border: 2px solid ButtonText; }
  .icon { forced-color-adjust: auto; }
}
/* Foco visible y amplio para teclado */
:focus-visible {
  outline: 3px solid #1a5cff;
  outline-offset: 3px;
}
/* Tamaños en rem para respetar el tamaño de letra del sistema */
html { font-size: 100%; }
body { font-size: 1.125rem; line-height: 1.6; }

Y en los formularios, la inclusión pasa por pedir menos y aceptar más. Un único campo de nombre completo, en lugar de nombre y dos apellidos obligatorios, encaja con muchas más culturas. Los atributos autocomplete ayudan a quien tiene dificultades motoras o de memoria, y las etiquetas visibles ayudan a todo el mundo.

<label for="nombre">Nombre y apellidos</label>
<input id="nombre" name="nombre" type="text" autocomplete="name" required>
<label for="tratamiento">Cómo prefieres que te llamemos <span>(opcional)</span></label>
<input id="tratamiento" name="tratamiento" type="text">
<label for="tel">Teléfono</label>
<input id="tel" name="tel" type="tel" autocomplete="tel" inputmode="tel">

Los objetivos táctiles merecen una mención aparte. WCAG 2.2 fija un mínimo de 24 × 24 píxeles CSS en su criterio 2.5.8, y las guías de Apple recomiendan 44 × 44 puntos. En nuestros proyectos tomamos 44 como referencia para cualquier acción importante, porque es lo que resulta cómodo con un pulgar en movimiento.

06Una checklist para revisar tu web con ojos inclusivos

Además de la auditoría WCAG, esta lista recoge lo que solemos revisar en una web ya publicada. No hace falta resolverlo todo a la vez; con elegir tres puntos y mejorarlos, la diferencia se nota.

• →La tarea principal se completa con teclado, con lector de pantalla y con una sola mano en el móvil.
• →Los textos se entienden a la primera: frases de menos de 20 palabras de media, términos técnicos explicados.
• →Cada página tiene un objetivo claro y una acción principal visible.
• →Los procesos largos muestran en qué paso estás y permiten volver sin perder lo escrito.
• →Los formularios aceptan nombres con tildes, ñ, guiones y apóstrofos, y no piden datos innecesarios.
• →La web se lee bien con el texto ampliado al 200 % y en pantallas de 320 px de ancho.
• →Las animaciones se detienen cuando el sistema pide movimiento reducido.
• →Los vídeos llevan subtítulos y la información clave también está en texto.
• →La web carga lo importante con rapidez en una conexión móvil lenta.
• →El color nunca es la única forma de transmitir un estado (error, éxito, disponible).
• →Las imágenes y la fotografía muestran a personas diversas de forma natural, sin forzar.

Este último punto conecta el diseño inclusivo con la marca. Una identidad que solo representa a un tipo de persona en sus fotos, su tono y sus ejemplos comunica, sin decirlo, a quién está dirigida. Cuidar la representación es parte del mismo trabajo.

07Un ejemplo resuelto: la reserva de un centro de fisioterapia

Para aterrizarlo, te cuento cómo abordaríamos el sistema de citas online de un centro de fisioterapia en Marbella, un tipo de proyecto que conocemos bien.

Situación de partida. El formulario de reserva cumple WCAG AA. Tiene contraste correcto, etiquetas y navegación por teclado. Aun así, muchas reservas acaban por teléfono.

Quién puede quedarse fuera. Pacientes con dolor en un brazo u hombro (que usan el móvil con una mano y con molestias), personas mayores con poca soltura digital, residentes extranjeros que leen español con esfuerzo y personas con ansiedad ante trámites médicos.

Qué cambiamos.

1. 01El calendario pasa de una cuadrícula mensual con días diminutos a una lista de próximos huecos disponibles, con botones de 48 píxeles de alto.
2. 02El proceso se reduce de cuatro pantallas a dos, con un indicador de pasos y un resumen visible antes de confirmar.
3. 03Los textos se reescriben en lenguaje claro y se ofrecen en inglés con una traducción revisada por una persona nativa.
4. 04Se añade una opción visible de «Prefiero que me llaméis», que respeta a quien no quiere completar el trámite online.
5. 05La confirmación llega por email y SMS, con la dirección, el nombre del fisioterapeuta y cómo cambiar la cita en un enlace.

Ninguno de estos cambios es exótico ni requiere tecnología especial. Son decisiones de criterio, tomadas después de escuchar a las personas que más dificultades tenían. Y benefician a todos los pacientes, también a los que nunca habrían tenido un problema con el formulario anterior.

08La inclusión como parte de la identidad

Cuando una marca diseña pensando en todas las personas, se nota en algo más que en una web que funciona. Se percibe en el tono, en las imágenes, en la paciencia de los mensajes de error, en la opción de hablar con alguien cuando la pantalla no basta. Es una forma de respeto, y la gente la reconoce.

En SIMA trabajamos la inclusión como parte del criterio de diseño web y experiencia digital, desde la primera conversación hasta las pruebas finales. Si quieres revisar tu web con esta mirada, o empezar un proyecto que la tenga en cuenta desde el principio, escríbenos y lo hablamos con calma.