Problema 1: Navegación de encabezado rota / Manipulación del DOM

Problema: Los elementos de las publicaciones de respuesta no se muestran inicialmente en el Modelo de Objetos del Documento (DOM) en la carga inicial de la página y se eliminan del DOM después de que el lector de pantalla los ha procesado, lo que provoca que los lectores de pantalla de Windows pierdan el acceso al contenido y que VoiceOver tenga limitaciones en las herramientas que se pueden utilizar para acceder a la página.

Comportamiento específico:

● Al intentar navegar desde la publicación principal a las publicaciones de respuesta, los elementos utilizados en las publicaciones de respuesta aún no se han renderizado en el DOM, por lo que los usuarios no pueden utilizar la navegación rápida para navegar a ningún elemento en ninguna publicación de respuesta.

● Las publicaciones de respuesta individuales se marcan como encabezado de nivel 2 en el DOM solo cuando el lector de pantalla se enfoca en ellas, lo que requiere que los usuarios naveguen por cada elemento de la página para llegar a las publicaciones de respuesta.

● La herramienta de accesibilidad ANDI muestra una estructura de encabezados en constante cambio después de las interacciones con los elementos.

● Los elementos muestran errores de “eliminado del DOM” al intentar acceder a ellos.

● El lector de pantalla pierde la vista coherente de la estructura de la página.

Detalles de la plataforma:

● JAWS/NVDA: Fallo completo: no se puede acceder a los encabezados de respuesta en absoluto.

● VoiceOver: Acceso a través de la navegación rápida pero sin acceso al rotor; dado que VoiceOver funciona leyendo la página directamente, los usuarios pueden navegar por los encabezados de respuesta utilizando las teclas de navegación rápida; sin embargo, solo los elementos en los que el lector de pantalla está enfocado son accesibles dentro del rotor.

Por qué es crítico: Los usuarios de lectores de pantalla no pueden completar la tarea clave de leer las respuestas de las discusiones. Esto es una barrera total para participar en las discusiones.

2 Me gusta

Estos problemas se informaron por primera vez en Screen Reader Accessibility issues . Por favor, ayuden a resolverlos, tenemos toda una comunidad de usuarios ciegos y con baja visión que no pueden completar funciones básicas en el tablón de discusiones.

2 Me gusta

¡Gracias por informar de esto!

¿Sabes en qué tema(s) se probó específicamente? Sería útil tener una referencia compartida para asegurarnos de que estamos viendo los mismos problemas, hay muchas variaciones en el contenido de las publicaciones, así que me gustaría asegurarme de que estamos enfocando nuestros esfuerzos en el lugar correcto.

Podríamos usar try.discourse.org, o podemos usar una publicación aquí en Meta como referencia si eso ayuda.

Por “navegación rápida”, ¿parece que te refieres específicamente a las listas de elementos? Puedo confirmar que tanto en NVDA como en VoiceOver, solo el contenido actualmente disponible en el DOM se puede acceder en las listas de elementos, esto también es cierto para los usuarios videntes y es una parte fundamental de cómo funciona Discourse. En lugar de paginación manual, cargamos/descargamos contenido a medida que alguien se desplaza hacia arriba/abajo en la página.

Esto es lo que normalmente espero cuando alguien menciona “navegación rápida”, aunque me doy cuenta de que no siempre hay una terminología consistente entre las aplicaciones.

He confirmado que la navegación de elemento a elemento funciona en NVDA y VoiceOver, pero he identificado un problema con nuestras “publicaciones pequeñas” dentro de los temas que puede impedir que la navegación continúe y aplicaré una solución para ello.

Una “publicación pequeña” es una actualización de estado del tema como fijada, cerrada/abierta, activada, etc. El problema con estas es que no tienen un encabezado interno como las publicaciones normales, por lo que cuando caen en el umbral antes de que se carguen más publicaciones al navegar… un usuario puede detenerse y solo escuchar “no hay siguiente encabezado”.

Las herramientas automatizadas como ANDI a menudo no reconocen los cambios del DOM en aplicaciones web como Discourse, generalmente están diseñadas para escenarios más simples como páginas estáticas. Por lo tanto, aunque a veces usamos estas herramientas para identificar problemas nosotros mismos, en escenarios más complejos como la navegación, tenemos que centrarnos en lo que podemos reproducir con pruebas manuales.

¿Supongo que esto también se refiere a las listas de elementos? Esto es lo esperado, pero quizás haya una mejora que podamos considerar para que las listas de elementos funcionen en Discourse, puedo plantear esto a nuestros ingenieros para obtener su opinión.

¿Esto también es específicamente en una lista de elementos? Como se mencionó anteriormente, he probado la navegación de NVDA y VoiceOver para la navegación de elemento a elemento, y puedo confirmar que funciona… pero si hay un contexto específico en el que no funciona, podemos examinarlo más de cerca.

3 Me gusta

Latest Expanded Core Curriculum/Mastering the Monarch topics - APH Hive Discussion Board

Se probaron las actividades expresas.

1 me gusta

Actualización rápida sobre esto, he estado trabajando en mejorar nuestros puntos de referencia de una manera que debería proporcionar una mejor forma de navegar por una lista de elementos.

La navegación por encabezados en listas de elementos permanecerá sin cambios, pero esperamos que esto proporcione una alternativa razonable. Los cambios se describen aquí: A11Y: improve landmark navigation and add aria-labels to post controls by awesomerobot · Pull Request #34421 · discourse/discourse · GitHub

En resumen, esto hace lo siguiente:

  • Proporciona regiones de puntos de referencia para todas las publicaciones en el DOM
  • Agrega una región de punto de referencia que deja más claro que hay más publicaciones arriba/abajo: cargamos/descargamos publicaciones para no tener que usar paginación manual, si un tema tuviera cientos de publicaciones cargadas en el DOM a la vez, podría causar problemas de rendimiento.

Hacer que todo el contenido de los encabezados sea accesible en el DOM sin degradar el rendimiento para todos sería un cambio muy complicado, por lo que este es un punto intermedio. Aunque no es perfecto, navegar a las áreas de “cargar más contenido” cargará correctamente más publicaciones, momento en el cual la lista de elementos se puede reabrir.

  • He hecho una actualización para cambiar los controles de publicación de una región de navegación a una región de barra de herramientas, esto es semánticamente más preciso y permite que la lista de regiones de puntos de referencia se centre en las publicaciones.

  • También he mejorado el etiquetado de los controles de publicación mientras estaba en ello.

Así que pasamos de una lista de elementos de puntos de referencia bastante escasa dentro de los temas

A algo que representa más claramente la estructura del tema

Esta actualización debería estar disponible en algún momento de esta semana. Tendré curiosidad por escuchar sus comentarios sobre estos cambios una vez que estén disponibles @adress!

4 Me gusta

Hola @awesomerobot, hemos sido contratados por APH para realizar una consulta de accesibilidad sobre este problema. A continuación, he proporcionado un par de enlaces de video que muestran nuestro problema principal relacionado con este hilo. Verá el problema en la primera grabación a partir de la marca de tiempo 08:36 en la primera grabación.
Auditoría de accesibilidad de Discourse JAWS
Esto no está relacionado con la lista de elementos, sino con lo que llamaríamos Teclas Rápidas o Navegación Rápida, en la que navegaremos al siguiente tipo de elemento HTML (en este caso, encabezados).

El problema al solucionar este problema creando nuevos puntos de referencia es que los puntos de referencia suelen reservarse para secciones de alto nivel, por lo que para un usuario de lector de pantalla, navegar entre pequeñas secciones de la página con puntos de referencia eliminaría el acceso rápido a las grandes regiones de la página, como el banner de navegación. Esto también viola los estándares WCAG de nivel A, creando un Bypass Block.

1 me gusta

genial, ¡gracias por los detalles adicionales! un video ayudará enormemente; parece que el video está protegido con contraseña, ¿puedes desbloquearlo o enviar el código a accessibility@discourse.org?

1 me gusta

Sí, lo siento. Aquí tienes el enlace con la contraseña incrustada. Video Conferencing, Web Conferencing, Webinars, Screen Sharing - Zoom
Contraseña: .kBwdK3a

1 me gusta

Hola @awesomerobot, soy colega de Cody y un ingeniero de accesibilidad. He revisado el repositorio para diagnosticar el problema. Como ya sabrás, el problema principal parece ser que (1) el contenido de las publicaciones ocultas no es visible para los lectores de pantalla y (2) las publicaciones solo se muestran cuando están dentro de la vista de un usuario según PostStreamViewportTracker.

Pensando en una posible solución, quiero optimizar dos cosas: (1) habilitar la navegación de cada publicación por encabezado con lectores de pantalla y (2) minimizar los cambios en el repositorio de Discourse y el impacto en el rendimiento.

El enfoque que recomiendo es mantener un wrapper ligero para cada publicación cargada que incluya el H2 semántico utilizado para la navegación por encabezados, mientras que el cuerpo pesado de la publicación permanece oculto. Esto mantiene los encabezados estables para la tecnología de asistencia sin inflar el DOM en toda la página. Cuando un usuario llega a cualquier H2 de una publicación a través de la navegación por encabezados, el lector de pantalla activará un desplazamiento de página que, a su vez, mostrará el cuerpo de la publicación en su lugar.

La viabilidad de esta solución depende de cuándo se cargue el siguiente bloque de publicaciones. Una mejora opcional es un encabezado centinela solo para lectores de pantalla “cargar más publicaciones” (similar a la “región de carga de más” propuesta en tu PR) ubicado en la parte inferior de la lista de publicaciones cargadas. Cuando este encabezado entra en vista o se selecciona del rotor de encabezados, carga el siguiente bloque y anuncia la finalización a través de un mensaje aria-live=polite.

3 Me gusta

¡Gracias por los comentarios y sugerencias, discutiremos esto internamente y volveremos con una actualización!

1 me gusta

Este es el enfoque en el que estamos trabajando actualmente en A11Y: improve heading-to-heading nav, fix infinite scrolling for screenreaders by awesomerobot · Pull Request #34589 · discourse/discourse · GitHub

Como sugirió, estamos agregando algunos encabezados ligeros solo para lectores de pantalla en todas las publicaciones (ocultas o no), así como un encabezado que activará la carga de más publicaciones, junto con el anuncio de que la carga se ha completado.

Todavía es un trabajo en progreso, por lo que aún necesitará algo de refinamiento, pero esperamos poder ofrecer esta solución a todos pronto.

1 me gusta

Actualización rápida sobre las expectativas del cronograma: estamos en un bloqueo de pre-lanzamiento durante la próxima semana más o menos y gran parte de nuestro equipo estará fuera en nuestra reunión anual… así que probablemente pasarán un par de semanas antes de que este cambio pueda implementarse.

2 Me gusta

¡Hola! A partir del 5 de noviembre, hemos implementado una actualización que se espera que mejore la navegación por temas mediante encabezados. Más detalles aquí:

4 Me gusta