Problemas con spoilers en VoiceOver

Error
, ,
1

Continuando la discusión de Spoiler blur not compatible with screen readers:

He tenido un informe de un usuario de VoiceOver de que el nuevo código de spoiler no funciona:

¿Alguno de mis compañeros usuarios de lectores de pantalla ha experimentado dificultades con la función de spoilers actualizada en el foro? Al menos ASUMO que ha habido una actualización; solía ser que el texto del spoiler se leía con normalidad sin ninguna indicación de que algo debiera estar oculto, lo cual, por supuesto, no era ideal. La actualización parece haber solucionado este problema al poner el contenido detrás de un área colapsable etiquetada como “mostrar contenido oculto”, pero por alguna razón el texto no se capta cuando presiono el botón para expandirlo/revelarlo. Como referencia, estoy usando Voiceover, el lector de pantalla nativo de Apple, y he notado esto tanto en iOS como en Mac OS.

3 Me gusta
3

Alguien más dijo

Tengo los mismos problemas cuando uso NVDA en Windows.

Y una tercera persona estuvo de acuerdo.

Lo siento, ¡pero no parece que el código actual funcione adecuadamente! Probablemente sería mejor incluso volver al código antiguo.

1 me gusta
6

Hola @Dannii, gracias por identificar este problema. Acabo de publicar una corrección, que ahora debería mejorar el comportamiento para que los lectores de pantalla lean el contenido del spoiler una vez que se activa.

4 Me gusta
7

He actualizado mi foro, pero los usuarios de lectores de pantalla informan que nada ha cambiado para ellos.

1 me gusta
8

¿Estás seguro de que el plugin está actualizado a la última versión? (commit 0ee68da)

Parece que me funciona aquí en Meta con VoiceOver. También estamos usando aria-live como polite para esto, lo que significa que el lector de pantalla no será tan asertivo e disruptivo. En su lugar, esperará a que el usuario esté inactivo para leer el contenido.

Esto se leerá al probarlo

1 me gusta
9

Sí, el plugin de spoiler está en 0ee68da1.

1 me gusta
11

Keegan, ¿puedes decir algo más sobre cómo estás probando esto? Tu captura de pantalla parece un navegador de escritorio. ¿Estás usando VoiceOver de macOS? (¿En qué navegador?)

VoiceOver de macOS es un producto muy diferente de VoiceOver de iOS. Es común que haya errores en VoiceOver de macOS que no aparecen en VoiceOver de iOS, y viceversa. (Por diversas razones, VoiceOver de iOS es mucho más popular entre los usuarios con discapacidad visual que VoiceOver de macOS).

Cuando intenté probar tu publicación https://meta.discourse.org/t/spoiler-issues-with-voiceover/257450/8?u=dfabulich en Safari 16.3.1 de iOS, esto es lo que vi:

Aquí tienes una transcripción:

  • El video comienza con el foco en el video. Luego deslizo hacia la derecha para enfocar el texto difuminado del spoiler.
  • VoiceOver anuncia: “Mostrar contenido oculto. Botón. Contraído. Doble toque para expandir.”
  • Hago doble toque. El texto del spoiler se desenfoca visualmente.
  • VoiceOver anuncia: “Ocultar contenido. Expandido. Ocultar contenido.” Afirmo que esto es un error en Discourse. Debería haber leído el contenido del texto en voz alta, como lo hizo en el video de Keegan.
  • Deslizo hacia la derecha, navegando al siguiente control de la interfaz de usuario.
  • VoiceOver anuncia: “A una persona le gustó esta publicación. Haz clic para ver. Botón de alternancia.”
  • Deslizo hacia la izquierda, volviendo al texto del spoiler desenfocado.
  • VoiceOver anuncia: “Ocultar contenido. Botón. Expandido. Doble toque para contraer.”
  • Luego deslizo hacia la derecha y hacia la izquierda de nuevo solo para comprobar que ocurre el mismo comportamiento, y ocurre.

Tenemos informes de usuarios en el foro intfiction.org de que el desenfoque del spoiler también está roto en NVDA, lo que podría valer la pena probar de tu lado.

2 Me gusta
12

Hola @dfabulich, gracias por compartir estos detalles. Sí, estuve probando principalmente en Chrome (macOS VoiceOver y Windows 11 Narrator).

Investigaré/probaré más y veré si puedo lanzar una solución pronto que resuelva el problema para iOS, NVDA y otros dispositivos importantes.

¡Gracias!

3 Me gusta
13

Sí, ninguno de esos son lectores de pantalla populares ni remotamente, y no deberían ser sus plataformas principales para probar.

Aquí está la principal encuesta de la industria de usuarios de lectores de pantalla, de WebAIM.

https://webaim.org/projects/screenreadersurvey9/ (vuelven a realizar esta encuesta cada pocos años; esta es de 2021)

Ahora, debe leer esta encuesta detenidamente, porque primero habla sobre navegadores de escritorio y tiene un gráfico “Lector de pantalla principal” https://webaim.org/projects/screenreadersurvey9/#primary pero se refiere específicamente al lector de pantalla principal “de escritorio/portátil”.

Ese gráfico indica que “VoiceOver” no es muy popular, pero se refiere a macOS VoiceOver en esa sección. (Si se desplaza hacia abajo hasta la sección “Sistemas operativos”, verá que macOS en sí no es muy popular entre los usuarios de lectores de pantalla).

JAWS para Windows es el lector de pantalla líder, seguido de NVDA para Windows. macOS VoiceOver es un distante tercero. ¡Windows Narrator tiene un uso del 0,5%!

Tenga en cuenta que JAWS cuesta dinero (y su esquema de licencias es oneroso), y NVDA es gratuito. Pero también, NVDA tiende a ser más propenso a errores que JAWS; en mi experiencia, cualquier cosa que funcione en NVDA también funciona en JAWS.

Más tarde, habla sobre “Lectores de pantalla móviles utilizados” https://webaim.org/projects/screenreadersurvey9/#mobilescreenreaders

Ese gráfico muestra que los lectores de pantalla integrados del sistema operativo dominan, con iOS VoiceOver (71,5%) y Android TalkBack (29,1%). (Estos suman más del 100% porque algunas personas usan ambos).

Falta en esta encuesta una encuesta de “tiempo en móvil frente a tiempo en escritorio”, pero, en mi experiencia, la gran mayoría de los informes de errores que escucho de los usuarios de lectores de pantalla provienen de usuarios de iOS y NVDA.

Por lo tanto, recomiendo probar en este orden de prioridad:

  1. iOS Safari VoiceOver. Recomiendo móvil sobre escritorio (porque, afirmo sin datos, que el móvil es significativamente más popular entre los usuarios con discapacidad visual) y iOS sobre Android, porque iOS es abrumadoramente más popular que Android entre los usuarios con discapacidad visual.
  2. Windows NVDA en Chrome. NVDA no es tan popular como JAWS, pero tiene más errores. Cualquier cosa que funcione en NVDA también funcionará en JAWS, pero no necesariamente viceversa.
  3. Windows JAWS en Chrome.
  4. Android TalkBack en Chrome.
  5. macOS VoiceOver en Safari.

Pero creo que encontrará que solo probar en iOS Safari VoiceOver obtiene un excelente valor por su dinero. Normalmente solo pruebo iOS Safari, y luego Windows NVDA en Chrome cuando quiero ser muy minucioso, y luego típicamente me detengo.

Ha pasado al menos cinco años desde que vi a un usuario informar un error que ocurre en Windows JAWS pero no en Windows NVDA. Creo que nunca he visto a un usuario informar un error en Android TalkBack.

4 Me gusta
14

¿Hay algún avance en este problema todavía?

15

aria-live no está diseñado para alternarse. Debes configurarlo en polite al principio y dejarlo así. Con la implementación existente, nunca llega a reconocer que se ha realizado un cambio porque los cambios nunca ocurren mientras está activado.

1 me gusta
16

El problema para mí (NVDA/Windows) parece ser que tienen un div externo con una aria-label. Creo que en la mayoría de los lectores de pantalla, esto no es una anotación del contenido, sino un reemplazo de contenido inaccesible. Al menos, la aria-label es lo único que se lee para mí.

Aquí hay una grabación del spoiler en este hilo: lee el control de tiempo en la parte inferior del video, luego un espacio en blanco (no sé qué es), luego el spoiler visible (“botón expandido ocultar contenido”) y luego el menú desplegable “2 respuestas”.

Tenga en cuenta que si uso la función de depuración de NVDA y paso el mouse sobre el texto expandido para leerlo, lo lee. Pero no he encontrado ninguna forma de hacer que lea el texto sin usar el mouse. Por lo tanto, esa no parece ser una forma válida de probar si es realmente accesible…

2 Me gusta
17

He realizado una PR con algunas mejoras de accesibilidad:

3 Me gusta
19

Gracias @Dannii por la PR :slight_smile:

Acabo de revisarla y he añadido algunos comentarios, solo cosas muy menores, ¡pero por lo demás se ve bien!

1 me gusta
21

Gracias @Dannii, tu PR ha sido fusionado :slight_smile: este problema debería estar resuelto ahora.

2 Me gusta