Mitos y realidades de la accesibilidad

Si trabajas en accesibilidad, oirás las mismas objeciones una y otra vez. Algunas nacen del desconocimiento y otras del interés de quien vende atajos. En esta lección las recogemos con su respuesta, para que puedas responder con argumentos y no con buenas intenciones.

«La accesibilidad es cara»

Es el mito más extendido y tiene una parte de verdad: corregir la accesibilidad de un producto ya terminado sí es caro, porque obliga a tocar plantillas, componentes, contenidos y, a veces, decisiones de diseño. Pero construir accesible desde el inicio tiene un coste marginal pequeño. Elegir un <button> en lugar de un <div> no cuesta más; escribir un texto alternativo cuesta segundos; definir una paleta con contraste suficiente se hace una vez en la guía de estilo.

Es el mismo principio que en seguridad o en calidad: cuanto más tarde se detecta un defecto, más caro es arreglarlo. Por eso en los niveles avanzados de este programa insistiremos en el enfoque shift-left: llevar la accesibilidad a los requisitos y al diseño.

«Una web accesible es fea o aburrida»

Nada en las WCAG limita la creatividad visual. Exigen contraste suficiente, texto redimensionable, foco visible y alternativas para el contenido no textual. Con esas condiciones se puede diseñar cualquier estética. De hecho, muchas de las tendencias recientes (tipografías grandes, mucho espacio en blanco, animaciones sutiles que respetan la preferencia de movimiento reducido) son perfectamente compatibles con la accesibilidad.

Lo que sí ocurre es que algunos recursos de moda chocan con ella: texto gris claro sobre fondo blanco, enlaces que solo se distinguen por un color tenue, carruseles automáticos o botones e iconos diminutos. Pero eso no es una limitación de la accesibilidad, sino un problema de legibilidad que afecta a todo el mundo.

«Solo es para personas ciegas»

Las personas ciegas son el colectivo más visible, porque el lector de pantalla hace evidentes los fallos. Pero son una minoría dentro de la discapacidad visual (la baja visión es mucho más frecuente) y la discapacidad visual es solo una parte del conjunto. En el siguiente curso verás los perfiles con detalle: personas con baja visión, con daltonismo, sordas, con discapacidad motriz, con discapacidad cognitiva o intelectual, neurodivergentes y mayores. A ellas se suman las situaciones temporales y situacionales que ya vimos.

«Lo arregla un overlay»

Un overlay es un script de terceros que se añade a la web y muestra un botón flotante con opciones como aumentar el texto, cambiar el contraste o leer en voz alta. Algunos proveedores afirman que con una línea de código la web pasa a cumplir las WCAG o la ley. Esa afirmación es falsa, y conviene saber por qué:

• Un overlay no puede escribir el texto alternativo correcto de una imagen que no lo tiene; como mucho, lo adivina con inteligencia artificial, con resultados a menudo erróneos.
• No puede reparar un orden de foco incorrecto, un diálogo modal mal construido o un formulario sin etiquetas: son problemas del código original.
• Las funciones que ofrece (zoom, contraste, lectura en voz alta) ya las tienen el navegador, el sistema operativo y las tecnologías de apoyo del usuario, generalmente mejor configuradas.
• Puede interferir con el lector de pantalla o con los atajos del usuario, empeorando la experiencia.

Esto no quiere decir que una capa de ajustes de usuario sea mala en sí misma: una barra de preferencias bien hecha puede ser útil como complemento. El problema es presentarla como sustituto de la accesibilidad del código. Ni las WCAG ni el RD 1112/2018 (PDF, se abre en una ventana nueva) ni la Ley 11/2023 (PDF, se abre en una ventana nueva) contemplan los overlays como vía de cumplimiento; la conformidad se evalúa sobre el contenido real.

«Ya cumplimos: pasamos la herramienta automática»

Las herramientas automáticas (axe, WAVE, Lighthouse) son muy útiles y las verás en el nivel de auditoría, pero solo detectan una parte de los problemas: una estimación habitual habla de entre un 30 % y un 40 % de los criterios, aunque la cifra varía según cómo se cuente. Pueden comprobar que una imagen tiene atributo alt, pero no si ese texto describe bien la imagen. Pueden medir el contraste de un texto, pero no si un vídeo tiene subtítulos correctos. Un informe automático «sin errores» significa que no hay errores de los que la herramienta sabe buscar, nada más. En la última lección de texto de este curso aprenderás a completar esa información con una primera revisión manual.

«Nuestros usuarios no tienen discapacidad»

Esta afirmación suele basarse en que nadie se ha quejado. Pero las personas que no pueden usar una web no suelen quejarse: se van. Y como no completan el proceso, no aparecen en las analíticas de conversión. Además, las tecnologías de apoyo, por lo general, no se identifican ante el servidor (ni deberían, por privacidad), así que no hay forma fiable de contarlas. La ausencia de quejas no es evidencia de ausencia de barreras.

«Es cosa de los desarrolladores»

Los desarrolladores tienen una parte importante, pero muchos problemas de accesibilidad nacen antes: en el diseño (contraste, tamaño, foco), en los contenidos (textos alternativos, lenguaje, estructura), en la gestión (plazos, compras de componentes inaccesibles) y en la edición diaria (un PDF escaneado subido a la web). Por eso este programa se dirige a todos los perfiles: la accesibilidad es una responsabilidad compartida. En la lección siguiente concretamos qué le toca a cada uno.

Resumen

• Construir accesible desde el inicio es barato; corregir después es lo caro.
• Las WCAG no limitan la estética: exigen legibilidad, operabilidad y alternativas.
• La accesibilidad afecta a muchos perfiles, no solo a personas ciegas.
• Un overlay no corrige el código ni sirve como prueba de conformidad.
• Las herramientas automáticas detectan solo una parte de los problemas y la ausencia de quejas no demuestra nada.