Problèmes de spoiler avec VoiceOver

Continuant la discussion de Spoiler blur not compatible with screen readers :

J’ai eu un rapport d’un utilisateur de VoiceOver indiquant que le nouveau code de divulgation ne fonctionne pas :

Est-ce que certains de mes collègues utilisateurs de lecteurs d’écran ont rencontré des difficultés avec la fonctionnalité de divulgation mise à jour sur le forum ? Je suppose qu’il y a eu une mise à jour — auparavant, le texte de divulgation se lisait normalement, sans aucune indication que quelque chose était censé être caché, ce qui n’était évidemment pas idéal. La mise à jour semble avoir résolu ce problème en plaçant le contenu derrière une zone rétractable étiquetée « afficher le contenu caché », mais pour une raison quelconque, le texte n’est pas capté lorsque j’appuie sur le bouton pour l’étendre/le révéler. À titre de référence, j’utilise VoiceOver, le lecteur d’écran natif d’Apple, et j’ai remarqué cela sur iOS et Mac OS.

3 « J'aime »

Quelqu’un d’autre a dit

J’ai les mêmes problèmes en utilisant NVDA sous Windows.

Et une troisième personne a été d’accord.

Désolé, mais il semble que le code actuel ne fonctionne pas adéquatement ! Il serait probablement préférable de revenir au code précédent.

1 « J'aime »

Salut @Dannii, merci d’avoir identifié ce problème. Je viens de déployer un correctif, qui devrait maintenant améliorer le comportement afin que les lecteurs d’écran lisent le contenu du spoiler une fois qu’il est activé.

4 « J'aime »

J’ai mis à jour mon forum, mais les utilisateurs de lecteurs d’écran signalent que rien n’a changé pour eux.

1 « J'aime »

Êtes-vous sûr que le plugin est mis à jour vers la dernière version ? (commit 0ee68da)

Cela semble fonctionner ici sur Meta pour moi avec VoiceOver. Nous utilisons également aria-live comme polite pour cela, ce qui signifie que le lecteur d’écran ne sera pas aussi assertif et perturbateur. Au lieu de cela, il attendra que l’utilisateur soit inactif pour lire le contenu.

Tester cela sera lu

1 « J'aime »

Oui, le plugin spoiler est à 0ee68da1.

1 « J'aime »

Keegan, pouvez-vous en dire un peu plus sur la façon dont vous testez cela ? Votre capture d’écran ressemble à un navigateur de bureau. Utilisez-vous VoiceOver sur macOS ? (Dans quel navigateur ?)

VoiceOver sur macOS est un produit très différent de VoiceOver sur iOS. Il est courant qu’il y ait des bugs dans VoiceOver sur macOS qui n’apparaissent pas dans VoiceOver sur iOS, et vice versa. (Pour diverses raisons, VoiceOver sur iOS est beaucoup plus populaire auprès des utilisateurs malvoyants que VoiceOver sur macOS.)

Lorsque j’ai récemment tenté de tester votre publication https://meta.discourse.org/t/spoiler-issues-with-voiceover/257450/8?u=dfabulich sur Safari 16.3.1 sur iOS, voici ce que j’ai vu :

Voici une transcription :

  • La vidéo commence avec le focus sur la vidéo. Je balaye ensuite vers la droite pour focaliser le texte flouté du spoiler.
  • VoiceOver annonce : « Afficher le contenu masqué. Bouton. Réduit. Double-cliquez pour développer. »
  • Je double-clique. Le texte du spoiler est visuellement désactivé.
  • VoiceOver annonce : « Masquer le contenu. Développé. Masquer le contenu. » J’affirme qu’il s’agit d’un bug dans Discourse. Il aurait dû lire le contenu textuel à voix haute, comme il l’a fait dans la vidéo de Keegan.
  • Je balaye vers la droite, en naviguant vers le contrôle d’interface utilisateur suivant.
  • VoiceOver annonce : « Une personne a aimé ce message. Cliquez pour voir. Bouton bascule. »
  • Je balaye vers la gauche, en revenant au texte du spoiler désactivé.
  • VoiceOver annonce : « Masquer le contenu. Bouton. Développé. Double-cliquez pour réduire. »
  • Je balaye ensuite vers la droite et vers la gauche à nouveau juste pour vérifier que le même comportement se produit, et c’est le cas.

Nous avons des rapports d’utilisateurs sur le forum intfiction.org indiquant que le floutage des spoilers est également cassé dans NVDA, ce qui pourrait valoir la peine d’être testé de votre côté.

2 « J'aime »

Salut @dfabulich, merci d’avoir partagé ces détails. Oui, j’ai principalement testé sur Chrome (macOS VoiceOver et Windows 11 Narrator).

Je vais approfondir/tester davantage et voir si je peux publier bientôt un correctif qui résoudra le problème pour iOS, NVDA et d’autres appareils majeurs.

Merci !

3 « J'aime »

Oui, aucun de ces lecteurs d’écran n’est particulièrement populaire et ne devrait pas être votre plateforme principale pour les tests.

Voici la principale enquête sectorielle sur les utilisateurs de lecteurs d’écran, de WebAIM.

\u003chttps://webaim.org/projects/screenreadersurvey9/\u003e (ils refont cette enquête tous les quelques années ; celle-ci date de 2021)

Maintenant, vous devez lire attentivement cette enquête, car elle parle d’abord des navigateurs de bureau et présente un graphique « Lecteur d’écran principal » \u003chttps://webaim.org/projects/screenreadersurvey9/#primary\u003e, mais il fait spécifiquement référence au lecteur d’écran principal « de bureau/portable ».

Ce graphique indique que « VoiceOver » n’est pas très populaire, mais il fait référence à VoiceOver de macOS dans cette section. (Si vous faites défiler jusqu’à la section « Systèmes d’exploitation », vous verrez que macOS lui-même n’est pas très populaire parmi les utilisateurs de lecteurs d’écran.)

JAWS pour Windows est le lecteur d’écran leader, suivi de NVDA pour Windows. VoiceOver de macOS arrive loin derrière en troisième position. Narrator de Windows n’est utilisé qu’à 0,5 % !

Notez que JAWS est payant (et son système de licences est contraignant), et NVDA est gratuit. Mais aussi, NVDA a tendance à être plus bogué que JAWS ; d’après mon expérience, tout ce qui fonctionne dans NVDA fonctionne aussi dans JAWS.

Plus tard, il parle des « Lecteurs d’écran mobiles utilisés » \u003chttps://webaim.org/projects/screenreadersurvey9/#mobilescreenreaders\u003e

Ce graphique montre que les lecteurs d’écran intégrés au système d’exploitation dominent, avec VoiceOver d’iOS (71,5 %) et TalkBack d’Android (29,1 %). (Ces pourcentages s’additionnent à plus de 100 % car certaines personnes utilisent les deux.)

Cette enquête ne comprend pas d’enquête sur le « temps passé sur mobile par rapport au temps passé sur ordinateur », mais, d’après mon expérience, la grande majorité des rapports de bogues que j’entends de la part des utilisateurs de lecteurs d’écran proviennent des utilisateurs d’iOS et de NVDA.

Par conséquent, je recommande de tester dans cet ordre de priorité :

  1. VoiceOver d’iOS Safari. Je recommande le mobile plutôt que le bureau (car, j’affirme sans données, que le mobile est beaucoup plus populaire parmi les utilisateurs malvoyants) et iOS plutôt qu’Android, car iOS est beaucoup plus populaire qu’Android parmi les utilisateurs malvoyants.
  2. NVDA pour Windows sur Chrome. NVDA n’est pas aussi populaire que JAWS, mais il est plus bogué. Tout ce qui fonctionne dans NVDA fonctionnera aussi sur JAWS, mais pas nécessairement l’inverse.
  3. JAWS pour Windows sur Chrome.
  4. TalkBack pour Android sur Chrome.
  5. VoiceOver de macOS sur Safari.

Mais je pense que vous constaterez que le simple fait de tester sur VoiceOver d’iOS Safari offre un excellent rapport qualité-prix. Je teste normalement uniquement sur iOS Safari, puis sur NVDA pour Windows sur Chrome lorsque je veux être très méticuleux, et ensuite je m’arrête généralement.

Cela fait au moins cinq ans que je n’ai pas vu un utilisateur signaler un bogue qui se produit dans JAWS pour Windows mais pas dans NVDA pour Windows. Je pense que je n’ai jamais vu d’utilisateur signaler de bogue sur TalkBack pour Android.

4 « J'aime »

Des progrès sur ce problème ?

aria-live n’est pas censé être activé ou désactivé. Vous devriez le définir sur polite au début et le laisser ainsi. Avec l’implémentation actuelle, il ne parvient jamais à reconnaître qu’un changement a été effectué car les changements ne se produisent jamais pendant qu’il est activé.

1 « J'aime »

Le problème pour moi (NVDA/Windows) semble être que vous avez une div externe avec un aria-label. Je crois que dans la plupart des lecteurs d’écran, ce n’est pas une annotation du contenu, c’est un remplacement pour un contenu inaccessible. Au moins, l’aria-label est la seule chose qui est lue pour moi.

Voici un enregistrement du spoiler dans ce fil de discussion : lecture de la barre de progression en bas de la vidéo, puis d’un espace vide (je ne sais pas ce que c’est), puis du spoiler visible (« bouton développé masquer le contenu ») et ensuite du menu déroulant « 2 réponses ».

Notez que si j’utilise la fonction de débogage de NVDA et que je survole le texte développé pour le lire, il est lu. Mais je n’ai trouvé aucun moyen de le faire lire le texte sans utiliser la souris. Donc, cela ne semble pas être un moyen valide de tester s’il est réellement accessible…

2 « J'aime »

J’ai fait une PR avec quelques améliorations d’accessibilité :

3 « J'aime »

Merci @Dannii pour la PR :slight_smile:

Je viens de l’examiner et d’ajouter quelques commentaires, juste des choses très mineures, mais sinon, ça a l’air bien !

1 « J'aime »

Merci @Dannii, votre PR a été fusionné :slight_smile: ce problème devrait maintenant être résolu

2 « J'aime »