El viernes es el final de la jornada laboral. Las malas noticias siempre llegan al final de la jornada laboral del viernes.
Está a punto de salir de la oficina, acaba de llegar al correo una nueva carta sobre otra reorganización.
Gracias xxxx, yyy a partir de hoy reportarás zzzz
...
Y el equipo de Hugh se asegurará de que nuestros productos sean accesibles para personas con discapacidades.
¡Oh, no! ¿Por qué merecía esto? ¿Quieren que me vaya? Prepárate para trabajar duro e ingrato y tratar de corregir los errores de otras personas. Definitivamente esto es un fracaso...
Esta era la disponibilidad hace unos años. A algunas pobres almas se les asignó la tarea de "limpiar" la interfaz de usuario para tratar de hacerla accesible para personas con discapacidades.
Lo que esto realmente significaba era bastante vago: presumiblemente, si pudiera ver un indicador de enfoque y pasar por los campos, tener algo de texto alternativo y un par de descripciones de campos, se consideraría que su aplicación es accesible...
Pero de repente los “bichitos” empezaron a multiplicarse a la velocidad de una avalancha.
Varios lectores de pantalla (Ing. Lectores de pantalla) y los navegadores se comportaron de manera completamente diferente.
Los usuarios se han quejado de que la aplicación no se puede utilizar.
Tan pronto como se corrigía un error en un lugar, aparecía otro en otro.
Y simplemente cambiar y corregir errores de la interfaz de usuario requirió esfuerzos hercúleos.
Yo estaba allí. Sobreviví, pero no "tuvimos éxito": técnicamente limpiamos mucho, agregamos muchas descripciones de campos, roles y logramos cierto nivel de cumplimiento, pero nadie estaba contento. Los usuarios aún se quejaban de que no podían navegar por la aplicación. El director todavía se quejaba del constante flujo de errores. Los ingenieros se quejaron de que el problema se planteó incorrectamente, sin una solución "correcta" claramente definida que funcionara en todos los casos.
Hubo algunos momentos decididamente reveladores a lo largo de mi viaje hacia la comprensión de la accesibilidad.
Quizás el primero fue darse cuenta de que era difícil agregar funcionalidad de accesibilidad además de un producto terminado. ¡Y es aún más difícil convencer a los directivos de que es increíblemente difícil! No, no se trata simplemente de "agregar algunas etiquetas" y la interfaz de usuario funcionará bien. No, esto no se puede completar en tres semanas; ni siquiera tres meses serán suficientes.
Mi siguiente momento de verdad llegó cuando vi de primera mano cómo los usuarios ciegos usaban nuestra aplicación. Esto es MUY diferente a mirar mensajes de error.
Volveré a esto una y otra vez, pero casi todas nuestras "suposiciones" sobre cómo la gente usaba nuestra aplicación eran erróneas.
Navegar por una interfaz de usuario compleja mediante pulsaciones de teclas Tab/Shift+Tab – ¡Esto apesta! Necesitamos algo mejor. Atajos de teclado, encabezados.
Perder el foco al cambiar la interfaz de usuario no es un gran problema, ¿verdad? Pensemos de nuevo: esto es increíblemente confuso.
Continué, trabajé en diferentes proyectos durante un tiempo y luego comenzamos un nuevo proyecto, con una interfaz de usuario compleja y una instalación clara, para finalmente lograr la accesibilidad correcta esta vez.
Entonces, dimos un paso atrás y analizamos cómo podríamos implementar esto de manera diferente y tener éxito, ¡y hacer que el proceso sea menos aburrido!
Muy rápidamente llegamos a algunas conclusiones:
- No queríamos que la gente que desarrollaba la interfaz de usuario se metiera con las etiquetas/roles de aria y, por supuesto, con la estructura HTML de los componentes. Necesitábamos proporcionarles los componentes adecuados que crearan accesibilidad desde el primer momento.
- Accesibilidad == Facilidad de uso, es decir Este no es sólo un desafío técnico. Necesitábamos cambiar todo el proceso de diseño y asegurarnos de que la accesibilidad se tuviera en cuenta y se discutiera antes de comenzar el diseño de la interfaz de usuario. Debe pensar desde el principio cómo los usuarios descubrirán cualquier funcionalidad, cómo navegarán y cómo funcionará hacer clic derecho desde el teclado. La accesibilidad debe ser una parte integral del proceso de diseño; para algunos usuarios es mucho más que la simple apariencia de la aplicación.
- Desde el principio, queríamos recibir comentarios de usuarios ciegos y otros discapacitados sobre la facilidad de uso de la aplicación.
- Necesitábamos formas realmente buenas de captar las regresiones de accesibilidad.
Bueno, desde el punto de vista de la ingeniería, la primera parte sonó bastante divertida: desarrollar una arquitectura e implementar una biblioteca de componentes. Y efectivamente así fue.
Dando un paso atrás, mirando y al pensar en esto como un problema de diseño más que como un problema de "adaptación", introdujimos algunas abstracciones. Un componente tiene una 'Estructura' (consta de elementos HTML) y un 'Comportamiento' (cómo interactúa con el usuario). Por ejemplo, en los fragmentos siguientes tenemos una lista simple desordenada. Al agregar "comportamientos", los roles correspondientes se agregan a la lista para que actúe como una lista. Hacemos lo mismo con el menú.
De hecho, aquí no solo se agregan roles, sino también controladores de eventos para la navegación con el teclado.
Esto se ve más ordenado. Si pudiéramos lograr una separación clara entre ellos, no importaría cómo se creó la estructura, podríamos aplicarle comportamientos y obtener la accesibilidad correcta.
Puedes ver esto en acción en – Biblioteca de experiencia de usuario , que está diseñado e implementado teniendo en cuenta la accesibilidad desde el principio.
La segunda parte: cambiar el enfoque y los procesos en torno al diseño inicialmente me asustó: los ingenieros humildes que intentan impulsar el cambio organizacional no siempre terminan bien, pero resultó ser una de las áreas más interesantes en las que hicimos contribuciones significativas al proceso. . En pocas palabras, nuestro proceso fue el siguiente: un equipo desarrollaría la nueva funcionalidad, luego nuestro equipo de liderazgo revisaría/iteraría la propuesta y luego, una vez aprobada, el diseño generalmente se entregaría al equipo de ingeniería. En este caso, el equipo de ingeniería efectivamente era "propietario" de la funcionalidad de accesibilidad porque era su responsabilidad solucionar cualquier problema asociado con ella.
Al principio, fue un trabajo bastante difícil explicar que la accesibilidad y la usabilidad están inextricablemente vinculadas y que esto tenía que hacerse en la etapa de diseño, de lo contrario conduciría a grandes cambios y redefiniciones de algunas funciones. Sin embargo, con el apoyo de la gerencia y los actores clave, tomamos la idea y la pusimos en marcha para que se probara la accesibilidad y usabilidad de los diseños antes de presentarlos a la gerencia.
Y estos comentarios fueron extremadamente valiosos para todos: fue fantástico como ejercicio de intercambio/comunicación de conocimientos sobre cómo los usuarios interactúan con las aplicaciones web, identificamos numerosas áreas problemáticas de la interfaz de usuario antes de que se crearan, los equipos de desarrollo ahora tienen especificaciones mucho mejores de no sólo aspectos visuales, sino también comportamentales del diseño. Las discusiones reales son discusiones divertidas, enérgicas y apasionadas sobre aspectos e interacciones técnicos.
Podríamos hacer esto aún mejor si tuviéramos usuarios ciegos y discapacitados en estas (o posteriores) reuniones; esto fue difícil de organizar, pero ahora trabajamos con organizaciones y empresas locales para ciegos, que brindan pruebas externas para verificar el flujo de ejecución en las primeras etapas. desarrollo, tanto a nivel de componente como de flujo de ejecución.
Los ingenieros ahora tienen especificaciones bastante detalladas, componentes disponibles que pueden usar para implementar y una forma de validar el flujo de ejecución. Parte de lo que nos ha enseñado la experiencia es lo que nos hemos estado perdiendo todo el tiempo: cómo podemos detener la regresión. Del mismo modo, las personas pueden utilizar pruebas de integración o de un extremo a otro para probar la funcionalidad, que necesitamos para detectar cambios en las interacciones y los flujos de ejecución, tanto visuales como de comportamiento.
Determinar la regresión visual es una tarea bastante definida; hay muy poco que se pueda agregar al proceso aparte de verificar si el foco es visible al navegar con el teclado. Más interesantes son dos tecnologías relativamente nuevas para trabajar con accesibilidad.
- es un conjunto de herramientas que se pueden ejecutar tanto en el navegador como como parte del ciclo de compilación/prueba para identificar problemas.
- Verificar que los lectores de pantalla funcionen correctamente ha sido una tarea particularmente desafiante. Con la introducción del acceso a Accesibilidad DOM, finalmente podemos tomar instantáneas de accesibilidad de la aplicación, como lo hacemos para las pruebas visuales, y probarlas para determinar la regresión.
Entonces, en la segunda parte de la historia, pasamos de editar código HTML a trabajar en un nivel más alto de abstracción, cambiamos el proceso de desarrollo del diseño e introdujimos pruebas exhaustivas. Nuevos procesos, nuevas tecnologías y nuevos niveles de abstracción han cambiado por completo el panorama de la accesibilidad y lo que significa trabajar en este espacio.
Pero esto es solo el comienzo.
El siguiente “entendimiento” es que los usuarios ciegos están impulsando tecnología de vanguardia: son los que más se benefician no solo de los cambios que describimos anteriormente, sino también de que el ML/AI hace posibles nuevos enfoques e ideas. Por ejemplo, la tecnología Immersive Reader permite a los usuarios presentar texto de forma más fácil y clara. Se puede leer en voz alta, la estructura de la oración se desglosa gramaticalmente e incluso el significado de las palabras se muestra gráficamente. Esto no encaja en absoluto con la antigua mentalidad de "hacerlo accesible": es una característica de usabilidad que ayudará a todos.
ML/AI está permitiendo formas completamente nuevas de interactuar y trabajar, y estamos entusiasmados de ser parte de las próximas etapas de este viaje de vanguardia. La innovación está impulsada por un cambio de mentalidad: la humanidad existe desde hace milenios, las máquinas desde hace cientos de años, los sitios web desde hace varias décadas y los teléfonos inteligentes aún menos, la tecnología debe adaptarse a las personas y no al revés.
PD: El artículo ha sido traducido con pequeñas desviaciones del original. Como coautor de este artículo, estuve de acuerdo con Hugh en estas digresiones.
Solo los usuarios registrados pueden participar en la encuesta. por favor
¿Prestas atención a la accesibilidad de tus aplicaciones?
-
Sí
-
No
-
Esta es la primera vez que escucho sobre la accesibilidad de las aplicaciones.
17 usuarios votaron. 5 usuarios se abstuvieron.
Fuente: habr.com