🥇Hacia la accesibilidad

Viernes: el final de la jornada laboral. Las malas noticias siempre llegan el viernes al final del día laboral.

Estás a punto de salir de la oficina, un 'ding' indica que ha llegado un nuevo correo sobre otra reestructuración.

Gracias xxxx, a partir de hoy, reportarás a zzzz.
…
Y el equipo de Hugh garantizará la accesibilidad de nuestros productos para personas con discapacidad.

¡Oh, no! ¿Por qué merezco esto? ¿Quieren que me vaya? Prepararse para un trabajo ingrato y difícil y tratar de corregir los errores de otras personas. Esto seguramente será un fracaso...

Así era la accesibilidad hace algunos años. Algunos desafortunados recibían trabajos de 'limpieza' de la interfaz de usuario para intentar hacerla accesible para personas con discapacidad.

Lo que esto realmente significaba era bastante difuso: probablemente, si podías ver el indicador de enfoque y navegar por los campos usando la tecla tab, tener algún texto alternativo y un par de descripciones para los campos, eso se consideraba que tu aplicación era accesible...

Pero de repente, los 'bugs' comenzaron a multiplicarse a una velocidad alarmante.

Diferentes lectores de pantalla (en. Screen Readers) y navegadores se comportaban de manera completamente diferente.

Los usuarios se quejaban de que la aplicación no era usable.

Una vez que se corregía un error en un lugar, aparecía otro en otro lugar.

Y simplemente cambiar y corregir errores de la interfaz de usuario requería un esfuerzo titánico.

Estuve allí. Sobreviví, pero no 'prosperamos': técnicamente limpiamos mucho, añadimos muchas descripciones a los campos, roles y alcanzamos cierto nivel de cumplimiento, pero nadie estaba feliz. Los usuarios seguían quejándose de que no podían navegar en la aplicación. El gerente seguía quejándose del flujo constante de errores. Los ingenieros se quejaban de la mala formulación del proyecto, sin una 'solución correcta' claramente definida que funcionara en todos los casos.

En mi camino hacia la comprensión de la accesibilidad, encontré algunos momentos claramente reveladores.
Quizá lo primero que comprendí fue que agregar funcionalidad de accesibilidad sobre un producto existente es complicado. Y aún más difícil es convencer a los gerentes de que ¡es increíblemente complicado! No, no se trata solo de "agregar algunas etiquetas" y el interfaz de usuario funcionará perfectamente. No, no es posible terminarlo en tres semanas; incluso tres meses serán insuficientes.
Mi próximo momento de verdad llegó cuando vi de primera mano cómo los usuarios ciegos realmente utilizan nuestra aplicación. ¡Es TAN diferente a ver mensajes de error!

Volveré a esto una y otra vez, pero casi todas nuestras "suposiciones" sobre cómo la gente usaba nuestra aplicación resultaron ser incorrectas.

Navegar por una interfaz de usuario compleja con teclas Tabulación/Shift+Tab ¡es horrible! Necesitamos algo mejor. Combinaciones de teclas, encabezados.

¿La pérdida de foco al cambiar la UI no es un gran problema? Pensemos de nuevo: es increíblemente confuso.

Continué, trabajé un tiempo en diferentes proyectos, y luego comenzamos un nuevo proyecto, con una interfaz de usuario compleja y un claro objetivo de finalmente lograr una accesibilidad adecuada esta vez.

Entonces, retrocedimos y buscamos cómo podríamos implementar esto de otra manera y tener éxito, y asegurar que el proceso mismo no fuera aburrido.

Rápidamente llegamos a algunas conclusiones:

No queríamos que las personas que desarrollaban la interfaz de usuario se ocuparan de las etiquetas/rangos aria y, naturalmente, de la estructura HTML de los componentes. Necesitábamos proporcionarles los componentes adecuados, en los que la accesibilidad estuviera implementada desde el primer momento.
Accesibilidad == Usabilidad – es decir, no solo es una tarea técnica. Necesitábamos cambiar todo el proceso de diseño y asegurarnos de que la accesibilidad se tome en cuenta y se discuta antes de iniciar el diseño de la interfaz de usuario. Teníamos que pensar desde el principio en cómo los usuarios podrían descubrir cualquier funcionalidad, cómo se moverían y cómo funcionaría el "clic derecho" del ratón con el teclado. La accesibilidad debe ser una parte integral del proceso de diseño; para algunos usuarios, es algo mucho más importante que la apariencia de la aplicación.
Desde el principio queríamos obtener comentarios de personas ciegas y otros usuarios con discapacidades sobre la facilidad de uso de la aplicación.
Necesitábamos formas realmente efectivas de detectar regresiones en la accesibilidad.

Desde un punto de vista ingenieril, la primera parte sonaba bastante divertida: el desarrollo de la arquitectura y la implementación de la biblioteca de componentes. Y realmente así fue.

Al dar un paso atrás, considerando ejemplos de ARIA y pensando en ello como un problema de diseño, no como un problema de 'adaptarse', introdujimos algunas abstracciones. El componente tiene 'Estructura' (compuesto de elementos HTML) y 'Comportamiento' (cómo interactúa con el usuario). Por ejemplo, en los fragmentos a continuación tenemos una lista simple no ordenada. Al añadir 'comportamiento' a la lista, se añaden roles apropiados para que actúe como lista. Hacemos lo mismo para el menú.

De hecho, aquí se añaden no solo roles, sino también manejadores de eventos para la navegación a través del teclado.

Esto ya se ve más ordenado. Si pudiéramos obtener una separación clara entre ellos, no importaría cómo se creó la estructura; podríamos aplicar comportamientos y obtener la accesibilidad correcta.

Esto se puede ver en acción en https://stardust-ui.github.io/react/ – la biblioteca UX React, que se proyecta y se implementa teniendo en cuenta la accesibilidad desde el principio.

La segunda parte, cambiar el enfoque y los procesos en torno al diseño, me asustaba al principio: modestos ingenieros tratando de impulsar cambios organizativos, no siempre termina bien, pero resultó ser una de las áreas más interesantes en las que hicimos una contribución significativa al proceso. En pocas palabras, teníamos el siguiente proceso: una nueva funcionalidad era desarrollada por un equipo, después nuestra grupo de líderes analizaba/iteraba la propuesta, y luego, tras su aprobación, generalmente el diseño se entregaba al equipo de ingenieros. En este caso, el equipo de ingenieros 'poseía' de hecho la funcionalidad de accesibilidad, ya que debía resolver todos los problemas asociados.

Al principio, fue un trabajo bastante difícil explicar que la accesibilidad y la facilidad de uso están intrínsecamente relacionadas y que esto debía abordarse desde la etapa de diseño, de lo contrario, se producirían cambios significativos y redefiniciones de algunos roles. Sin embargo, con el apoyo de la dirección y los actores clave, conseguimos comunicar esta idea y ponerla en marcha para que los diseños se sometieran a pruebas de accesibilidad y usabilidad antes de ser presentados a la dirección.

Y estos comentarios fueron extremadamente valiosos para todos; fue fantástico, como un ejercicio de intercambio de conocimientos/información sobre cómo los usuarios interactúan con las aplicaciones web, identificamos numerosas áreas problemáticas en la interfaz de usuario antes de que se construyeran. Actualmente, los equipos de desarrollo tienen especificaciones mucho mejores, no solo de los aspectos visuales, sino también de los aspectos conductuales del diseño. Las discusiones reales son diálogos divertidos, enérgicos y apasionados sobre aspectos técnicos y las interacciones.

Podríamos haber hecho este trabajo aún mejor si en estas (o futuras) reuniones hubieran participado usuarios ciegos y personas con discapacidades; fue complicado de organizar, pero ahora realmente estamos colaborando tanto con organizaciones locales de personas ciegas como con empresas que proporcionan pruebas externas para verificar el flujo de trabajo en las primeras etapas de desarrollo, tanto a nivel de componentes como a nivel de flujo de trabajo.

Ahora, los ingenieros tienen especificaciones bastante detalladas y componentes accesibles que pueden utilizar para implementar y verificar el flujo de trabajo. En parte, la experiencia nos ha enseñado lo que constantemente pasamos por alto: cómo podemos detener la regresión. De manera similar, las personas pueden utilizar pruebas de integración o pruebas de extremo a extremo para verificar la funcionalidad que necesitamos para detectar cambios en las interacciones y flujos de trabajo, tanto visuales como conductuales.

La definición de la regresión visual es una tarea bastante específica, se puede agregar muy poco a este proceso, excepto, quizás, verificar si el foco es visible al navegar con el teclado. Son más interesantes dos tecnologías relativamente nuevas para trabajar con la accesibilidad.

Accessibility Insights es un conjunto de herramientas que pueden ejecutarse tanto en el navegador como dentro del ciclo de compilación/pruebas, para identificar problemas.
Verificar el correcto funcionamiento de los lectores de pantalla fue una tarea especialmente difícil. Con la introducción del acceso a Accessibility DOM, finalmente obtuvimos la capacidad de tomar instantáneas de la aplicación desde el punto de vista de la accesibilidad, muy similar a cómo lo hacemos para las pruebas visuales, y verificarlas para detectar regresiones.

Así que, en la segunda parte de la historia, hemos pasado de editar el código HTML a trabajar en un nivel más alto de abstracción, cambiando el proceso de desarrollo del diseño e introduciendo pruebas rigurosas. Nuevos procesos, nuevas tecnologías y nuevos niveles de abstracción han cambiado por completo nuestra comprensión de la accesibilidad y de lo que significa trabajar en este campo.
Pero esto es solo el comienzo.

La siguiente «comprensión» es que los usuarios ciegos impulsan tecnologías innovadoras: ellos son quienes más se benefician, no solo de los cambios que hemos descrito anteriormente, sino también de que nuevos enfoques e ideas se hacen posibles con la ayuda de ML/AI. Por ejemplo, la tecnología Immersive Reader permite a los usuarios entender el texto de manera más simple y clara. Puede leerse en voz alta, la estructura de las oraciones se divide gramaticalmente e incluso se representan gráficamente los significados de las palabras. Esto no encaja en la antigua comprensión de «hacerlo accesible»: es una función de usabilidad que ayudará a todos.

Con ML/AI surgen formas completamente nuevas de interactuar y trabajar, y estamos contentos de ser parte de las siguientes etapas de este camino innovador. La innovación se basa en un cambio de mentalidad: la humanidad ha existido durante milenios, las máquinas durante cientos de años, los sitios web durante unas pocas décadas, y los teléfonos inteligentes incluso menos; la tecnología debe adaptarse a las personas, y no al revés.

P.D. El artículo ha sido traducido con algunas desviaciones del original. Siendo coautor de este artículo, he acordado estas desviaciones con Hugh.

Solo los usuarios registrados pueden participar en la encuesta. Inicie sesión, por favor.