La accesibilidad afecta a casi todas las etapas de un proyecto. Esto suele explicarse diciendo que la accesibilidad es necesaria antes, durante y después de realizarlo. Es una forma elegante de ilustrar que la accesibilidad debe tenerse en cuenta en la fase de planificación, durante el desarrollo y como parte del Control de Calidad (QA) cuando el proyecto ya está en marcha.
Esta simplificación es útil para explicar que la accesibilidad no es solo una preocupación durante la implementación; pero como toda simplificación, es inexacta porque puede inducir a error. Aclaremos algunos de estos malentendidos.
La accesibilidad en la fase de planificación va más allá del diseño visual
Muchas directrices se aplican específicamente al diseño visual, como las que se engloban bajo el principio general de ser Perceptible. Pero incluso estas están estrechamente ligadas a la arquitectura de contenidos y a la redacción.
Para tener un sitio web fácil de entender, lo habitual es tener en cuenta la complejidad del texto mediante alguno de los modelos y fórmulas existentes (como las pruebas de legibilidad de Flesch-Kincaid, que se basan en la longitud de las palabras y las frases para asignar una puntuación entre 0 y 100, donde 100 corresponde a un texto fácil de leer y 10 o menos a un texto extremadamente difícil).
Esto también se aplica a la navegación. Una estructura con muchas categorías muy pobladas y varios niveles de subcategorías es más difícil de recorrer que una navegación sencilla de un solo nivel.
También se aplica a cualquier proceso, como el de compra. Es mejor pedir a los usuarios solo la información mínima necesaria para realizar una compra, y preguntar después si desean crear una cuenta con los datos facilitados, y no al contrario. Esto reduce la fricción, lo que favorece la conversión, pero facilitar las cosas también ayuda a los usuarios que, de otro modo, podrían sentirse abrumados.
Siempre merece la pena tener presente que los pasos que pedimos a los usuarios no tienen por qué coincidir con los pasos que tienen lugar en nuestra empresa. A menudo podemos simplificar el trabajo de los usuarios centrándome en lo que quieren conseguir y gestionando el resto internamente.
La accesibilidad durante el desarrollo va más allá del código
En la fase de implementación, las cosas empiezan a concretarse. En esta etapa es más fácil detectar cuando algo desentona. Además, por el mero hecho de estar en contexto, los componentes son más fáciles de analizar.
Si tenemos un elemento superpuesto (un botón), independientemente de dónde aparezca en pantalla, su orden de tabulación depende de su posición dentro del HTML. Si el botón activa un modal, este debe colocarse dentro del DOM de forma que su orden de navegación por teclado (comúnmente conocido como orden de tabulación) tenga sentido. O bien, si es un modal a pantalla completa, hay que deshabilitar temporalmente el resto de la navegación. Aunque hayamos diseñado el botón y el modal como un componente cohesionado, puede que sea necesario implementarlos en partes distintas del HTML para que la navegación por teclado funcione como se pretende.
Esto cobra mayor importancia cuando utilizamos un enfoque atómico del diseño, en el que los componentes se diseñan de forma aislada y pueden necesitar ajustes al aplicarse en distintos contextos. Estos ajustes pueden ser variaciones visuales o implementaciones de código completamente diferentes.
No es necesario que esto implique una comunicación constante entre diseñadores y desarrolladores (algo que siempre genera cierto recelo). Simplemente tener en cuenta la accesibilidad puede allanar el camino.
La accesibilidad tras el lanzamiento del proyecto va más allá del QA
Una vez en marcha, si todo se ha hecho correctamente, solo hay que estar atentos a los errores, ¿verdad? Ni mucho menos.
Uno de los principales factores de la accesibilidad es el contenido, ya que los proyectos digitales son sistemas vivos que cambian, crecen y se adaptan. Los textos cuidadosamente elaborados para desarrollar y lanzar el sitio convivirán pronto con contenido nuevo o necesitarán una actualización cuando queden desactualizados. Y la accesibilidad del nuevo contenido requiere la misma atención que el contenido original.
El contenido nuevo mantiene un proyecto al día, pero también es un riesgo. El contenido continuo para el blog y la presencia en redes sociales de una empresa es, al mismo tiempo, una forma de crecer de manera orgánica y un pozo sin fondo de entropía. El nuevo contenido aporta nuevas perspectivas, pero también nuevos problemas. Algo tan sencillo como la necesidad de recontextualizar contenido antiguo cuando se incorpora contenido nuevo puede resultar una carga si no somos metódicos.
Por ejemplo, si queremos ampliar nuestra audiencia creando contenido informativo o educativo sobre temas técnicos o académicos complejos, debemos encontrar la manera de incluirlo junto al contenido más preciso y técnico de forma que no colisione ni entre en conflicto con la voz y el tono utilizados en cada uno de ellos. Si utilizamos contenido llano y accesible solo en una parte del proyecto, el resto resultará más confuso o, en el peor de los casos, disonante para los usuarios.
Cada nuevo contenido debe ser coherente con su contexto, tanto en fondo como en tono, y también en su implementación. Una imagen que resume a la perfección un tema complejo puede ser adecuada para ciertas plataformas. Pero es necesario adaptarla a un elemento textual o interactivo, según su contexto, para que tenga sentido para el usuario.
Conclusión
En el artículo La accesibilidad no es solo una buena experiencia de usuario, escribí sobre cómo la accesibilidad y la experiencia de usuario no pueden abordarse simplemente en la misma conversación. Esto no significa que la estrategia de experiencia de usuario y los esfuerzos en materia de accesibilidad deban estar reñidos. Necesitamos entender cómo se manifiesta la accesibilidad en cada aspecto de un proyecto para evitar el conflicto.
Esto se malinterpreta a veces como un escenario ideal, solo posible si la empresa va muy bien y quiere invertir algo de dinero en accesibilidad. La realidad es que esta es la forma eficiente de hacer accesibles los proyectos. Lo que hace que la remediación de accesibilidad resulte abrumadora es, por lo general, que está desconectada del proceso habitual. Ya sabemos cómo es la planificación, pero ¿qué ocurre cuando surge un problema fuera de nuestro plan original? Siempre lleva más tiempo y es más costoso, y suele arrojar peores resultados que la alternativa.
Fran Rosa. Desarrollador sénior, especialista en accesibilidad y defensor del desarrollo centrado en las personas