Hay una pregunta que aparece, con demasiada frecuencia, hacia el final de un proyecto: "¿Ya hemos revisado lo de la accesibilidad?". La redacción lo dice todo. "Lo de la accesibilidad" como si fuera un check en una lista de últimas horas, una formalidad de cumplimiento antes de salir a producción, algo que existe en paralelo al producto real.
Esa pregunta, y el momento en que se hace, es síntoma de un malentendido estructural que tiene consecuencias muy concretas: deuda técnica acumulada, rediseños costosos, flujos rotos para millones de usuarios y, en según qué sectores regulados, exposición legal. No es un problema de buena voluntad. Es un problema de modelo mental: la accesibilidad se trata como feature cuando en realidad es infraestructura.
Y la diferencia entre los dos no es semántica. Una feature puedes añadirla después. La infraestructura, si no está desde el principio, obliga a demoler para reconstruir.
La accesibilidad tratada como feature aparece al final, se audita una vez y se olvida en el siguiente sprint.
La accesibilidad como infraestructura se diseña en los tokens, los componentes y los criterios de aceptación desde el día uno.
El coste de retroadaptarla no es lineal: en sistemas complejos, se multiplica por cada capa que se ha construido encima.
El Problema: Por qué el Sector lleva Años Mal Enfocado
La historia estándar en los equipos de producto va así: hay un sprint de diseño, un sprint de desarrollo, testing, y en algún momento alguien recuerda que existe WCAG. Se pasa una herramienta automática de auditoría, se resuelven los errores más evidentes de contraste y alt text, y se cierra el ticket con un "accesibilidad: OK". Lo que esa herramienta automática no detecta, en el mejor de los casos, ronda el 70% de los problemas reales.
El origen del error es conceptual. Cuando los equipos hablan de accesibilidad, suelen pensar en discapacidades visuales graves —personas ciegas usando lectores de pantalla— como si fuera un nicho pequeño. Los números cuentan otra historia. Más del 15% de la población mundial vive con algún tipo de discapacidad según la OMS. Pero si amplías el foco a situaciones de uso —una mano ocupada, pantalla bajo el sol, conexión lenta, estrés cognitivo— el porcentaje de usuarios que se beneficia de un diseño accesible se acerca al 100%.
La accesibilidad bien entendida no es un caso extremo. Es el caso general.
Diseñar para la restricción no es diseñar para la excepción. Es diseñar mejor para todos.
El problema de fondo es que los equipos que sí quieren abordarla con seriedad no saben dónde encajarla organizativamente. ¿Es responsabilidad de diseño? ¿De desarrollo? ¿De QA? Esta ambigüedad de ownership hace que acabe siendo responsabilidad de nadie. Y cuando el ownership es difuso, la accesibilidad siempre pierde frente a la siguiente feature del roadmap.
Infraestructura: Lo que Cambia cuando Construyes desde Ahí
Llamar a la accesibilidad "capacidad operativa" —como hacen cada vez más equipos maduros— no es un eufemismo motivacional. Tiene implicaciones técnicas y organizativas muy concretas. Significa que la accesibilidad se gestiona como gestionas la seguridad, el rendimiento o la observabilidad: no como una historia de usuario que alguien escribe cuando toca, sino como una capa de calidad que el sistema tiene que mantener en cada release.
En el design system
Si tienes un design system —y si no lo tienes, eso merece otra conversación—, la accesibilidad tiene que vivir en los componentes base, no en las pantallas finales. Un botón con contraste correcto, estados de foco visibles y roles ARIA definidos desde el token level es accesibilidad que escala automáticamente a cada pantalla que lo usa. Un botón que se "arregla" en la pantalla de checkout no arregla nada: deja el problema latente en las otras 40 pantallas donde aparece ese mismo componente.
Esto conecta directamente con la madurez del design system. Los frameworks de evaluación de sistemas de diseño más rigurosos —el de Nielsen Norman Group incluye seis dimensiones— siempre distinguen entre sistemas que documentan accesibilidad y sistemas que la aplican. La documentación sin enforcement en los componentes es ruido. Lo que importa es si los criterios WCAG están codificados como constraints no negociables en el nivel de componente, no como recomendaciones en un Notion que nadie lee.
En los criterios de aceptación
La otra palanca crítica es quién define "terminado". Si los criterios de aceptación de una historia de usuario no incluyen checks de accesibilidad, el desarrollador que implemente esa historia no tiene obligación de contemplarlos. No es negligencia: es que el sistema de trabajo no lo pide. Añadir criterios como "el componente es navegable por teclado", "el ratio de contraste supera 4.5:1 en texto normal" o "los errores de formulario tienen descripción accesible" al nivel de Definition of Done cambia el comportamiento sin necesidad de campañas de concienciación. Los incentivos cambian la cultura más rápido que los talleres.
Equipos que han hecho este cambio —Shopify con Polaris, GOV.UK con su Design System— reportan una reducción drástica de los bugs de accesibilidad detectados en fases tardías. No porque el equipo sea más virtuoso, sino porque el problema se intercepta antes, cuando cuesta infinitamente menos resolverlo.
El Coste Real: Una Aritmética que Rara vez se Hace
Hay una razón por la que los equipos de negocio no priorizan la accesibilidad: nadie les ha presentado los números de forma honesta. Se habla de "lo correcto" y de "impacto social", que son argumentos válidos pero que no ganan debates de priorización contra una feature que promete conversión. Lo que sí gana esos debates es mostrar el coste de no hacerlo.
La regla general en ingeniería de software —popularizada por el concepto de "coste de la deuda técnica"— establece que corregir un bug en producción cuesta entre 10 y 100 veces más que detectarlo en diseño. Con la accesibilidad la escala es, si acaso, peor: un flujo crítico inaccesible que se detecta seis meses después de salir puede implicar rediseñar el sistema de navegación, migrar tokens de color en todo el sistema, revisar la jerarquía semántica del HTML y retestear cada pantalla afectada.
En sectores regulados —banca, salud, administración pública— el coste legal añade otra dimensión. La European Accessibility Act entró en vigor con obligaciones concretas para el sector privado en junio de 2025. Las empresas que no hayan incorporado la accesibilidad como proceso van a encontrarse haciendo auditorías de emergencia y retrofits costosos en lugar de haber construido bien desde el principio.
El argumento de negocio para la accesibilidad no es altruismo. Es no pagar tres veces por el mismo problema.
Hay también un coste de oportunidad que se ignora sistemáticamente. Un producto inaccesible excluye usuarios activos con poder adquisitivo. Más del 22% de la población en edad laboral en Europa tiene algún tipo de discapacidad reconocida. Cuántos de esos usuarios están intentando usar tu producto hoy y abandonando por fricción evitable es una métrica que casi ningún equipo mide, porque para medirla primero tienes que admitir que el problema existe.
Cómo se Parece en la Práctica: Tres Cambios Quirúrgicos
Convertir la accesibilidad en infraestructura no requiere parar el roadmap ni un proyecto de transformación de dieciocho meses. Requiere tres cambios de proceso que, aplicados con consistencia, reposicionan completamente cómo el equipo gestiona la calidad.
El primero es el que ya hemos mencionado: accesibilidad en el Definition of Done. No como una nota al pie, sino como criterio bloqueante igual que lo es un test de regresión fallido. El segundo es la auditoría de componentes base, no de pantallas. Si tienes un sistema de componentes, prioriza que los diez o quince más utilizados —botón, input, modal, navegación, formulario de error— pasen una auditoría real con lector de pantalla, no solo una herramienta automática. El impacto en superficie es desproporcionado al esfuerzo.
El tercero, y quizás el más subestimado, es incluir usuarios reales con discapacidad en los procesos de investigación. No en una sesión puntual para "el sprint de accesibilidad", sino de forma recurrente. La investigación de usuario bien hecha —la que no se convierte en entregable muerto sino en decisión viva— tiene que incluir la diversidad real de quién usa el producto. Sin eso, estás diseñando para un usuario imaginario que navega siempre con las dos manos libres, pantalla en perfectas condiciones y sin estrés cognitivo. Ese usuario no existe.
Estos tres cambios no son el techo. Son el suelo. A partir de ahí, la accesibilidad empieza a comportarse como lo que es: una propiedad del sistema, no una historia de usuario pendiente.
Si tu equipo está en el momento de construir o refactorizar un design system, o si la accesibilidad lleva meses apareciendo como deuda en los retrospectivos sin que nadie sepa cómo atacarla, es el tipo de conversación que tenemos habitualmente en Room 714. No para hacer una auditoría de checklist, sino para entender dónde está la palanca de mayor impacto y cómo integrarla sin parar lo que ya funciona. El error más frecuente no es no querer mejorar, es optimizar lo que no mueve la aguja mientras la infraestructura real sigue agrietada.
