El 70% de los sitios web siguen fallando los controles básicos de contraste en 2025. No es una cifra de hace diez años. Es ahora, después de años de design systems, linters de accesibilidad y librerías de componentes supuestamente "seguros". La conclusión es incómoda: no fallamos por falta de herramientas. Fallamos porque la accesibilidad nunca entra en el roadmap como requisito real.
Y no es un problema técnico. Es un problema de prioridades.
- La accesibilidad se trata como deuda técnica que "ya arreglaremos" en lugar de como una condición de salida del sprint.
- Los iconos, el contraste y las etiquetas ARIA se ignoran hasta que llega una auditoría legal o un cliente con necesidades especiales que no puede usar el producto.
Diseño: Cuando lo "Invisible" Rompe la Experiencia
Hay una trampa cognitiva en los equipos de producto: si algo funciona para la mayoría, se considera terminado. Los iconos SVG se renderizan bien en pantalla, las etiquetas de color parecen claras, los flujos se completan sin rozadura. Entonces llega alguien que usa un lector de pantalla, o con baja visión, o que navega solo con teclado, y el producto se convierte en una sala oscura sin señalización.
La paradoja es que muchos de estos problemas son de los más baratos de resolver si se atacan en el momento correcto: en diseño, antes de que el código exista. Un icono decorativo sin aria-hidden, un texto sobre un fondo con contraste insuficiente, un estado de foco que desapareció porque "quedaba feo" — cada uno de esos detalles es minutos de fricción para miles de usuarios reales. Como señalamos al hablar del ROI de UX, el coste de ignorar estas decisiones no aparece en el dashboard de producto hasta que ya es tarde para actuar sin dolor.
La accesibilidad no es un sprint especial. Es la señal más honesta de que un equipo entiende para quién diseña de verdad.
Estrategia: Entrar en el Roadmap o No Existir
El problema de fondo es de gobernanza, no de talento. Los equipos que tienen buenas intenciones con la accesibilidad la relegan al final del ciclo porque no hay nadie que la defienda con métricas en la conversación de planificación. Y al final del ciclo, siempre hay algo más urgente.
La solución no es contratar a un especialista en WCAG para que revise todo lo ya construido — aunque a veces toca. La solución es convertir los criterios de accesibilidad en criterios de aceptación desde el diseño: contraste mínimo, roles semánticos, estados de interacción visibles. Si no pasa esa lista, la historia no está terminada. Punto.
Esto conecta directamente con cómo se estructura la investigación de usuario: si tus sesiones de usabilidad no incluyen participantes con necesidades diversas, estás midiendo solo una fracción del comportamiento real. El prototipo puede parecer brillante en tu sala de reuniones y ser completamente opaco para el 15-20% de usuarios que tienen algún tipo de discapacidad.
En Room 714 auditamos productos donde la accesibilidad lleva meses "en el backlog". Lo que encontramos casi siempre no es ignorancia — es un proceso de diseño que nunca incluyó las preguntas correctas desde el principio. Ahí es donde intervenimos.
