Imagínese ser ciego e intentar asistir a un evento virtual. Pruébelo la próxima vez que suba a la primera etapa. – Heaven32

¿Cómo se puede hacer que un evento virtual sea accesible para personas ciegas o con discapacidad visual?

Cuando comencé a trabajar en Sight Tech Global en junio de este año, confiaba en que encontraríamos la respuesta a esa pregunta con bastante rapidez. Con tantas plataformas de eventos virtuales y opciones de venta de entradas en línea disponibles para los organizadores de eventos virtuales, estábamos seguros de que al menos una cumpliría con un estándar razonable de accesibilidad para las personas que usan lectores de pantalla u otros dispositivos para navegar por la Web.

Lamentablemente, estaba equivocado en eso. Mientras hacía mi debida diligencia y hablaba con directores ejecutivos en una variedad de plataformas, escuché mucho de “estamos estudiando WCAG [Web Content Accessibility Guidelines] requisitos “o” nuestros desarrolladores van a volver a escribir nuestro código front-end cuando tengamos tiempo “. En otras palabras, estas operaciones, como muchas otras en la Web, no se habían tomado la molestia de codificar sus sitios para la accesibilidad al principio, que es el enfoque menos costoso y más justo, por no mencionar el que cumple con la ADA.

Esta comprensión fue una gran señal de alerta. Habíamos anunciado las fechas de nuestro evento, del 2 al 3 de diciembre de 2020, y no había vuelta atrás. Dmitry Paperny, nuestro diseñador, y no tuve mucho tiempo para encontrar una solución. No menos importante que las fechas fue el imperativo de que la experiencia virtual del evento funcione bien para los asistentes ciegos, dado que nuestro evento estaba realmente centrado en esa comunidad.

Decidimos llevar la navaja de Occam a las convenciones que rodean las experiencias de eventos virtuales y responder una pregunta clave: ¿Qué era esencial? Las plataformas de eventos virtuales tienden a tener muchas funciones, lo que agrava los problemas de accesibilidad. Clasificamos lo que realmente importaba y la lista se redujo a tres cosas:

  • video en vivo para los eventos del “escenario principal”
  • una agenda interactiva y altamente navegable
  • video interactivo para las sesiones de trabajo.

También debatimos agregar un elemento social o de redes y decidimos que era opcional a menos que hubiera una solución fácil y convincente.

La siguiente pregunta fue ¿qué herramientas de terceros podríamos usar? La muy buena noticia fue que YouTube y Zoom obtienen excelentes calificaciones en accesibilidad. Las personas ciegas están familiarizadas con ambos y muchos conocen los comandos del teclado para navegar por los jugadores. Descubrimos esto en gran parte de boca en boca al principio y luego descubrimos una amplia documentación de respaldo en YouTube y Zoom. Así que elegimos YouTube para nuestra programación del escenario principal y Zoom para nuestros brotes. Es útil, por supuesto, que sea muy fácil incorporar YouTube y Zoom en un sitio web, que se convirtió en nuestro plan.

Dónde hospedar la experiencia general, fue la siguiente pregunta. Queríamos poder dirigir a los asistentes a una única URL para unirse al evento. Afortunadamente, ya habíamos construido un sitio web accesible para comercializar el evento. Dmitry había aprendido mucho en el curso del diseño y la codificación de ese sitio, incluida la importancia de pensar tanto en los usuarios ciegos como en los de baja visión. Así que decidimos agregar la experiencia del evento a nuestro sitio en sí, en lugar de usar una plataforma de eventos de terceros, agregando dos elementos a la navegación del sitio: Evento (ya no está en vivo en el sitio) y Agenda.

La primera equivalía a una “página” (en el lenguaje de WordPress) que contenía el reproductor en vivo de YouTube incrustado, y debajo de ese texto descripciones de la sesión actual y la próxima sesión, junto con enlaces destacados a la Agenda completa. Algunas personas podrían preguntar, ¿por qué colocar la agenda en una página separada? ¿No lo hace eso más complicado? Buena pregunta, y la respuesta fue una de las muchas revelaciones que vinieron de nuestro socio. Fábula, que se especializa en pruebas de usabilidad para personas con discapacidades. La respuesta, como encontramos una y otra vez, fue imaginar la navegación con un lector de pantalla, no con los ojos. Si la agenda estuviera debajo del reproductor de YouTube, crearía una experiencia cacofónica – imagínese tratando de escuchar la programación y al mismo tiempo “leer” (como en “escuchar”) la agenda a continuación. Una página separada para la agenda fue la idea correcta.

los Página de la agenda fue nuestro mayor desafío porque contenía mucha información, requería filtros y también, durante el programa, tenía diferentes “estados” – como en qué elementos de la agenda estaban “jugando ahora” versus próximos versus ya concluidos. Dmitry aprendió mucho sobre el mejor enfoque de los menús desplegables para filtros y otros detalles para hacer navegable la página de la agenda, y lo revisamos varias veces con los expertos de Fable. No obstante, decidimos dar el paso sin precedentes de invitar a nuestros asistentes ciegos registrados al evento a unirse a nosotros para un “evento de práctica” unos días antes del espectáculo para obtener más comentarios. Casi 200 personas asistieron a dos sesiones. También invitamos a expertos en lectores de pantalla ciegos, incluidos Sam Proulx de Fable y Matt King de Facebook, a unirse a nosotros para responder preguntas y resolver los comentarios.

Vale la pena señalar que hay tres lectores de pantalla principales: JAWS, que es utilizado principalmente por los usuarios de Windows; VoiceOver, que se encuentra en todos los productos de Apple; y NVDA, que es de código abierto y funciona en PC con Microsoft Windows 7 SP1 y versiones posteriores. No todos funcionan de la misma manera, y las personas que los usan van desde expertos que conocen cientos de comandos de teclado hasta usuarios ocasionales que tienen habilidades más básicas. Por esa razón, es muy importante contar con interlocutores expertos que puedan ayudar a separar las buenas sugerencias de las frustraciones simples.

El formato de nuestra jornada de puertas abiertas (sesión uno y sesión dos) fue una reunión de Zoom, donde brindamos un resumen sobre el evento y cómo funcionó la experiencia. Luego, proporcionamos enlaces a una página de eventos en funcionamiento (con un reproductor de YouTube activo) y la página de la agenda, y les pedimos a las personas que lo probaran y regresaran a la sesión de Zoom con comentarios. Como tantas otras cosas en este esfuerzo, el resultado fue humillante. Teníamos bien los conceptos básicos, pero habíamos pasado por alto algunos matices, como la mejor manera de ordenar la información en un ítem de la agenda para alguien que solo puede “escucharlo” en lugar de “verlo”. Afortunadamente, tuvimos tiempo de ajustar un poco más la página de la agenda antes del espectáculo.

La sesión de práctica también reforzó que habíamos hecho un buen movimiento para ofrecer soporte al cliente en vivo durante el espectáculo como un amortiguador para los asistentes que eran menos sofisticados en el uso de lectores de pantalla. Nos asociamos con Ser mis ojos, una aplicación móvil que conecta a los usuarios ciegos con ayudantes videntes que usan la cámara del teléfono de la persona ciega para ayudar a solucionar problemas. Es como tener un amigo mirando por encima de tu hombro. Reclutamos a 10 voluntarios y los capacitamos para que estuvieran listos para responder preguntas sobre el evento, y Be My Eyes los colocó en la parte superior de la lista para cualquier llamada relacionada con Sight Tech Global, que se incluyó en la sección “Evento” de Be My Eyes. . Nuestro anfitrión del evento, el incomparable Will Butler, quien es vicepresidente de Be My Eyes, les recordaba regularmente a los asistentes que usaran Be My Eyes si necesitaban ayuda con la experiencia virtual.

Un mes después del evento, nos sentimos lo suficientemente confiados que decidimos agregar una función de interacción social al programa. La palabra en la calle era que Slido ‘Las funciones básicas de preguntas y respuestas funcionaron bien con los lectores de pantalla y, de hecho, Fable utilizó el servicio para sus proyectos. Entonces agregamos Slido al programa. No incorporamos un widget de Slido debajo del reproductor de YouTube, que podría haber sido una buena solución para los participantes videntes, sino que agregamos un enlace a cada sesión de la agenda a una página de Slido independiente, donde los asistentes podían agregar comentarios y hacer preguntas sin enredarse. la agenda o la transmisión en vivo. La solución terminó funcionando bien y tuvimos más de 750 comentarios y preguntas sobre Slido durante el programa.

Cuando finalmente llegó el 2 de diciembre, estábamos listos. Pero los planes mejor trazados a menudo salen mal, estábamos a solo unos minutos del evento cuando de repente se rompieron nuestros subtítulos en vivo. Decidimos detener el espectáculo hasta que pudiéramos volver a reproducirlo en vivo, en beneficio de los asistentes sordos y con problemas de audición. Después de muchas revueltas, volvieron los subtítulos. (Vea más sobre los subtítulos a continuación).

De lo contrario, la producción funcionó bien desde el punto de vista de la programación y la accesibilidad. ¿Como lo hicimos? De los más de 2400 asistentes registrados en el evento, el 45% dijo que planeaba usar lectores de pantalla. Cuando hicimos una encuesta a esos asistentes inmediatamente después del espectáculo, 95 respondieron y le dieron a la experiencia una puntuación de 4.6 / 5. En cuanto a la programación, nuestros asistentes (esta vez preguntaron a todos – 157 respuestas) nos dieron una puntuación de 4,7 / 5. No hace falta decir que estábamos encantados con esos resultados.

Otra nota se refería al registro. Al principio, también “escuchamos” que una de las plataformas de registro de eventos era “tan buena como es posible” en cuanto a accesibilidad. Lo tomamos al pie de la letra, lo cual fue un error. Deberíamos haberlo probado porque los comentarios de las personas que intentan registrarse, así como la baja participación de personas ciegas en el registro, revelaron después de unas semanas que el sitio de registro puede haber sido mejor que el resto, pero aún así fue realmente decepcionante. Fue doloroso, por ejemplo, aprender de uno de nuestros oradores que etiquetas alt faltaban en las imágenes (y no había forma de agregarlas) y que los usuarios del lector de pantalla tenían que pasar por montañas de información para acceder a enlaces procesables, como “registrarse”.

Como hicimos con nuestro enfoque del sitio web, decidimos que lo mejor era simplificar. Agregamos un Formulario de Google como opción de registro alternativa. Estos son muy accesibles. Instantáneamente vimos que nuestros registros aumentaron fuertemente, particularmente entre las personas ciegas. Nos disgustó darnos cuenta de que nuestra primera opción para el registro había sido excluir a las mismas personas que nuestro evento pretendía incluir.

Pudimos usar la opción Google Forms porque el evento fue gratuito. Si hubiéramos intentado cobrar el pago de las tarifas de registro, Google Form no habría sido una opción. ¿Por qué hicimos que el evento fuera gratuito para todos los asistentes? Hay varias razones. Primero, dadas nuestras ambiciones de hacer que el evento sea global y fácilmente disponible para cualquier persona interesada en la ceguera, fue difícil llegar a un precio universalmente aceptable. En segundo lugar, agregar un pago y una función de “inicio de sesión” para acceder al evento en sí crearía otro dolor de cabeza de accesibilidad. Con nuestro enfoque, cualquier persona con el enlace a la agenda o la página del evento podría asistir sin ninguna solicitud de inicio de sesión o registro. Sabíamos que esto crearía algunas filtraciones en términos de saber quién asistió al evento, bastante de hecho porque teníamos un 30% más de asistentes que registrantes, pero dada la naturaleza del evento, pensamos que perder nombres y correos electrónicos era aceptable. precio a pagar considerando el beneficio de accesibilidad.

Si hay una lección general de este ejercicio, es simplemente esta: los organizadores de eventos deben arremangarse y llegar al fondo de si la experiencia es accesible o no. No es suficiente confiar en los proveedores de plataformas o tecnología, a menos que tengan una reputación destacada en la comunidad, como lo hacen YouTube y Zoom. Es igualmente importante asegurarse de que el sitio o la plataforma estén codificados de forma adecuada (según los estándares WCAG y utilizando una herramienta como la de Google Faro) ya que se trata de realizar pruebas en el mundo real para garantizar que la experiencia real y observable de los usuarios ciegos y con baja visión sea buena. Al final del día, eso es lo que más cuenta.

Una nota final a pie de página. Aunque nuestro evento se centró en cuestiones de accesibilidad para personas ciegas o con baja visión, nos comprometimos desde el principio a incluir subtítulos para las personas que se beneficiarían. Optamos por el resultado de mejor calidad, que sigue siendo subtituladores humanos (versus IA), y trabajamos con VITACE para proporcionar subtítulos para las sesiones de Zoom y YouTube en vivo y 3Play Media para las versiones bajo demanda y las transcripciones, que ahora forman parte del registro permanente. También escuchamos solicitudes de versiones de “texto sin formato” (sin marcas) de las transcripciones en una versión fácilmente descargable para las personas que usan lectores de Braille. También los suministramos. Puedes ver cómo todos esos recursos se unieron en las páginas como éste, que contienen toda la información sobre una sesión determinada y están vinculados desde la sección correspondiente de la agenda.

Leave a Reply

Your email address will not be published. Required fields are marked *