Algunas consideraciones sobre accesibilidad

Uno de los temas más interesantes e importantes que vemos en el curso que imparto en Fictizia es sobre accesibilidad web. Siempre intento transmitir la idea de que hay que entender el concepto como algo mucho más amplio y no reducirlo a “Hagamos nuestro site accesible para invidentes” (que suele ser la concepción más extendida), sino que debemos pensar en algo más global.

Desde mi punto de vista, tenemos el deber y la responsabilidad de construir productos digitales universales y accesibles (a los que se puedan acceder) para que puedan ser consumibles y por tanto útiles para las personas, intentando que ni su diseño ni sus funcionalidades supongan una barrera que impidan su uso.

NOTA: Si la idea de hacer el bien no te seduce o no es motivo suficiente para adoptar este enfoque, recuerda que un producto que no es útil con toda probabilidad no retornará valor al no poderse usar.

Ampliando el espectro

Lo primero es entender que existen muchos tipos de barreras que pueden impedir la utilización de un producto o servicio, y que pueden ser temporales o permanentes. Que pueden ser visuales, auditivas, motrices, cognitivas o tecnológicas (porque un site en el que no se ha trabajado la performance puede resultar inaccesible para dispositivos con menor capacidad de procesamiento o con una red móvil básica). Y en el peor de los casos puede ser una combinación de algunas de ellas. Como la casuística es muy amplia, siempre recomiendo echar un vistazo al proyecto Funkify y a su extensión para Chrome ya que ayuda a visibilizar otros perfiles que quizá no tenemos en mente.

Otras consideraciones

Los problemas con la accesibilidad suelen aparecer a medida que crece la complejidad de una interfaz. Es decir, la tecnología web es accesible por defecto pero nosotros (diseñadores y desarrolladores) la enreversamos hasta hacerla inaccesible. A veces es el resultado de una mala decisión en el marcado y otras es debido a que la funcionalidad que necesitamos construir no tiene equivalencia con un elemento nativo, y al tener que crearlo desde cero, tenemos que dotarle de ciertas capacidades y no lo hacemos; por falta de tiempo o de definición, porque no entra en el ámbito del proyecto, o porque el cliente no lo quiere ya que implica un aumento en el tiempo de desarrollo.

Y es que en la mayoría de los casos, la capa de accesibilidad se añade al final y casi siempre con caracter correctivo, es decir, que nos vemos en la necesidad de modificar nuestro código para que la interfaz sea interpretable para tecnologías asistivas.

Aunque en realidad no siempre será un coste extra, ya que una vez hayamos integrado estas buenas prácticas en nuestro día a día, cuidar la accesibilidad en nuestras interfaces no supondrá un esfuerzo extra.

Cómo y por dónde de empezar

Cuando tomamos conciencia y nos implicamos, descubrimos que hay un montón de siglas, reglas y conceptos nuevos que aprender y mucha documentación, lo que paradójicamente, hace más difícil encontrar el punto de entrada por el que empezar.

Por mi parte, siempre recomiendo lo mismo, hay que tomarlo con calma. Hay mucha información ahí fuera y el esfuerzo para integrarla es demasiado para hacerlo de golpe, así que lo mejor es avanzar paso a paso. Podemos poner el foco en algo concreto o en lo más básico y según lo vayamos entendiendo e integrando en nuestra forma de pensar y trabajar la nueva información y nos sintamos cómodos, podremos ir añadiendo una capa más de complejidad, de modo que cuando llevemos un tiempo con esta dinámica, podremos mirar atrás y ver un avance real y progresivo, nos saldrá de forma natural y nos sentiremos más satisfechos.

Como lo mejor es empezar por el principio, lo más adecuado sería revisar la documentación oficial de la WAI, WCAG y WAI-ARIA. Y ya que no es lo más fácil de digerir, desde aquí iremos destacando las partes más interesantes de estas especificaciones.