La evolución de la accesibilidad web en la última década

Los que me conocen saben que vivo en una batalla continua por conseguir que las webs sean más accesibles, por convencimiento, pero también por egoísmo, como persona ciega. Desde la enseñanza, el humor y un poco de sana ironía, intento que la gente entienda la importancia de construir productos inclusivos para todo el mundo, sin centrarnos solo en la discapacidad.

En los días malos (últimamente tengo unos cuantos, debe ser por la edad), se apodera de mi alter ego pesimista y pienso que, en este camino que la web está recorriendo, la accesibilidad se nos descarrila muy a menudo, y cuesta mucho (incluso mediante leyes) volver a encarrilarla. Son esos días en los que solo gritas: ¡fuego, destrucción! y cada imagen sin texto alternativo o cada etiqueta sin semántica aderezada con JavaScript, refuerza ese estado de ánimo pesimista.

Pero, ¿es esto realmente así o, poniendo las cosas en perspectiva, la accesibilidad goza de mejor salud que hace algunos años? Vamos a poner esto un poco en contexto.

La evolución de la web

En muchos aspectos, 2014 fue un año de transición. Veníamos de webs en las que lo más normal era pulsar un botón o un enlace que hacían que la página se recargase completamente, lo cual era lento, pero permitía que los lectores de pantalla detectasen los cambios sin dificultad. Aunque ya no eran «las webs de los noventa», aún se utilizaban mayoritariamente controles nativos, lo que facilitaba las cosas a las ayudas técnicas (a pesar de JQuery y otros frameworks JS, que ya llevaban unos años dando vueltas por ahí, haciendo de las suyas con las animaciones y los cambios dinámicos). Sin embargo, la transición hacia una web con aspecto y funcionalidad similar a la de una aplicación de escritorio y la necesidad de adaptarla a dispositivos móviles aceleraron una serie de cambios que pondrían patas arriba la accesibilidad, sobre todo para lectores de pantalla.

Las cosas estaban cambiando de forma rápida. Frameworks como Angular.JS estaban tomando cada vez más protagonismo, permitiendo la aparición por doquier de portales SPA. De repente nos encontrábamos con que, al pulsar un enlace en una web, nuestro lector de pantalla se quedaba igual, como si ese enlace estuviera roto, porque los lectores de pantalla, si no se les ayuda, no saben cómo interpretar los cambios parciales. Junto con las SPA, aparecieron numerosos controles no nativos (aquellos que no se pueden expresar directamente como una etiqueta HTML), y que también contribuyeron con su dosis de caos al panorama: acordeones, menús desplegables, diálogos modales y popovers, por poner algunos ejemplos. Esto volvió las cosas un poco más complicadas (y aún siguen siéndolo hoy en día), pero no por la falta de soluciones técnicas (que las había casi desde el principio), sino por la falta de conocimiento y de implementación por parte de los desarrolladores web.

Afortunadamente, como decía, las soluciones técnicas estaban ahí. En 2014, la W3C publicó como recomendación la primera versión de un conjunto de especificaciones llamado ARIA (Accessible Rich Internet Applications), que permitió enriquecer las aplicaciones web, dotándolas de la información necesaria para que las tecnologías de asistencia entendiesen profundamente el funcionamiento de cada uno de sus elementos, y a responder adecuadamente a sus cambios de estado. De hecho, durante estos diez años, ARIA también ha ido evolucionando a la par que la tecnología, siendo la versión 1.2 la última recomendación publicada por la W3C en 2023, y en 2024, la versión 1.3 como borrador de trabajo.

A lo largo de los años, el estándar HTML también ha ido evolucionando, proporcionando a los desarrolladores los ladrillos fundamentales para crear webs más accesibles y semánticas. Se han añadido etiquetas para definir la estructura de una web (lo que hace que las ayudas técnicas puedan percibirla sin dificultad), y se han introducido nuevas etiquetas para renderizar controles que hasta ahora solo podían existir haciendo un uso casi obsceno de JavaScript (y, por tanto, de ARIA para ser accesibles). Por ejemplo, la etiqueta <dialog> es uno de ellos, permitiendo crear modales de forma realmente simple, en lugar de tener que usar librerías JS para simularlos desde cero.

Frameworks como React, Vue, Angular 2 y Svelte se han consolidado como líderes en el desarrollo de aplicaciones web, ofreciendo como reclamo fundamental su capacidad para crear interfaces altamente interactivas y permitir las actualizaciones parciales de forma casi instantánea. Pero otra vez, la accesibilidad ha sido la más perjudicada, ya que transmitir todo esto de forma efectiva a lectores de pantalla requiere de un trabajo adicional por parte de los desarrolladores, quienes deben ser capaces de entender e implementar ARIA de forma correcta. Y ya os digo yo que implementar ARIA de forma correcta en aplicaciones web cada vez más interactivas y complejas tiene su miga.

El papel fundamental de las librerías de componentes

Todos los frameworks JS modernos tienen algo en común: el uso de componentes. Los componentes son fragmentos de una aplicación que se pueden reutilizar y personalizar bajo diferentes situaciones. Por ejemplo, podríamos crear un componente que pinte un acordeón con las opciones que queramos, otro que pinte un cuadro de edición con un tooltip u otro que pinte un menú horizontal que, en un móvil, se convierte mágicamente en un menú desplegable para ocupar menos espacio. Como casi todas las aplicaciones utilizan componentes comunes, aparecieron, de forma natural, las librerías de componentes. Estas librerías son un conjunto de componentes empaquetados, altamente personalizables y listos para usar sin demasiado esfuerzo.

Esto, como podréis imaginar, facilita muchísimo la creación de una aplicación, ya que un desarrollador no tiene que escribir sus componentes desde cero, sino que solo tiene que utilizar los componentes que ya existen en sus librerías. Así que, si una librería es ampliamente utilizada por muchos desarrolladores e implementa una buena accesibilidad por defecto, las aplicaciones que la utilicen van a ser mucho más accesibles sin demasiado trabajo extra para los desarrolladores. ¡Magia! Pero también puede ocurrir el caso contrario: que una librería ampliamente utilizada no implemente accesibilidad por defecto, lo que dificulta muchísimo que las aplicaciones que la utilicen sean accesibles.

Afortunadamente, gran parte de las librerías de componentes más utilizadas implementan en mayor o menor medida características de accesibilidad (a veces liándola parda, todo hay que decirlo), así que en los últimos años hemos visto cómo muchas aplicaciones han mejorado en accesibilidad, sin que en muchos casos sus propios desarrolladores sean conscientes de ello. Qué maravilla esto de la reutilización 😉.

Lo bueno es que muchas librerías son open source, así que siempre podemos hacerles una pull request para mejorar, de golpe, miles de portales. ¡Reutilización otra vez!

Entonces, ¿en qué quedamos? ¿Somos más accesibles que hace diez años?

La respuesta, a pesar de esos días malos de los que os hablaba al principio de este artículo, es un rotundo sí. Hemos mejorado mucho en algunas cosas, aunque aún queda un largo camino por recorrer.

Una conciencia creciente

Creo que hace diez años la accesibilidad web era una preocupación solo para un pequeño grupo de desarrolladores que conocíamos de cerca las barreras que una web no accesible podía generar, y eso nos hizo estar mucho más comprometidos con su implementación. Hoy en día, la sociedad está cambiando, al menos en gran parte del mundo, y creo que está más comprometida con los valores de diversidad, equidad e inclusión. Esto, poco a poco, se está reflejando en el mundo del desarrollo, donde cada vez más personas buscan recursos para formarse en accesibilidad, y se comprometen a tener en cuenta la accesibilidad en sus proyectos.

La ley y las multas también ayudan

En España, desde 2007, hemos tenido una ley bastante clara en lo referente a accesibilidad web, tanto del sector público como de empresas privadas de gran trascendencia. Si bien es cierto que su aplicación hasta ahora ha sido realmente limitada (por no decir penosa), en otros países como los EE. UU. han tenido más mano dura a la hora de aplicar sus propias leyes. Debido a la globalización en el mundo digital, esto ha generado un efecto apreciable en el resto del planeta, sobre todo en grandes multinacionales.

Pero aunque hasta ahora los EE. UU. han estado a la cabeza de los cambios positivos en accesibilidad debido a su legislación, a partir del año que viene, en Europa también viviremos un punto de inflexión hacia portales más accesibles, con la entrada en vigor de la European Accessibility Act, una ley que será de aplicación en todos los países miembros, y que exigirá, a partir de 2025, que todo contenido nuevo, tanto del sector público como del sector privado de gran trascendencia cumpla con la norma UNE-EN 301 549, que además de algunos puntos adicionales, supone cumplir con las WCAG 2.1 en su nivel AA. Podéis imaginarme ahora saltando de alegría y diciendo: ¡ya era hora, maldita sea, ya era hora!

Así como en España la ley no se ha aplicado, tengo la esperanza de que, al ser esta una ley europea, España no pueda hacerse la sueca y dejar pasar las denuncias como ha ido haciendo hasta ahora. Ojalá que el tiempo me dé la razón.

El compromiso de las grandes empresas

En los últimos años, compañías como Microsoft, Google y Apple, empresas que comercializan numerosos productos digitales usados de forma masiva por todo el mundo, se han comprometido realmente con la accesibilidad en sus desarrollos, y han implementado protocolos que garantizan que dichos productos sigan manteniendo un buen nivel de accesibilidad a lo largo del tiempo.

Más allá del impacto positivo de que sus propios productos sean accesibles, esto también ha influido positivamente en la accesibilidad de productos de terceros. Por ejemplo, con la inclusión de herramientas de comprobación de accesibilidad en Chrome y Edge, Google y Microsoft han transmitido un mensaje claro sobre la importancia de la accesibilidad, lo que ha hecho que otros desarrolladores se fijen en ella, y se planteen aplicarla en sus propios proyectos.

El desarrollo accesible en la actualidad

La tecnología ha evolucionado significativamente en los últimos diez años, pero con ella también lo han hecho las capacidades para garantizar su accesibilidad. Hoy en día, las herramientas, estándares y frameworks disponibles permiten que las aplicaciones puedan ser totalmente accesibles. El uso de ARIA, de librerías accesibles de componentes, y sobre todo de un buen uso del estándar HTML, permiten que las aplicaciones actuales, a pesar de su complejidad, puedan ser totalmente accesibles.

Sin embargo, esto solo es posible si los desarrolladores cuentan con los conocimientos necesarios, y aplican buenas prácticas de forma consciente en sus proyectos. La accesibilidad, más que una barrera técnica, sigue siendo un desafío de formación y compromiso.

La accesibilidad y la fragmentación

A pesar de que iniciativas como ARIA han evolucionado y en teoría cubren la mayor parte de las necesidades de las aplicaciones web actuales, es cierto que en la práctica existen bastantes problemas con la heterogeneidad de su implementación. Así, hay navegadores que implementan especificaciones de ARIA de maneras sutilmente diferentes, o que ofrecen más o menos compatibilidad con algunos atributos o incluso con la implementación de accesibilidad de controles HTML nativos. Además, los lectores de pantalla tampoco soportan toda la especificación de ARIA de la misma manera, o incluso puede haber diferencias en función del sistema operativo en el que se ejecuten. Así, una misma aplicación web puede tener mayor o menor accesibilidad en función de la combinación de navegador, lector de pantalla y sistema operativo, lo que, desgraciadamente, recuerda a aquella época en la que se tenían que incluir parches en las webs para que una funcionalidad fuese compatible en el mayor número de navegadores posible.

Afortunadamente, esto está cambiando poco a poco y las implementaciones de ARIA se están consolidando para alinearse con las especificaciones (la mejora en la documentación de las nuevas versiones de ARIA también está ayudando en esto). Así mismo, la implementación de los últimos controles HTML también está equiparándose en los distintos navegadores y la experiencia de accesibilidad cada vez tiene menos diferencias. Sin embargo, aún necesitamos que todos los actores implicados sigan trabajando juntos para eliminar del todo esa heterogeneidad, y conseguir que, si una aplicación es accesible, lo sea en igualdad de condiciones sin importar el lector de pantalla, el sistema operativo o el navegador en el que se ejecute.

La formación, la raíz de los problemas de accesibilidad

Personalmente, creo que el problema de raíz con la falta de accesibilidad es la falta de formación de los desarrolladores. En mi experiencia como consultor de accesibilidad, he llegado a una conclusión muy triste pero no menos cierta: la mayor parte de los desarrolladores web casi no saben HTML. Es como si un albañil no entendiera la importancia de los cimientos al construir una casa. Puede colocar ladrillos de cualquier forma, rellenando huecos con lo que tenga a mano, pero, aunque el resultado pueda parecer sólido a simple vista, tarde o temprano, esas deficiencias estructurales acabarán causando problemas. Del mismo modo, en la web, un HTML mal construido genera barreras que quizá no se aprecian a simple vista, pero que impactan directamente en quienes dependen de la accesibilidad para navegar o interactuar con ella.

Así mismo, hoy en día casi no existe formación en accesibilidad como parte de los itinerarios formativos de bootcamps, ciclos formativos o universidades, y esta es la segunda parte del problema. Es imperativo que la accesibilidad se estudie, pero no como una asignatura adicional, un parche a aplicar cuando sea necesario, sino como parte indivisible del desarrollo web, al igual que hacemos con las buenas prácticas de codificación, los patrones de diseño o las pruebas unitarias. Hasta entonces, la accesibilidad se percibirá como un añadido, y no como la única forma de desarrollar correctamente.

¿Qué nos traerá la accesibilidad en los próximos años?

La tecnología va a continuar evolucionando y las capacidades de accesibilidad tendrán que hacerlo a la par para no quedarse atrás. Con el marco legislativo actual, creo que la accesibilidad va a continuar mejorando a pasos agigantados, y no solo porque se tendrá mucho más en cuenta, sino por la intervención de la inteligencia artificial.

Sí, lo sé, ahora parece que todo tiene que llevar inteligencia artificial y, si no, ya no mola, pero estoy convencido de que va a tener un papel importantísimo en la accesibilidad.

Sin ir más lejos, en este último año, los lectores de pantalla han incorporado descripción de interfaces utilizando Chat GPT. Por ejemplo, si en una web me encuentro un botón sin etiquetar, puedo pedirle a mi lector de pantalla que le envíe la representación gráfica de ese botón a GPT y este me devolverá un texto explicándome no solo qué es lo que aparece visualmente, sino incluso una explicación de su significado en el contexto de la pantalla en la que se encuentra. Ahora imaginad que pudiésemos integrar esto en un complemento de navegador que utilice la IA para etiquetar al vuelo todos los elementos no etiquetados de una interfaz, y que basándose en la estructura visual de la página sea capaz de añadir en tiempo real todas aquellas secciones HTML que los humanos hemos omitido. Lo mismo podría ocurrir con las etiquetas de los campos de formulario, la inclusión de atributos para indicar la obligatoriedad de esos campos en función del color, etc.

Creo que todo esto no tardará en llegar, y mejorará sustancialmente nuestra experiencia con aquellos productos que no han sido desarrollados pensando en su accesibilidad. Por supuesto, el uso de la IA para arreglar lo que nosotros hemos roto no debería ser la norma, sino el último recurso para que, a pesar de no haberlo hecho bien, los productos puedan, aun así, ser inclusivos.

También podremos aplicar todo esto a las herramientas de testing de accesibilidad, que hoy en día solo se basan en el HTML y el CSS generado para determinar si una web es accesible. Este tipo de herramientas es capaz de capturar como mucho el 40 % de los errores, pero con la ayuda de la IA, este porcentaje va a aumentar significativamente.

Conclusión

La accesibilidad web ha mejorado en los últimos diez años, pero aún nos queda mucho camino por recorrer. A pesar de los retos técnicos, legales y formativos, hemos visto un progreso significativo en la conciencia y en las herramientas disponibles. La accesibilidad ya no es la preocupación de unos pocos, sino una forma de pensar y de empatizar que está empezando a calar en la cultura del desarrollo y en el ADN de muchas empresas.

A pesar de los progresos, la fragmentación en la implementación de estándares, la falta de formación y el desconocimiento siguen siendo barreras realmente importantes. Es imperativo que sigamos trabajando para hacer de la accesibilidad un pilar fundamental del desarrollo web, no un parche que aplicamos a posteriori, cuando no queda más remedio.

¿Que si estamos en el buen camino? Sin duda. Habrá revueltas, retrocesos, pero también atajos y al final lo lograremos. A pesar de «los días malos», estoy convencido de ello.

Cita recomendada: MONTIEL, Juanjo. La evolución de la accesibilidad web en la última década. Mosaic [en línea], enero 2023, no. 202. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n202.2412