Digital Accessibility Guide

Hola y bienvenidos a mi charla sobre la ampliación de la accesibilidad. Hablaremos sobre cómo lograr una accesibilidad digital sostenible. Mi nombre es Tim Dama. Soy un desarrollador frontend y líder de accesibilidad en ABN AMRO, que es un banco en los Países Bajos. Y si quieres más información sobre mí, puedes visitar mi sitio web si lo deseas.

Sin más preámbulos, comencemos con una introducción a la accesibilidad. Y me gusta comenzar esta introducción con características de accesibilidad de la vida real como estas baldosas. Podrías encontrarlas en estaciones de tren o estaciones de metro. Guiando a las personas, personas videntes a lo largo del camino. O ascensores, por supuesto, ayudando a personas en sillas de ruedas, por ejemplo, o personas con un cochecito, con niños pequeños. Haciendo la vida fácil para subir y bajar en grandes edificios o estaciones de metro, por ejemplo. Y último ejemplo, semáforos, donde tienes los colores que indican cuándo detenerse o cuándo avanzar. Pero también los sonidos de tic-tac. Podrías reconocerlo cuando la luz está verde. El sonido de tic-tac va más rápido. Cuando está rojo, va más lento. Y estos son todos ejemplos de características de accesibilidad de la vida real, que hemos construido juntos para hacer la vida más fácil para nosotros mismos. Pero también para personas con discapacidades, estas características están construidas con la accesibilidad en mente. Y yo argumentaría que deberíamos hacer lo mismo al construir en la web. Al construir aplicaciones frontend, por ejemplo. Y nuestras vidas como desarrolladores frontend, por ejemplo, se hacen un poco más fáciles porque la accesibilidad ya está incorporada en la web.

Sí, ¿por qué decimos esto? Porque el creador de la web, Tim Berners-Lee, dijo hace mucho tiempo, dijo que el poder de la web está en su universalidad. El acceso por parte de todos, independientemente de la discapacidad, es un aspecto esencial. Entonces, la web fue creada con la accesibilidad en mente. Solo necesitamos utilizarla para crear aplicaciones web accesibles. Y por supuesto, con el tiempo, la web evolucionó y se desarrolló más. Más JavaScript y características CSS más complejas llegaron, lo que hizo que la web fuera un poco menos accesible. Pero no obstante, estas mismas características de accesibilidad todavía están disponibles. Solo necesitamos usarlas. Así que, resumiendo un poco.

La accesibilidad digital trata de crear aplicaciones que sean accesibles para todos, independientemente de la discapacidad. Y hablando de todos, por ejemplo, estas personas, este gran grupo de personas que usan tu aplicación o sitio web o aplicación web, el grupo de personas, que incluye a 1.3 mil millones de personas que experimentan discapacidades significativas, según la OMS. Entonces, estas son personas que usan tu aplicación.

Así que, estoy hablando con muchos desarrolladores frontend, muchos desarrolladores en JS Nation, por lo que me gusta compartir este gráfico contigo de esta organización, WebAIM. Hacen muchas cosas geniales sobre la accesibilidad. Y lo que hacen cada año, realizan esta investigación, y investigan un millón de diferentes páginas de inicio web y prueban con las cifras de WCAG. Y lo que encontraron es que el 95.9% de todas estas páginas de inicio no cumplen con las cifras de WCAG en ellas. Así que, no son accesibles. Así que, animaría a todos a, después de esta charla, investigar el tema de la accesibilidad y tratar de mejorar y tratar de crear características web más accesibles para nuestros usuarios.

Die, die. Y hablando de WCAG, está en el título aquí mismo. Para las personas que aún no saben todavía, WCAG significa Web Content Accessibility Guidelines. Y WCAG son las directrices definidas internacionalmente que proporcionan una base para la accesibilidad web. Y 2.2 es la última versión de WCAG. Y si quieres, die. Después de esta charla, puedes ir a esta URL que compartí y buscar en las especificaciones, por ejemplo. Hay mucha información excelente sobre WCAG en esta página, específicamente sobre todos los requisitos y el significado de todos los criterios de éxito dentro de WCAG. Hay muchas directrices diferentes, y mucha información diferente para que descubras.

Y WCAG también se utiliza en mucha legislación alrededor del mundo. Por ejemplo, también en el EU Accessibility Act que se implementará el próximo año. Die.

Así que hicimos una pequeña introducción. Hablamos sobre WCAG. Te mostré un buen gráfico de lo mal que lo estamos haciendo. Ahora hablemos de algunos roles y responsabilidades dentro de una organización que necesitas antes de escalar tu accesibilidad.

Así que lo que quieres tener es un enfoque a nivel organizacional para comenzar a mejorar la accesibilidad web. Y lo que es realmente bueno es si tienes si la accesibilidad tiene el apoyo de la gerencia, así que el apoyo de la alta gerencia, diciendo que hay una persona que tiene la responsabilidad final de la accesibilidad que preferiblemente esté cerca del CEO. Die. Y la accesibilidad está incluida en eventualmente todos los procesos, necesita ser incluida en todos los procesos para todos los diferentes roles. Y es realmente bueno si tienes un presupuesto y capacidad permanentes para eso.

Si eso aún no es el caso, no te preocupes. Puedes comenzar a abogar por ello. Por ejemplo, yo mismo y un grupo de desarrolladores y diseñadores también comenzamos a abogar por ello dentro de Admin Envelope hace dos años. Y ahora tenemos prioridad, tenemos capacidad y tenemos presupuesto para trabajar en ello. Así que puedes comenzar pequeño y comenzar a escalar. Die. Die.

También dentro de organizaciones de tamaño mediano a grande, los equipos de desarrollo están estructurados de esta manera. Así que tenemos muchos equipos de desarrollo diferentes trabajando en sus propias aplicaciones. Y estos equipos, la mayoría de las veces, constan de un PO, diseñador, desarrolladores, testers, por ejemplo. Y el PO tiene un papel realmente importante que desempeñar cuando se trata de la priorización, por supuesto, de la accesibilidad. Además, tiene más una visión general de si el nivel de accesibilidad del equipo es lo suficientemente alto como para comenzar a crear aplicaciones accesibles. Y el diseñador, desarrollador y tester, cada uno en su propio rol necesita evaluar si pueden probar la accesibilidad, desarrollar de manera accesible, o diseñar de manera accesible. Necesitan estar al día con los últimos estándares y directrices, por ejemplo, con Baycoff, y necesitan tener controles en su lugar para... Die. Conocimiento en su lugar para comenzar a trabajar de manera accesible. Die.

Así que esta organización, por ejemplo, el equipo A podría estar trabajando en la aplicación llamada Manage Contacts.

El equipo B está trabajando en solicitar nuevos productos. El equipo C trabajando en la configuración de productos, por ejemplo. Y el equipo D podría estar trabajando en la navegación. Die. Cada equipo encapsulado dentro de su propio equipo trabaja en sus aplicaciones. Y, por ejemplo, uno principal o uno principal y uno más pequeño juntos. Pero eventualmente necesitan unirse y necesitan trabajar juntos, por supuesto. Necesitan usar los mismos colores. Necesitan usar la misma fuente, misma imagen, mismo logo. Y esto, por supuesto, necesitas trabajar juntos también como una sola organización.

También, cuando se trata de accesibilidad, que es un esfuerzo combinado... Debería ser un esfuerzo combinado. Die. Muy bien. Así que hablamos sobre algunos roles y responsabilidades. Ahora, hablemos sobre el tema, por supuesto. Cómo dejar de lanzar características inaccesibles. Por ejemplo, estos equipos, están trabajando hoy en día mucho en formas ágiles de scrum. Así que están yendo en ciclos de dos semanas de sprint a sprint. Y en el día a día, nuevo código se publica en producción. Y la mayoría de las veces, como el 95.9% del tiempo, este código no es accesible. Así que estamos lanzando características inaccesibles. Bueno, ¿cómo detener eso? Die. Lo primero que quieres comenzar a hacer es construir una base de conocimiento dentro de tu organización. Construir conocimiento es algo bueno de hacer para todos, para cada rol. Debería recibir, por ejemplo, una capacitación en accesibilidad, una capacitación introductoria. Pero también hay capacitaciones especializadas para desarrolladores, diseñadores y testers. Puedes optar por certificaciones, por ejemplo.

Y lo que también es realmente bueno, si comienzas a hacer eso, son las sesiones internas de investigación e intercambio de conocimientos. Por ejemplo, en ABN AMRA, tenemos un gremio de accesibilidad en el cual, juntos, investigamos el tema y compartimos conocimientos dentro del gremio, pero también con otros equipos. Die. Die.

Así que construir conocimiento y realizar pruebas es realmente importante. Automatizadas, manuales, pruebas de usuario, todas muy importantes. Automatizadas, por supuesto, úsalas tanto como sea posible. Pero no esperes detectar todo con pruebas automatizadas. Alrededor del 20% al 25% de los problemas, puedes detectarlos con pruebas automatizadas. Las pruebas manuales son el camino a seguir aquí, es donde obtienes una visión completa de tus problemas, por ejemplo. Y las pruebas de usuario también son realmente importantes. Necesitas probar con el usuario final e incluir también a personas con discapacidades en este grupo, por supuesto. Die.

Así que tenemos construcción de conocimiento, pruebas y monitoreo. El monitoreo también es realmente bueno para agregar a esta lista. Comienza a monitorear los problemas, problemas de accesibilidad encontrados, por ejemplo, por equipo, por cuadrícula, por bloque, lo que sea que estés usando. Así puedes ver cuántos problemas aún existen, qué equipo lo está haciendo mejor, qué cuadrícula lo está haciendo mejor. Y esto también hace que el esfuerzo combinado de solucionar problemas de accesibilidad sea realmente más fácil de seguir. Die. Y luego también necesitamos hablar sobre la auditoría de accesibilidad. Auditoría, pruebas, verificación de accesibilidad. Y la auditoría la mayoría de las veces se utiliza dentro de las organizaciones para tener una idea de qué tan bien lo está haciendo la empresa en términos de accesibilidad, y también se utiliza como la forma de obtener información y retroalimentación sobre el nivel de accesibilidad dentro de la empresa. Y esto también se comunica, por supuesto, con los equipos de desarrollo. Pero estoy de acuerdo con Carl Groves en este punto, y es que él dijo que las auditorías y las herramientas automatizadas no solucionan los problemas de accesibilidad. Y entraré un poco más en detalle, explicando por qué, por ejemplo, la metodología que se utiliza para auditar la accesibilidad, el método WCAG-EM, tiene algunas desventajas donde para organizaciones más grandes con muchos equipos de desarrollo diferentes que están trabajando en sus propias aplicaciones, obtener la retroalimentación correcta para estos equipos específicos. Dos cosas que quiero destacar. Ese es el tamaño de muestra grande. El método de evaluación WCAG-EM prescribe que el tamaño de muestra en el que se realiza la auditoría necesita ser grande para aplicaciones grandes. Puede consistir en unas 20 a 25 páginas diferentes. Y la segunda es que no es obligatorio mostrar todos los problemas por requisitos de WCAG.

Y el segundo es que no es obligatorio mostrar todos los problemas por requisitos de WCAG. Así que hay muchos requisitos de WCAG, y no todos los problemas necesitan ser mostrados para cada uno de los requisitos de WCAG. De hecho, solo uno es requerido. Esto trae algunos problemas cuando se intenta construir el conocimiento dentro de los equipos sobre accesibilidad. Uno es que debido al gran tamaño de la muestra, muchos equipos diferentes pueden estar involucrados en una sola auditoría. Y hay un potencial para pasar por alto muchos problemas debido al gran tamaño de la muestra y al hecho de que no es obligatorio listar todos los problemas por requisitos de WCAG. Esto hace que una auditoría sea realmente amplia.

Además, el momento en que se realiza principalmente una auditoría de accesibilidad es, se puede ver como en una forma en cascada de hacer su ciclo de vida de desarrollo. Realmente se hace en la parte más baja de la cascada. Así que cuando el código ya está en producción por un tiempo, entonces un auditor entra y revisa y ve todo y lo informa. Y esto, por supuesto, no es una forma realmente eficiente de volver todo el camino, comenzar a corregir cosas.

Ahora, lo que sucede es que después de algunos meses pasan o medio año o más, entonces nuevamente, se realiza una auditoría en la parte más baja del ciclo. Y entras en un ciclo de auditoría, corrigiendo estas cosas encontradas, auditoría, corrección. Y esto no es algo que funcione para muchas organizaciones, que son un poco más grandes y tienen muchos equipos de desarrollo diferentes. Porque estos equipos, lo que están haciendo, están operando en ciclos de desarrollo ágil de aproximadamente dos semanas. Y el momento perfecto para verificar la accesibilidad es, por supuesto, en cada paso del camino. Así que no solo durante las pruebas, sino también desarrollando, en todas partes en el mundo perfecto se necesita verificar la accesibilidad.

Por supuesto, si haces esto, ya tienes un nivel muy alto de accesibilidad. Pero en realidad llegar a este punto, así que construir el conocimiento dentro de cada equipo para poder hacer esto, es la parte más importante. Y ahí es donde entra el ciclo de retroalimentación de accesibilidad. Hay mucho en la pantalla ahora mismo, lo revisaremos juntos. No te preocupes, comenzaremos todo el camino a la izquierda con el equipo A, el equipo de desarrollo A, quieren entrar en el ciclo. Quieren entrar en el ciclo de retroalimentación de accesibilidad. Quieren hacer una aplicación accesible, su aplicación accesible. Así que necesitan cumplir con algunos de los requisitos previos. Estos pueden ser que necesitas estar usando las últimas versiones de todos los componentes del sistema de diseño, por ejemplo.

Si cumplen con todos los requisitos previos, se realiza una reunión de ingreso con el equipo de accesibilidad. Y este equipo hará dos cosas entonces. Y hay dos tipos de pruebas. Así que la prueba wake up 2.2a y una prueba de usuario de accesibilidad. Y estas dos pruebas combinadas dirán, de acuerdo, esta aplicación es accesible. ¿Sí o no? Probablemente las primeras veces, o tal vez un poco más será no. Y luego se entrega un informe de mejora de auditoría al equipo que es probado. Y luego en dos o tres sprints, necesitarán haber abordado todos los problemas y se realiza una nueva auditoría después de este tiempo. Así que el equipo de accesibilidad interviene nuevamente. ¿La prueba es accesible? ¿Sí o no? Bueno, las primeras veces probablemente será no. Pero después de una cierta cantidad de tiempo en pruebas, será sí, por supuesto, porque este ciclo no se detendrá hasta que lleguemos allí.

Y luego se otorga un certificado de accesibilidad al equipo. Y luego, después de un cierto período de tiempo, necesitarán ir por la recertificación. Así que necesitarán estar al tanto del conocimiento que se acumula en el equipo, porque reciben retroalimentación sobre su aplicación y comienzan a ver la forma en que han desarrollado su aplicación y la forma en que la han desarrollado de manera accesible. Ahora se les muestra cómo hacerlo de manera accesible. Así que hay conocimiento que se está acumulando en el equipo.

También habrá recertificaciones sobre eso. Y una forma realmente agradable para que los equipos reciban esta retroalimentación. Así que por cada problema encontrado en la aplicación que están construyendo, se da para cada problema de tal manera. Comenzando desde el principio, tenemos un título, el menú principal no funciona con el teclado. Y luego en la descripción, el problema se describe con texto enriquecido HTML, lo cual describe el problema de tal manera que es comprensible para el equipo de desarrollo. Y después de eso, también se da una solución, que podría ser la solución o simplemente la dirección en la que el equipo podría ir. Al final, también puedes ver algunos metadatos que apuntan a la documentación de la WCAG, por ejemplo, y también algunos otros metadatos como dificultad y severidad, y la muestra en la que se encontró este problema.

Muy bien. Y para resumir ahora, hicimos una introducción sobre accesibilidad. Hablamos sobre WCAG, roles y responsabilidades dentro de la organización, cómo detener la liberación de características inaccesibles, sobre lo cual cubrimos auditorías de accesibilidad, por ejemplo, y luego hablamos sobre el ciclo de retroalimentación de accesibilidad. Y espero que hayas encontrado estos temas interesantes y que hayas aprendido algo. También me gustaría saber sobre ello. Así que si me contactas en algún lugar y me cuentas sobre ello, definitivamente me gustaría saberlo y me gustaría charlar contigo al respecto. Muchas gracias por escuchar y tomarte el tiempo. Y espero verte la próxima vez.