Diseñar accesible a escala

La checklist de accesibilidad es útil. Te obliga a mirar lo que normalmente se te escapa: contraste, foco, etiquetas, estados, jerarquía, mensajes de error. El problema es que, en producto real, la checklist casi nunca falla por “mala intención”… falla por cómo se trabaja.

Porque una checklist vive en un documento; un producto vive en un ecosistema cambiante: nuevas pantallas, nuevos componentes, rediseños parciales, experimentos A/B, prisas por salir, equipos distintos tocando lo mismo. En ese contexto, la accesibilidad no se rompe de golpe: se desgasta. Un botón nuevo “casi igual” que el anterior, un modal que aparece sin gestionar el foco, un color de campaña que entra por marketing y deja textos por debajo del contraste mínimo, un error que solo se ve en rojo, un dropdown que funciona con ratón pero no con teclado. Y cuando te das cuenta, ya no es un fallo: es un patrón.

Además, la checklist suele llegar tarde. Se aplica al final, cuando “ya está diseñado”, como si la accesibilidad fuese una revisión estética. Pero la accesibilidad es comportamiento, estructura y estados: cosas que, si no están previstas desde el principio, se convierten en parches que molestan al usuario y frustran al equipo (“otra vez hay que rehacer el componente”, “otra vez QA lo tira para atrás”).

Si quieres diseñar accesible a escala, no necesitas más checklists. Necesitas que la accesibilidad deje de depender de la memoria o del cuidado individual y pase a ser parte del sistema: decisiones reutilizables (tokens), componentes con contrato (cómo se comportan siempre) y controles de calidad (QA) que eviten regresiones. No para “cumplir”, sino para construir una experiencia consistente, robusta y sostenible en el tiempo.

En otras palabras: la checklist te ayuda a detectar problemas. Un sistema de diseño accesible evita que vuelvan a aparecer.

EAA + EN 301 549 en 3 ideas prácticas

No necesitas convertirte en jurista para diseñar accesible a escala, pero sí entender qué está cambiando en Europa y por qué ya no vale “lo revisamos al final”. Quédate con estas tres ideas:

1. El EAA convierte la accesibilidad en un requisito de producto

El European Accessibility Act (EAA) empuja a que determinados productos y servicios (especialmente digitales y de consumo) tengan requisitos de accesibilidad comunes en la UE. En la práctica, esto significa que accesibilidad deja de ser “depende del cliente” o “depende del equipo” y pasa a ser un criterio de salida: algo que afecta a diseño, desarrollo, QA y documentación.

2. EN 301 549 es el puente entre “norma” y “requisitos verificables”

La EN 301 549 es una norma europea pensada para aterrizar la accesibilidad en requisitos técnicos y funcionales para productos/servicios TIC. Traducido a tu día a día: no te pide “hacerlo más usable”, sino que puedas demostrar cosas concretas como navegación por teclado, compatibilidad con tecnologías de asistencia, alternativas textuales, control del foco, etc. Es el tipo de marco que te interesa cuando trabajas con sistemas de diseño, porque te obliga a pasar de “intención” a criterios repetibles.

3. Lo práctico: no diseñes para “pasar una auditoría”, diseña para no romperlo en la siguiente release

La trampa habitual es pensar en EAA/EN 301 549 como “la auditoría que viene”. Pero en equipos reales, el mayor enemigo no es la auditoría: son las regresiones. Lo que hoy cumple, mañana se rompe con un cambio pequeño (un token de color, un componente “clonado”, un nuevo patrón de modal). Por eso, el enfoque más eficiente no es añadir controles al final, sino construir una base que haga difícil hacerlo mal: reglas en tokens, contratos en componentes y puertas de QA. Y esto, además, encaja con cómo la propia UE aborda la accesibilidad digital a través de estándares y armonización: el foco está en que sea implementable y verificable, no solo declarativo.

Con este contexto, el objetivo ya no es “cumplir una vez”, sino cumplir siempre. Y ahí es donde pasamos del checklist al método: Tokens → Componentes → QA.

El método: Tokens → Componentes → QA 

Si quieres accesibilidad a escala, necesitas un enfoque que aguante cambios, equipos distintos y nuevas features sin depender de la memoria de nadie. El método que mejor funciona en la práctica es este:

1. Tokens: decisiones globales que no se negocian pantalla a pantalla

Los tokens son la capa de “reglas base” del producto: colores, tipografías, espaciados, estilos de foco, estados, movimiento…Cuando accesibilidad está en tokens, dejas de discutirla en cada diseño y pasas a tener un estándar. Ejemplos típicos:

• Paletas con combinaciones que ya cumplen contraste.
• Tamaños mínimos de texto y line-height.
• Espaciado/tamaños táctiles mínimos.
• Estilos de foco consistentes y visibles.
• Motion con respeto a preferencias del usuario.

Ventaja clave: reduces el número de decisiones “peligrosas” en cada nueva pantalla. Si el token es accesible, el sistema tiende a salir accesible.

2. Componentes: contratos reutilizables

Un componente accesible no es solo “cómo se ve”, es cómo se usa: teclado, foco, lectura por tecnologías de asistencia, estados y mensajes.

Aquí está el salto de madurez: cada componente del sistema debe tener un contrato que diga:

• Qué soporta por teclado (Tab, Enter, Escape, flechas…).
• Cómo gestiona el foco (al abrir, al cerrar, al error).
• Qué etiquetas y relaciones necesita (label, helper text, error).
• Qué roles/atributos aplica (cuando toca) y cuáles están prohibidos.
• Cómo se comporta en estados límite (loading, disabled, empty, error).

Ventaja clave: evitas que cada equipo “reinvente” un dropdown, un modal o un formulario… y lo rompa de una forma distinta.

3. QA: puertas de control para evitar regresiones

Incluso con tokens y componentes, la accesibilidad se puede romper. La diferencia es que con un sistema, puedes poner gates: controles que detectan y bloquean regresiones antes de que lleguen a producción.

QA aquí significa tres cosas, muy concretas:

• Criterios de aceptación: qué debe cumplir cada UI antes de considerarse “done”.
• Revisión sistemática (manual y automática): navegación por teclado, foco, zoom/reflow, lector de pantalla en puntos críticos.
• Definición de “no pasa”: qué fallos bloquean release y cuáles entran a deuda con fecha.

Ventaja clave: accesibilidad deja de ser una revisión heroica al final y pasa a ser parte del flujo normal de entrega.

La idea importante: Tokens evitan problemas, componentes los encapsulan, y QA impide que vuelvan.A partir de aquí, lo aterrizamos: primero tokens (dónde suelen estar las regresiones) y después componentes (dónde suelen estar las trampas).

Tokens accesibles que previenen regresiones

Si tuviera que elegir un sitio donde la accesibilidad se rompe “sin que nadie se dé cuenta”, serían los tokens. Porque los tokens cambian poco a poco (un rediseño, una campaña, un refresh de marca) y ese cambio se propaga a todo el producto. La buena noticia: si defines bien estos tokens, previenes la mayoría de regresiones sin añadir fricción al equipo.

Color y contraste: diseña una paleta “segura por defecto”

Aquí no se trata de memorizar ratios, sino de construir una paleta que no permita combinaciones peligrosas.

• Define tokens de color por rol: text/primary, text/secondary, bg/default, bg/subtle, border/default, status/success|warning|error.
• Para cada rol, valida pares típicos: texto sobre fondo, iconos sobre fondo, borde sobre fondo, estados hover/active/disabled.
• Evita que “marketing colors” entren como texto sin pasar por el sistema: que puedan vivir como acentos, pero no como text/primary si no cumplen.

Regresión típica: el contraste se rompe en hover o disabled, no en el estado normal.

Tipografía: tokens que aguantan zoom, legibilidad y jerarquía

La tipografía accesible es menos “estética” y más “resistente”.

• Tokens de tamaño y line-height por escala: font/size/* y font/lineHeight/*.
• Asegura que el cuerpo de texto tenga una base cómoda y escalable (y que no dependa de “12px porque cabe”).
• No olvides tokens de font/weight y letterSpacing: algunos pesos finos en tamaños pequeños son un imán de problemas.

Regresión típica: un cambio de fuente o de weight que hace que el texto “parezca” más pequeño y pierda legibilidad (sin que nadie lo mida).

Espaciado y tamaños interactivos: el token invisible que reduce errores

La accesibilidad también es motricidad. Y esto se decide con spacing, no con copy.

• Tokens de espacio coherentes (space/1..n) y reglas para densidad.
• Define mínimos para objetivos interactivos (botones, iconos clicables, chips) y úsalo como “contrato” del sistema.
• Separa tokens de layout (márgenes/padding) de tokens de interacción (hit area).

Regresión típica: iconos que eran fáciles de pulsar y, tras un rediseño “más limpio”, se vuelven demasiado pequeños o pegados.

Foco: token + estilo, no “un borde azul que ya veremos”

El foco es una de las cosas más importantes y más ignoradas… hasta que falla.

• Crea tokens específicos: focus/color, focus/width, focus/offset, focus/radius, focus/style.
• Decide cuándo usar :focus-visible (idealmente por defecto) para que el foco aparezca cuando toca, sin molestar a quien usa ratón.
• Asegura contraste suficiente del foco sobre fondos claros y oscuros (y sobre componentes con borde).

Regresión típica: el foco desaparece en modales, headers sticky o componentes con overflow: hidden.

Motion: tokens para animación con freno incorporado

No se trata de “prohibir animaciones”, sino de hacerlas seguras y controlables.

• Tokens de duración y easing (motion/duration/*, motion/easing/*) y límites razonables.
• Política clara para animaciones grandes (parallax, auto-play, transiciones agresivas).
• Soporte explícito a preferencias de usuario: reduce motion cuando corresponda.

Regresión típica: una animación “bonita” introduce mareo o distrae, y nadie lo detecta porque en el equipo nadie lo sufre… hasta que usuarios lo reportan.

La idea central: los tokens son tu cinturón de seguridad. Si los defines bien, muchas decisiones de accesibilidad pasan de ser “revisión manual” a ser “propiedad del sistema”. En la siguiente sección bajamos a tierra los componentes: donde el diseño se convierte en comportamiento y donde más trampas aparecen (formularios, modales, menús…).

Componentes con contrato de accesibilidad

Los tokens ponen la base, pero donde la accesibilidad se gana o se pierde de verdad es en los componentes. Aquí el objetivo no es “añadir ARIA”, sino definir un contrato: qué debe hacer siempre el componente, sin depender de quién lo implemente o en qué pantalla aparezca.

Formularios y errores: el 80% de la fricción está aquí

Contrato mínimo:

• Cada campo tiene label visible (si se oculta, se justifica y se hace bien, pero por defecto visible).
• La ayuda y el error están asociados al campo (no solo “debajo en rojo”).
• El error explica qué ha pasado y cómo resolverlo (no “campo inválido”).
• Estados claros: default / focus / filled / error / disabled (y no solo con color).

Trampas típicas:

• Marcar error solo con rojo.
• Mensajes genéricos que no ayudan a corregir.
• Validación que salta tarde o de forma impredecible (y rompe el flujo).

Modales y drawers: si el foco no está controlado, todo se cae

Contrato mínimo:

• Al abrir: el foco va a un punto lógico (título, primer campo o acción principal).
• Mientras está abierto: el foco no escapa al contenido de fondo.
• Al cerrar: el foco vuelve al elemento que lo abrió.
• Se puede cerrar con Escape y con un control visible (y no depende de “hacer clic fuera”).
• El fondo no “compite” (scroll bloqueado si aplica, y nada interactivo queda accesible detrás).

Trampas típicas:

• Modales “bonitos” que son solo una capa visual, pero el teclado sigue navegando por el fondo.
• Cierre que devuelve al inicio de la página (pérdida de contexto).

Menús y combobox: el patrón donde más se improvisa

Aquí conviene ser estrictos: no todo dropdown es un combobox, y no todo se resuelve “a mano”.

Contrato mínimo:

• Si es select simple, que se comporte como tal (no reinventar).
• Si es buscador con sugerencias, define comportamiento por teclado (flechas, Enter, Escape) y estados (sin resultados, cargando).
• El estado seleccionado se comunica de forma clara (visual + textual).
• Si hay resultados dinámicos, el componente gestiona bien cambios sin “saltos” y sin perder foco.

Trampas típicas:

• Dropdown que solo funciona con ratón.
• Scroll dentro de lista que “atrapa” y desorienta.
• Resultados que cambian y el foco se queda “en tierra de nadie”.

Tabs y acordeón: navegación clara, estructura consistente

Contrato mínimo (tabs):

• Navegable por teclado de forma coherente.
• El tab activo se distingue sin depender solo del color.
• El contenido asociado es claro (no “parece tab, pero es un filtro”).

Contrato mínimo (acordeón):

• Cabeceras accionables de verdad (no bloques clicables ambiguos).
• Estado expandido/colapsado evidente.
• Mantiene contexto al interactuar (sin saltos raros de scroll).

Trampas típicas:

• Usar tabs como navegación “decorativa” sin una relación real con paneles.
• Acordeones que expanden pero te dejan mirando a mitad de contenido sin orientación.

La clave: un sistema de diseño no dice solo “así se ve”. Dice así se comporta. Si cada componente tiene este contrato (aunque sea breve), reduces decisiones improvisadas y, con ello, reduces regresiones.

Conclusión

Puedes tener los mejores tokens y componentes del mundo y, aun así, perder accesibilidad en dos releases. No por mala praxis, sino por la realidad del producto: cambios rápidos, nuevas manos, presión por entregar. Por eso, la accesibilidad a escala no se “revisa”: se mantiene con QA y una gobernanza mínima pero constante.

Gates: decide qué se bloquea y qué no

Un gate es una puerta de control: si no se cumple, no pasa. Suena duro, pero evita el “lo arreglamos luego” que se convierte en rutina.

• Define una lista corta de fallos bloqueantes (por ejemplo: no se puede navegar por teclado, foco invisible, modal sin control de foco, formularios sin label, errores solo por color).
• El resto puede entrar como deuda, pero con responsable y fecha. Si no, no es deuda: es olvido.

Automatización + revisión manual: cada una para lo que sirve

La automatización detecta patrones y regresiones evidentes, pero no entiende toda la experiencia. Por eso funciona en dúo:

• Automático: checks en CI/PR para pillar lo repetible.
• Manual (ligero y sistemático): teclado, foco, zoom/reflow y, cuando aplique, una pasada con lector de pantalla en flujos críticos.

No se trata de “probar todo”, sino de probar siempre lo que más se rompe.

Definition of Done: accesibilidad como parte de “terminar”

Si tu equipo tiene un “done” que no incluye accesibilidad, sin querer está diciendo: no es parte del trabajo. Cambia eso con una definición breve y operativa:

• Cumple el contrato del sistema (tokens + comportamiento).
• Estados clave contemplados: loading / empty / error / disabled.
• Teclado validado.
• Foco visible y lógico.
• Errores claros y accionables (si hay formularios).

Gobernanza ligera: ownership, versionado y deuda visible

No necesitas un comité. Necesitas tres cosas que sostengan el sistema:

• Ownership del sistema de diseño.
• Versionado de componentes para no romper contratos “en silencio”.
• Backlog de accesibilidad visible y priorizado.

Cuando tokens, componentes y QA trabajan juntos, la accesibilidad deja de depender de héroes y de auditorías puntuales. Se convierte en una propiedad del producto: consistente, repetible y sostenible. Y eso es, precisamente, diseñar accesible a escala.

¿Tu sistema de diseño hace fácil “hacerlo bien”… o sigue obligando a revisar accesibilidad pantalla a pantalla?

Fuentes:

• Blog de ITDO