Problème 1 : Navigation dans les en-têtes cassée / Manipulation du DOM

Problème : Les éléments de publication de réponse ne sont pas initialement affichés sur le Document Object Model (DOM) lors du chargement initial de la page et sont supprimés du DOM après que le lecteur d’écran les a parcourus, ce qui fait que les lecteurs d’écran Windows perdent l’accès au contenu et que VoiceOver est limité dans les outils qui peuvent être utilisés pour accéder à la page.

Comportement spécifique :

● Lors de la tentative de navigation de la publication principale vers les publications de réponse, les éléments utilisés dans les publications de réponse n’ont pas encore été rendus sur le DOM, par conséquent, les utilisateurs ne peuvent pas utiliser la navigation rapide pour naviguer vers n’importe quel élément dans n’importe quelle publication de réponse.

● Les publications de réponse individuelles sont marquées comme titre de niveau 2 dans le DOM uniquement lorsque le lecteur d’écran est focalisé sur elles, obligeant les utilisateurs à naviguer sur chaque élément de la page afin d’atteindre les publications de réponse.

● L’outil d’accessibilité ANDI affiche une structure de titres en constante évolution après les interactions avec les éléments.

● Les éléments affichent des erreurs « supprimés du DOM » lors de la tentative d’accès à ceux-ci.

● Le lecteur d’écran perd la vue cohérente de la structure de la page.

Détails de la plateforme :

● JAWS/NVDA : Échec complet - impossible d’accéder aux titres de réponse.

● VoiceOver : Accès via la navigation rapide mais pas d’accès au rotor - car VoiceOver fonctionne en lisant la page directe, les utilisateurs peuvent naviguer dans les titres de réponse à l’aide des touches de navigation rapide, cependant seuls les éléments sur lesquels le lecteur d’écran est focalisé sont accessibles dans le rotor.

Pourquoi critique : Les utilisateurs de lecteurs d’écran ne peuvent pas accomplir la tâche essentielle de lire les réponses aux discussions. C’est une barrière totale à la participation aux discussions.

2 « J'aime »

Ces problèmes ont été signalés pour la première fois sur Screen Reader Accessibility issues . Veuillez aider à résoudre ce problème, car toute notre communauté d’utilisateurs aveugles et malvoyants est incapable d’accomplir des fonctions de base sur le forum de discussion.

2 « J'aime »

Merci de nous avoir signalé ces problèmes !

Savez-vous sur quel(s) sujet(s) cela a été testé spécifiquement ? Il serait utile d’avoir une référence commune pour nous assurer que nous constatons les mêmes problèmes, car il existe de nombreuses variations dans le contenu des publications. J’aimerais m’assurer que nous concentrons nos efforts au bon endroit.

Nous pourrions utiliser try.discourse.org, ou nous pouvons utiliser une publication ici sur Meta comme référence si cela peut aider.

Par “navigation rapide”, semble-t-il que vous signaliez spécifiquement les listes d’éléments ? Je peux confirmer qu’en NVDA et VoiceOver, seuls les contenus actuellement disponibles dans le DOM peuvent être accédés dans les listes d’éléments. C’est également vrai pour les utilisateurs voyants et c’est une partie fondamentale du fonctionnement de Discourse. En l’absence de pagination manuelle, nous chargeons/déchargeons le contenu au fur et à mesure que quelqu’un fait défiler la page vers le bas/le haut.

C’est généralement ce que j’attends lorsque quelqu’un mentionne la “navigation rapide”, bien que je réalise qu’il n’y a pas toujours une terminologie cohérente entre les applications.

J’ai confirmé que la navigation d’élément à élément fonctionne dans NVDA et VoiceOver, mais j’ai identifié un problème avec nos “petites publications” dans les sujets qui peut empêcher la navigation de continuer et j’appliquerai une correction pour cela.

Une “petite publication” est une mise à jour de statut du sujet comme épinglée, fermée/ouverte, activée, etc. Le problème avec celles-ci est qu’elles n’ont pas de titre interne comme les publications régulières, donc lorsqu’elles tombent sur le seuil avant que d’autres publications ne soient chargées lors de la navigation… un utilisateur peut être arrêté et entendre seulement “pas de titre suivant”.

Les outils automatisés comme ANDI échouent souvent à reconnaître les changements du DOM dans les applications web comme Discourse, ils sont généralement conçus pour des scénarios plus simples comme les pages statiques. Donc, bien que nous utilisions parfois ces outils pour identifier nous-mêmes les problèmes, dans des scénarios plus complexes comme la navigation, nous devons nous concentrer sur ce que nous pouvons reproduire avec des tests manuels.

Je suppose que cela fait également référence aux listes d’éléments ? C’est attendu, mais peut-être y a-t-il une amélioration que nous pouvons envisager pour que les listes d’éléments fonctionnent dans Discourse, je peux en discuter avec nos ingénieurs pour avoir leur avis.

Est-ce également spécifiquement dans une liste d’éléments ? Comme mentionné ci-dessus, j’ai testé la navigation NVDA et VoiceOver pour la navigation d’élément à élément, et je peux confirmer que cela fonctionne… mais s’il y a un contexte spécifique où cela ne fonctionne pas, nous pouvons examiner de plus près.

3 « J'aime »

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

Les activités express ont été testées.

1 « J'aime »

Mise à jour rapide à ce sujet, j’ai travaillé à l’amélioration de nos points de repère d’une manière qui devrait offrir une meilleure façon de naviguer dans une liste d’éléments.

La navigation dans les titres des listes d’éléments restera inchangée, mais j’espère que cela offrira une alternative raisonnable. Les changements sont décrits ici : A11Y: improve landmark navigation and add aria-labels to post controls by awesomerobot · Pull Request #34421 · discourse/discourse · GitHub

En bref, ce que cela fait :

  • Fournir des régions de repères pour tous les messages dans le DOM
  • Ajoute une région de repère qui indique plus clairement qu’il y a d’autres messages au-dessus/en dessous — nous chargeons/déchargeons des messages afin de ne pas avoir à utiliser la pagination manuelle, si un sujet avait des centaines de messages chargés dans le DOM à la fois, cela pourrait causer des problèmes de performance.

Rendre tout le contenu des titres accessible dans le DOM sans dégrader les performances pour tout le monde serait un changement très compliqué, c’est donc un peu un compromis. Bien que ce ne soit pas parfait, la navigation vers les zones « charger plus de contenu » chargera correctement plus de messages, auquel cas la liste d’éléments pourra être rouverte.

  • J’ai mis à jour les contrôles de message d’une région de navigation à une région de barre d’outils, c’est plus précis sémantiquement et permet à la liste des régions de repères de se concentrer sur les messages.

  • J’ai également amélioré l’étiquetage des contrôles de message pendant que j’y étais

Nous passons donc d’une liste d’éléments de repère plutôt clairsemée dans les sujets

À quelque chose qui représente plus clairement la structure du sujet

Cette mise à jour devrait être disponible dans le courant de la semaine. Je serai curieux d’entendre vos commentaires sur ces changements une fois qu’ils seront disponibles @adress !

4 « J'aime »

Salut @awesomerobot, nous avons été engagés par APH pour une consultation en accessibilité sur ce problème. J’ai fourni deux liens vidéo ci-dessous montrant notre problème principal lié à ce fil de discussion. Vous verrez le problème dans le premier enregistrement à partir de l’horodatage 08:36 dans le premier enregistrement.
Audit d’accessibilité Discourse JAWS
Cela n’est pas lié à la liste d’éléments, mais à ce que nous appellerions des touches rapides ou une navigation rapide, dans laquelle nous naviguerons vers le type d’élément HTML suivant (dans ce cas, les titres).

Le problème avec la résolution de ce problème en créant de nouveaux points de repère est que les points de repère sont généralement réservés aux sections de haut niveau, donc pour un utilisateur de lecteur d’écran, la navigation entre de petites sections de la page avec des points de repère supprimerait l’accès rapide aux grandes régions de la page comme la bannière de navigation. Ceci est également en violation des normes WCAG de niveau A créant un contournement de bloc.

1 « J'aime »

Super, merci pour ces détails supplémentaires ! Une vidéo serait d’une grande aide. Il semble que la vidéo soit protégée par un mot de passe. Pouvez-vous soit la déverrouiller, soit envoyer le code à accessibility@discourse.org

1 « J'aime »

Oui, désolé pour cela. Voici le lien avec le code d’accès intégré. Video Conferencing, Web Conferencing, Webinars, Screen Sharing - Zoom
Code d’accès : .kBwdK3a

1 « J'aime »

Salut @awesomerobot, je suis un collègue de Cody et un ingénieur en accessibilité. J’ai examiné le dépôt pour diagnostiquer le problème. Comme vous le savez peut-être déjà, le problème principal semble être que (1) le contenu des publications masquées n’est pas visible par les lecteurs d’écran et (2) les publications ne sont démasquées que lorsqu’elles sont dans la vue d’un utilisateur par PostStreamViewportTracker.

En réfléchissant à une solution potentielle, je souhaite optimiser deux points : (1) permettre la navigation dans chaque publication par titre avec les lecteurs d’écran et (2) minimiser les modifications du dépôt Discourse et l’impact sur les performances.

L’approche que je recommande est de conserver un wrapper léger pour chaque publication chargée qui inclut le H2 sémantique utilisé pour la navigation par titre, tandis que le corps de publication lourd reste masqué. Cela maintient les titres stables pour les technologies d’assistance sans gonfler le DOM sur toute la page. Lorsqu’un utilisateur arrive sur le H2 d’une publication par navigation par titre, le lecteur d’écran déclenche un défilement de page qui, à son tour, démasque le corps de la publication sur place.

La viabilité de cette solution dépend du moment où le prochain bloc de publications est chargé. Une amélioration facultative est un titre sentinelle uniquement pour les lecteurs d’écran « charger plus de publications » (similaire à la « région de chargement supplémentaire » proposée dans votre PR) situé en bas de la liste des publications chargées. Lorsque ce titre entre en vue ou est sélectionné à partir du rotor des titres, il charge le bloc suivant et annonce l’achèvement via un message aria-live=polite.

3 « J'aime »

Merci pour vos commentaires et suggestions, nous en discuterons en interne et reviendrons avec une mise à jour !

1 « J'aime »

C’est l’approche sur laquelle nous travaillons actuellement dans A11Y: improve heading-to-heading nav, fix infinite scrolling for screenreaders by awesomerobot · Pull Request #34589 · discourse/discourse · GitHub

Comme vous l’avez suggéré, nous ajoutons des titres légers uniquement pour les lecteurs d’écran sur toutes les publications (masquées ou non) ainsi qu’un titre qui déclenchera le chargement de publications supplémentaires, ainsi que l’annonce que le chargement est terminé.

C’est encore en cours de développement, donc cela nécessitera encore quelques ajustements, mais nous espérons pouvoir proposer ce correctif à tout le monde bientôt.

1 « J'aime »

Mise à jour rapide sur les attentes du calendrier : nous sommes en période de gel pré-lancement pour la semaine prochaine environ et une grande partie de notre équipe sera absente pour notre rencontre annuelle… il faudra donc probablement quelques semaines avant que ce changement ne puisse être appliqué.

2 « J'aime »

Bonjour ! Depuis le 5 novembre, nous avons intégré une mise à jour qui devrait améliorer la navigation par sujet via les titres. Plus de détails ici :

4 « J'aime »