Por motivos que no viene al caso, desde hace un par de años o así, tengo la oportunidad de participar en acciones de formación en materia de accesibilidad digital.
Se trata de una formación bastante básica, que no me exige la profundización pero, a pesar de ello, esa actividad me ha llevado ya a leer varios libros y documentos en materia de accesibilidad.
Y justo por la superposición de una reciente lectura con una clase sobre accesibilidad, me surgió la reflexión que quisiera compartir en este post.
Accesibilidad digital
Antes de entrar en la reflexión, y para aquel posible lector o lectora poco conocedora del campo de la accesibilidad, un par de explicaciones poco académicas.
Siguiendo a la que probablemente sea la mayor autoridad española en esta materia, Olga Carreras, en su libro ‘Accesibilidad Web. WCAG 2.2. de forma sencilla‘ podríamos definir la accesibilidad (en este caso, ‘sólo’ accesibilidad web) como:
el conjunto de características que debe incorporar un sitio web, una aplicación móvil o un documento digital para que el mayor número posible de personas en el mayor número posible de circunstancias pueda acceder a él, usarlo y comprenderlo.
Para que lo entendamos: se trata, fundamental, aunque no únicamente, de luchar contra la discapacidad, de hacer que cualquier persona, aunque tenga condiciones que afecten a su capacidad visual, auditiva, motora o cognitiva, pueda navegar, entender y trabajar con un sitio web o una aplicación móvil (y eventualmente con documentos como los PDF que se puedan encontrar en esa web).
Para conseguirlo hay que hacer un diseño web que tenga en cuenta aspectos como los colores (por ejemplo que sean perceptibles y distinguibles por personas con daltonismo), el tamaño de letra, el contraste de colores en texto e imágenes, el tamaño de botones y así un largo etcétera.
Aparte de estos elementos de diseño, y para conseguir que personas con condiciones diferentes puedan ajustar el sitio web a su situación particular, se necesita poder configurar o seleccionar esos tamaños, juegos de colores, tiempos de respuesta, etc
Además, y como apoyo a las denominadas tecnologías de asistencia, muy especialmente lectores de pantalla (JAWS, NVDA, VoiceOver, etc), teclados adaptados, líneas braille, etc, es necesario incluir utilizar de forma muy rigurosa (respectando su semántica) las etiquetas HTML y añadir atributos con información que pueda ser utilizada por estas tecnologías, como el famoso texto alternativo (atributo ‘alt’) en imágenes.
Aún hay más, es necesario dar alternativas, digamos multimodales, a los contenidos: añadir subtítulos y, si es posible, lengua de signos a los vídeos para que puedan ser percibidos por personas con condiciones que afecten a su audición, añadir variantes tanto visuales como sonoras a cualquier aviso o alarma y así sucesivamente.
Un imperativo ético, a veces legal y con algún interés de negocio
Dotar a los sitios web de accesibilidad es, ante todo, un imperativo ético, porque contribuye a crear igualdad de oportunidades para todas las personas independientemente de su condición. Y en algún caso, como las administraciones públicas, puede ser también un imperativo legal.
Pero, además, para aquellas empresas (o ‘influencers‘) que compiten por la atención o para aquellas empresas que usen masivamente el marketing de atracción y el comercio electrónico puede tener beneficios de negocio al llegar a un público más amplio y facilitar la conversión (obtener pedidos, vaya).
Algunas dificultades objetivas de la accesibilidad digital
Sin embargo, hay que reconocer que, si lo miramos desde un punto de vista técnico y operativo, conseguir la plena accesibilidad de un sitio web no es una tarea ni sencilla ni ligera.
Dejando aparte la necesidad de disponer de diseñadores y desarrolladores de front-end formados en accesibilidad web, hay muchas otras dificultades o trabajos añadidos.
Hay que hacer trabajo adicional (por ejemplo añadir las etiquetas describiendo imágenes o añadir los subtítulos), hay que preparar al sitio web para que sea configurable, hay que añadir opciones multimodales que en otro caso podrían no ser necesarias, hay que añadir subtítulos y lengua de signos y así un largo etcétera. Lo que quiero decir es, eso, que hay trabajo adicional.
Además, hay que tener en cuenta muchísimos factores, porque las discapacidades y condiciones de las personas son muy variadass y llevan a necesidades diferentes que incluso pueden ser contradictorias.
Es muy aconsejable que las pruebas del sitio web se realicen, al menos en algunas fases, con personas con todo el abanico de condiciones sensoriales y cognitivas porque para una persona que no presente estas condiciones es muy difícil juzgar la experiencia que recibe una persona que sí las detente. Pero eso lleva a un equipo de pruebas no tan fácil de conseguir, no pequeño y a pruebas muy manuales, muy artesanales.
Y, por supuesto, hay que disponer de tecnologías de asistencia para probar con todas ellas.
En resumen, si somos realistas, hacer un sitio web accesible supone un equipo con cualificación especial, realizar trabajo adicional y que una parte de ese trabajo sea muy artesanal.
El ‘quid’ de la cuestión
El ‘quid’ de la cuestión, la clave de mi argumento y opinión es que, si aspiramos a que se generalice la accesibilidad digital, si queremos que todos los sitios web sean plenamente accesibles, tenemos que dar un gran salto de eficiencia, tenemos que aplicar tecnología y conceptos rigurosos de ingeniería software y de operación.
Un benchmarking con el ‘mainstream’ de ingeniería de software
Pero tenemos espejos donde mirarnos y muchas tecnologías y metodologías que nos pueden echar una mano.
Algunas son casi, la aplicación directa de técnicas usadas en otros ámbitos, fundamentalmente del software, y otras sería algo más específicas, aunque siempre inspiradas en lo que ya se hace o ya se dispone a nivel metodológico o técnico.
Un poco a bote pronto, propongo, y luego explicaré brevemente, siete vías, siete soluciones o buenas prácticas que creo que se podrían y deberían aplicar. Son las siguientes:
- Reutilización y componentes accesibles
- Low-code accesible
- Un ‘responsive’ para la accesibilidad
- Accesibilidad por diseño
- DevOps y automatización
- Aprovechar la multimodalidad de la IA
- LLMs entrenados en accesibilidad
Algunas de estas propuestas entiendo que ya existen y se aplican, aunque probablemente no de forma generalizada) pero alguna podría resultar novedosa. Paso a describir cada una muy brevemente.
Componentes accesibles
La reutilización de componentes forma parte del ABC de la ingeniería software, algo que se viene promoviendo y llevando a cabo desde hace décadas en el desarrollo de software.
Es una técnica básica de productividad, mantenibilidad y robustez de una arquitectura software. Y presenta otro beneficio y es que, en el caso de algoritmos o tecnologías complejas, un desarrollador muy especializado puede crear ese componente reutilizable, que luego puede ser empleado por desarrolladores con menos conocimientos. específicos.
Aparte de la mera productividad, la reutilización haría que si los componentes básicos son accesibles, los desarrolladores menos expertos podrían construir soluciones accesibles sólo mediante la reutilización de componentes accesibles.
Low-code / No-code accesible
Ya desde hace años existen soluciones denominadas ‘Low-code’ / ‘No-code’ que permiten construir software sin apenas conocer, o sin conocer en absoluto, un lenguaje de programación. El ‘truco’ es, básicamente, que la lógica se define de manera gráfica y que, además, se apoya en componentes y elementos ya predefinidos y de alto nivel (alto nivel en el sentido de ser fáciles de usar pero que implementan lógica compleja).
Por un lado, es una mecánica de desarrollo muy productiva y, por otro, un uso intensivo, consciente o no, de la reutilización que hemos visto en el punto anterior.
La idea sería que las herramientas Low-Code / No-code, muy especialmente las orientadas a front-end, como WebFlow o Bubble, o aquellas que crean interfaces de usuario como Glide o PowerApps, por ejemplo, ya generasen ‘de serie’, una interfaz accesible o, ‘lo más accesible posible’.
La verdad es que no he comprobado ni investigado si ya lo hacen o cuáles sí y cuáles no, pero no soy demasiado optimista. Ojalá me equivoque.
Un ‘responsive’ para la accesibilidad
Desde hace años, básicamente desde que se generalizó el uso de smartphones y tablets, existe el concepto del diseño ‘responsive’ (responsivo, en castellano)
Básicamente se tarta de adaptar el tamaño y distribución de los elementos de la interfaz de usuario al tamaño y orientación de la pantalla. Para eso, el código detecta el tipo de dispositivo en que se encuentra y reacciona presentando la interfaz de usuario adecuada.
Se me ocurre que, dado que la accesibilidad lleva a sitios web que se deben poder configurar para que el usuario elija las opciones que mejor le resultan, se podría pensar una forma de ‘responsive’ en que la interfaz de usuario se adapta a unos perfiles.
Podrían existir perfiles predefinidos para, por ejemplo, personas con daltonismo y la capacidad de definir perfiles personalizados.
La interfaz de usuario, además de averiguar el dispositivo, debería averiguar el perfil para para adaptarse.
¿Existe ya algo así? Es posible, pero no lo he oido mencionar.
El ciclo de vida y la accesibilidad por diseño
Existe un cierto patrón que podríamos denominar ‘metodológico’ que promueve que, aspectos concretos de una solución software se tengan en cuenta, no al final, en la fase de pruebas, sino en todo el ciclo de vida del desarrollo software, desde el diseño a las pruebas y puesta en producción pasando por el desarrollo.
Así, por ejemplo, en el ámbito de la ética de la inteligencia artificial, se habla de la ética por diseño o, de forma más específica, de la privacidad por diseño.
En el ámbito de la ciberseguridad, nos encontramos con la filosofía ‘shift-left‘ que va un poco en la misma línea, tener en cuenta los aspectos de seguridad en la parte ‘izquierda’ es decir, el principio) del ciclo de vida.
Pues bien, de una forma más metodológica que técnica, debería hacerse, no sé hasta qué punto se hace, en materia de accesibilidad y podríamos hablar, parafraseando el caso de la ética, de una ‘accesibilidad por diseño‘.
Automatización de pruebas de accesibilidad
Una gran dificultad son, como hemos dicho, las pruebas de accesibilidad, tanto porque hay que probar casuísticas muy diferentes como porque resulta aconsejable el concurso de personas con diferentes condiciones y discapacidades.
Algo en que se ha avanzado mucho en software es, precisamente, en la automatización de pruebas, un trabajo otrora tremendamente artesanal e intensivo en mano de obra.
Deberíamos de conseguir la automatización ‘extrema’ de las pruebas de accesibilidad disminuyendo al mínimo la manualidad.
Lo cierto es que existen ya herramientas de evaluación de accesibilidad (por decir una, WAVE, de WebAIM) pero, hasta donde percibo, son relativamente simples y creo que no evitan la necesidad de que sean complementadas por bastantes pruebas manuales.
Creo que harían falta tres cosas.
Por un lado, y suponiendo que yo esté en lo cierto, habría profundizar en las capacidades de las herramientas de prueba (que probasen más cosas).
Por otro lado creo (y a lo mejor esto ya está hecho, pero no me lo parece) habría que darles un, digamos, ‘formato’, que permitiese integrarlas más fácilmente en el ciclo del software. Por ejemplo, podría disponerse de ellas como librerías python, o como contenedores en entornos cloud o como conectores y/o APIs para entornos Low-Code. No sé, habría que ver la mejor solución (o conjunto de soluciones) pero creo que se entiende la idea.
El tercer punto, puede que sea el más difícil… o no: sería evitar al máximo posible la necesidad (o conveniencia) de emplear como ‘testers’ a personas con discapacidad. Aunque esto es una apuesta, creo que hay buena base para pensar que se podrían hacer usando inteligencia artificial generativa, sólo entrenando modelos de manera adecuada. Me apoyo para decirlo que ya existen modelos generativos que sirven para ‘simular’ expertos que prueben otros modelos.
Pues bien, se trataría de preparar a modelos, mediante el entrenamiento o ‘fine-tunning’ adecuado que actuasen como personas con diferentes condiciones sensoriales o cognitivas (probablemente aplicando luego una especie de ‘Mixture of experts‘). Es posible que crear estos modelos sea costoso, pero una vez hecho por ‘alguien’ (Google, ¿Qué te parece?) , podría usarse como una herramienta más.
Ya puestos, hasta podríamos pensar en agentes que comprobasen la accesibilidad, incluso de sitios ya en producción.
DevOps
Y, diría que por supuesto, habría que aplicar la filosofía DevOps, o mejor aún, integrar la accesibilidad como un aspecto más en los pipelines DevOps.
De la misma forma que, en el ámbito de la ciberseguridad se habla de DevSecOps, para una forma de DevOps que tiene en cuenta todos los aspectos de ciberseguridad, debemos hacer una DevAccOps que tenga en cuenta los elementos de la accesibilidad.
Y si hemos hecho los deberes anteriores, convirtiendo los elementos de accesibilidad en componentes estándar, y si hemos logrado automatizar las pruebas de accesibilidad, parece que el resto viene casi por añadidura.
Pero es fundamental: DevOps es, probablemente uno de los mayores saltos en productividad y eficiencia en ingeniería software. No deberíamos dejar la accesibilidad fuera de este marco.
Vibe coding para la accesibilidad
Y ahora que estamos en el ‘boom’, no solo de los agentes, sino también del código generado con inteligencia artificial, ahora que nos asombran Codex o Claude Code, que se usan cada vez más Lovable, Cursor o Windsurf, qué tal si entrenamos a los modelos que hay por detrás para que el código que generen en materia de interfaz de usuario sea accesible?
Aquí debo apuntar que, quizá, ya lo generen, la verdad es que no lo he podido investigar. Si ya generan interfaces de usuario accesibles, entonces sería fantástico que se usasen cada vez más y, si no es así, sería bueno que sus creadores tomasen nota y tuviesen en cuenta la accesibilidad a la hora de entrenarlos y probarlos
Unas palabras de prudencia y una invitación a la retroalimentación
Unas palabras de prudencia antes de ir concluyendo.
No he podido materialmente investigar hasta qué punto las soluciones y prácticas actuales utilizan las tecnologías, técnicas y metodologías que he propuesto.
Mi sensación es que, caso de que ya se haga, no es de manera generalizada… pero puedo estar equivocado.
En ese sentido, me encantaría recibir ‘feedback’ y comentarios.
La ética, la voluntad y la inteligencia
La accesibilidad digital, aunque, como he dicho, puede en algunos casos reportar beneficios económicos, es ante todo una aspiración y un deber de base ética.
Pero hablar de ética no debe llevarnos a pensar sólo en buenos deseos o aspiraciones, hablar de ética no debe suponer sólo acciones heroicas o buena voluntad.
Hace unas semanas en mi podcast ‘Divergencias‘ publicaba un episodio que titulaba ‘Caridad e inteligencia‘ que, en esencia, venía a defender el uso de la inteligencia en el ámbito de la caridad, en forma de criterios prácticos orientados a los resultados, la eficiencia y la escalabilidad.
La idea es la misma para el caso de la accesibilidad.
Soy ingeniero y enormemente orgulloso de serlo. Ingeniería es tecnología sí, pero es también resultados, eficacia y eficiencia.
Y creo que en el caso de la accesibilidad, aunque nuestra inspiración sea ética, debemos de actuar como ingenieros y aplicar las tecnologías, metodologías y buenas prácticas que nos lleven a resultados masivos, escalables y eficientes.
Creo que la única manera de conseguir que la accesibilidad sea una realidad, una realidad generalizada, es que sepamos dar el salto de la ética a la ingeniería, que optimicemos y automaticemos, que logremos ser eficaces y, sobre todo, eficientes.
Conclusiones
La accesibilidad digital es una aspiración de base ética en algunos casos reforzada por elementos legales. Pero, por desgracia, estamos lejos, probablemente muy lejos, de conseguir que esté generalizada.
Y me parece, estoy convencido en realidad, de que si queremos que se generalice es preciso ser realistas y prácticos, es preciso simplificar y automatizar, es preciso ser baratos, es preciso aplicar las mejores tecnologías y las mejores prácticas para conseguir ser eficaces y eficientes y conseguir así que el construir sitio web o una solución digital accesible sea rápido y barato.
