Hace cinco años, accesibilidad web era lo cool. Wcag 2.1, contraste de colores, navegación por teclado. Todos los diseñadores jurabamos que importaba. Y bueno, algunos lo creían de verdad.
Hoy estoy mirando un portafolio de diseñador «premium» y… madre mía, es una catástrofe. Fondos con textura, letras pequeñas sobre gradientes sin contraste, navegación por componentes interactivos que requieren que veas con claridad y entiendas transiciones microinteractivas.
¿La realidad? Más del 15% de la población tiene alguna discapacidad visual. Otros tantos tienen dificultades cognitivas. Pero parece que diseñar para ellos es «sacrificar la estética».
Yo creo que no. Creo que hemos decidido que es más fácil mentir.
El lavado de manos: «eso lo hace el desarrollador»
Aquí viene la conversación incómoda. Hace poco hablé con un diseñador de una agencia top. Me dijo literalmente: «Yo hago el diseño, accesibilidad es responsabilidad del dev».
Perfecto. Un diseñador que no entiende que su trabajo define cómo se vé en tiempo real. Que cree que el ARIA, el semantic HTML y los tokens de contraste son cosa de programadores. Como si los «divs» fueran a arreglarse solos de la accesibilidad.
No funciona así. Si tú, el diseñador, creas un diseño que viola WCAG 2.1, ningún dev va a poder repararlo 100%. Los desarrolladores pueden mejorar cosas, pero tú ya habrás fallado.
Es como un arquitecto que dice: «Yo diseño edificios hermosos, que el constructor se encargue de que no se caigan». Te suena insensato, ¿verdad? Pues en web hacemos esto cada día.
El culpable silencioso: Figma y las herramientas visuales
No es culpa de Figma exactamente, pero la plataforma ha democratizado una cosa peligrosa: todos pueden ser diseñador.
Hace una década necesitabas Adobe Creative Suite, algo de educación en diseño y tiempo. Hoy cualquier junior tira componentes en Figma y, boom, «tengo un portfolio».
¿La consecuencia? Menos diseñadores entienden la web realmente. Entienden Figma. Y Figma es un canvas plano que no sabe de accesibilidad, de performance, de cómo se comportan los componentes en la realidad del navegador.
He visto «diseños» que literalmente no se podían construir sin HTML personalizado. He visto tipografías que rompían con cada tamaño de pantalla. He visto paletas de colores que jamás llegaban a 4.5:1 de contraste.
¿Sabés qué? El desarrollador lo intentó. Llamó al diseñador. El diseñador dijo: «eso no es posible en Figma, así que no es posible».
Fin de la historia: va en producción tal cual y alguien con daltonismo no puede leer el sitio.
La métrica que nadie mide
Google pagó millones por marcar Core Web Vitals como factor de ranking. Lighthouse, Pagespeed, métricas objetivas. Todos las checamos.
¿Sabés cuántas agencias tienen un checkeo similar para accesibilidad? Casi ninguna. ¿Screenreader testing? Cinco de cada cien. ¿Testing con usuarios reales con discapacidad? Probablemente cero.
Porque no hay negocio en medir algo que no se cobra. No hay OKR. No hay presión. Y si algo no tiene presión, en un equipo ocupado simplemente… desaparece.
Es como decir: «bueno, la seguridad es importante, pero como no hay presión vendemos sin HTTPS». Nos sonaría retrasados. Pero con accesibilidad la normalizamos.
La excusa que escucho más: «nuestros usuarios no necesitan eso»
Cariño, sí necesitan. Incluso si no tienes un usuario ciego ahora, lo tendrás mañana. Y si no, tu madre envejece y a los 70 tu vista baja un montón. De repente tu sitio que tiene textos de 12px sobre fondo gris es el infierno.
Pero hay algo más insidioso: accesibilidad beneficia a todos, no solo a discapacitados.
- Subtítulos: el 85% de videos se ven en mute. Qué casualidad, los subtítulos también ayudan al sordo.
- Navegación clara: si tu sitio se navega por teclado perfecto, también funciona mejor en móvil.
- Alto contraste: ves mejor el sitio al sol. Y además, el sordo… bueno, no lo afecta, pero el usuario ocupado que mira rápido sí.
- Texto alternativo en imágenes: el SEO ama eso. Google también.
Entonces cuando dices «nuestros usuarios no necesitan accesibilidad», lo que dices es «prefiero pelear contra mis propios intereses». Porque accesibilidad es buena para SEO, para conversión, para todo.
El verdadero costo
¿Sabés cuál es el costo real? Legal.
WCAG 2.1 AA no es opcional en la UE. En España, la AEPD lo chequea. En Estados Unidos, los abogados especializados en ADA demandas están obteniendo sentencias por webs inaccesibles. El 2026 es el año en que eso se normalizó.
Así que cuando tu cliente dice «accesibilidad es extra», lo que está diciendo es: «quiero pagar una demanda más adelante».
¿La solución?
Sencillo: diseña accesible desde el primer boceto.
No es complicado. Es solo diferente.
- Contrasta bien (4.5:1 mínimo).
- Usa tipografía legible (16px es tu amigo).
- Espaciado. Mucho espaciado.
- Prueba tu diseño con usuarios reales.
- Entiende ARIA si vamos a interactividad.
- Navega tu propio sitio sin ratón.
¿Eso te hace mediano? No. Es llamado «profesionalidad».
¿Y si no lo haces?
Seguirá pasando lo que pasa: excluyes a millones de personas, das malas experiencias, enfrentas riesgos legales y además, tu sitio ranking peor en SEO.
Pero en el fondo sospecho que sabes esto. La pregunta es: ¿vas a hacer algo al respecto o vas a seguir justificando por qué tu diseño bonito es más importante que la capacidad de alguien de usarlo?