Je ne sais pas si ce problème est connu ou suivi quelque part. Si c’est le cas, je serais ravi de recevoir des liens. Cependant, même si la situation s’améliore, l’expérience d’utilisation de Discourse avec un lecteur d’écran présente encore quelques défis que je souhaitais documenter.
Je suis utilisateur d’un lecteur d’écran et je souhaitais configurer une instance auto-hébergée principalement destinée aux utilisateurs aveugles. En général, je ne recommande pas Discourse en raison de problèmes d’accessibilité, mais vous rendez l’auto-hébergement avec les fonctionnalités que je souhaite très simple, ce qui me rend triste que l’accessibilité ne soit pas tout à fait au point. Voici quelques-uns des défis auxquels je suis confronté :
Les menus déroulants qui sont signalés à mon lecteur d’écran comme des éléments HTML <select/> sont presque entièrement défectueux. Ils se déroulent bien selon les conventions normales du clavier, mais c’est là que s’arrête l’accessibilité. Les problèmes ont commencé lorsque j’ai dû sélectionner une langue lors de la configuration. Je ne suis pas immédiatement certain que « Anglais : États-Unis » ait été sélectionné par défaut, mais lorsque j’ai voulu vérifier, j’avais réussi à définir la langue en espagnol et j’ai eu du mal à revenir en arrière. J’ai finalement trouvé la liste avec mon lecteur d’écran et réussi à la corriger. Mais pratiquement tous les menus déroulants sont défectueux. Je ne veux pas dire « tous » au cas où il y en aurait un quelque part dans un coin éloigné de l’interface qui fonctionne, mais chaque celui que j’ai essayé ne fonctionne pas du tout.
Je ne trouve aucun moyen d’accéder à l’interface d’administration sans naviguer directement. Les écrans de configuration m’ont indiqué qu’elle se trouvait sous l’icône d’engrenage, mais je ne trouve aucune représentation textuelle de ce que pourrait être cette icône, et aucun des contrôles accessibles au clavier que j’ai trouvés ne semble finalement mener à une interface d’administration. Pour l’instant, je me contente d’accéder à /admin, mais cela me fait me demander quels outils je pourrais ne pas découvrir parce que je ne trouve pas cet engrenage.
En lien avec le menu déroulant des paramètres, je ne peux pas utiliser les menus déroulants/sélecteurs en haut des listes de catégories pour naviguer vers les listes de catégories. Je connais le lien Catégories, que j’utilise généralement. Mais il serait agréable que ces sélecteurs fonctionnent.
Chaque fois que je ne m’inscris pas sur un Discourse, on me dit que je devrais le faire en partie parce que le forum se souvient de l’endroit où j’ai arrêté de lire. Cela ne m’a jamais fonctionné avec un lecteur d’écran. Comment est-ce censé fonctionner ? Cliquer sur le lien doit-il déplacer le focus vers le dernier message que j’ai lu ?
Et cela n’est pas lié à mon site, mais l’expérience de l’inscription modale ici présentait quelques défis. J’ai essayé de m’inscrire par e-mail, mais votre instance a rejeté mon adresse e-mail .info que j’utilise depuis près de 17 ans et qui fonctionnait parfaitement sur la mienne. J’ai ensuite m’inscrit via Google, mais la modale qui m’a été présentée à mon retour a posé quelques problèmes :
Elle n’a pas capturé le focus du clavier, donc j’ai dû la chercher et interagir avec elle moi-même.
Pendant que j’essayais de le faire, la liste des sujets défilant à l’infini ajoutait de nouveaux sujets, rendant plus difficile pour le focus d’atteindre réellement la boîte de dialogue. Je ne me souviens plus exactement comment j’ai réussi à me déplacer plus vite que l’apparition des sujets – je n’ai pas encore pris mon café – mais je suis là.
Donc, quelques questions :
Je veux vraiment rester sur Discourse si possible. Combien de ces éléments puis-je modifier sur mon propre site ? En particulier :
Puis-je supprimer les sélecteurs de la liste des catégories, afin que les utilisateurs soient obligés d’interagir avec le lien de la liste des catégories pour l’instant ?
Puis-je supprimer le sélecteur de catégorie sur les pages de nouveaux sujets, afin que les utilisateurs doivent d’abord entrer la catégorie dans laquelle ils souhaitent publier et ne puissent pas accidentellement publier sans catégorie ou se tromper ?
Puis-je faire les deux d’une manière qui facilite les mises à jour ? Je préfère éviter d’éditer les modèles par défaut et de forker le projet si possible, et je ne souhaite pas nécessairement un tout nouveau thème.
Ce travail est-il suivi quelque part, et y a-t-il quelqu’un dédié à sa réalisation ? Les forums Discourse mangent l’internet. Partout où je me tourne, les projets ou les communautés dans lesquels je passe du temps les adoptent. Bon sang, en tant qu’utilisateur aveugle, je veux gérer Discourse car, encore une fois, vous rendez cela si simple. Je ne veux simplement pas que l’accessibilité d’un outil aussi crucial soit soit une réflexion après coup, soit qu’elle doive constamment rattraper le développement.
C’est un post réfléchi @nolan. Je suis sûr que d’autres membres de l’équipe répondront à vos questions, mais pourriez-vous partager votre configuration afin qu’un développeur puisse essayer de reproduire les problèmes que vous rencontrez ? C’est-à-dire quel système d’exploitation, quel lecteur d’écran, etc.
Windows 10, lecteur d’écran NVDA. Bien que, pour le dire avec ménagement, le problème soit suffisamment grave pour qu’il ne fonctionne probablement pas correctement ailleurs ; ainsi, presque n’importe quelle combinaison de système d’exploitation et de lecteur d’écran devrait rencontrer ce problème.
Merci pour vos commentaires ! Nous savons que nous ne sommes pas encore arrivés au bout en matière d’accessibilité et nous y travaillons davantage ces derniers temps. À la fin de l’année 2020, nous avons fait réaliser un audit d’accessibilité par un tiers pour les pages non administratives les plus importantes de Discourse, et nous avons commencé à traiter les problèmes prioritaires au cours des dernières semaines.
Maintenant que vous le mentionnez, je comprends pourquoi il peut être difficile de trouver le menu d’administration. Le lien du menu se trouve dans l’un des menus principaux de l’en-tête… l’aria-label est « aller à une autre liste de sujets ou à une catégorie »… ce qui ne rend clairement pas évident qu’il y a quelques liens d’administration à l’intérieur.
Concernant le message indiquant que Discourse se souvient de l’endroit où vous vous êtes arrêté… le comportement attendu est que, lorsque vous ouvrez un sujet, vous sautiez directement à l’endroit où vous aviez laissé la lecture. Je viens d’essayer de naviguer avec le clavier et je peux confirmer que le focus n’est pas placé au bon endroit.
La plupart de nos menus déroulants sont une implémentation personnalisée, et c’est l’un des domaines qui nous ont été signalés pour amélioration de l’accessibilité. Nous sommes également conscients du fait que nos modales ne piègent pas le focus, ce qui rend certains contenus difficiles d’accès, en particulier sur les pages avec défilement infini, comme vous l’avez expérimenté.
Concernant vos questions sur le fait de rester avec Discourse… tout ce que vous avez listé est possible ; cela nécessiterait quelques lignes de CSS pour masquer ces éléments. Ce CSS devrait être intégré dans un thème, mais il pourrait exister dans un composant de thème, qui peut être ajouté à n’importe quel thème existant (vous n’auriez donc pas besoin de changer votre thème principal). Les thèmes sont bien plus avantageux pour le processus de mise à jour, car ils s’ajoutent par-dessus Discourse… modifier les modèles ou faire un fork comme vous l’avez mentionné rend les mises à jour très difficiles.
Nous étiquetons les rapports de problèmes d’accessibilité ici sur Meta avec le tag accessibility afin qu’ils soient plus faciles à retrouver au même endroit… cela dit, le rapport d’accessibilité réalisé par un tiers et le travail subséquent que j’ai mentionné plus tôt ne sont pas suivis publiquement.
Nous apprécions vraiment vos commentaires, surtout compte tenu de l’effort supplémentaire requis pour les publier. J’espère qu’au cours des prochains mois, Discourse deviendra beaucoup plus facile à utiliser pour vous.
J’ai reçu une question dans une discussion du Fediverse de la part de Robert Kingett, qui a un handicap visuel et se décrit comme « accélérationniste de l’accessibilité » dans son profil. La question était la suivante :
Comment rendez-vous Social Hub accessible aux lecteurs d’écran et aux autres personnes handicapées ? Épilepsie, etc.
Puisque SocialHub utilise Discourse, et que la question portait sur des problèmes d’accessibilité ici, j’ai proposé de copier ce fil sous forme de document Markdown dans un Gist GitHub. Le voici, et il peut être utilisé par d’autres personnes ayant un handicap visuel : Accessibility: Discourse with a screen reader · GitHub
Par ailleurs, si ce point n’a pas encore été soulevé, je souhaiterais le signaler comme une opportunité d’améliorer rapidement l’accessibilité :
Les lecteurs d’écran exploitent efficacement de nombreuses balises sémantiques du HTML 5. Non seulement je peux naviguer entre elles de manière efficace, mais ils annoncent également le type de contenu dans lequel je me trouve actuellement.
Ce serait idéal si les publications étaient placées dans une balise , avec l’en-tête et le pied de page respectivement dans des éléments et . Si le remplacement des éléments n’est pas possible, l’utilisation appropriée des attributs role permet de transmettre le même sens.
Actuellement, il est difficile de lire les longs fils de discussion. Après le premier message, je dois faire défiler la section contenant les sujets recommandés, etc. Ensuite, je lis les messages suivants de manière linéaire, sans moyen de passer outre les mêmes en-têtes que j’ai entendus des milliers de fois, sans aucune différence autre que la date, ni le pied de page avec les mêmes contrôles de message. Bien sûr, des ajustements avancés ARIA pourraient encore améliorer la situation, mais remplacer les balises ou utiliser les rôles constituerait une solution simple et peu coûteuse offrant de nombreux avantages, à mon avis.
J’ai une mise à jour dans notre file d’examen qui ajoutera quelques éléments de balisage ARIA aux pages de sujets. Selon la spécification, il semble logique de baliser les contrôles sous les publications et en bas de la page avec le rôle toolbar.
Nous avons également une zone de barre d’outils de chronologie des sujets qui sert de barre de défilement (je lui ai maintenant attribué le rôle scrollbar) et contient également les boutons « Aller au premier message » et « Aller au dernier message » (auxquels j’ai ajouté des descriptions)…
Ces changements devraient être disponibles avec les mises à jour de Discourse la semaine prochaine.
Cela peut sembler aller de soi, mais je le précise quand même. Il ne suffit pas d’ajouter ARIA à ces contrôles et de considérer la tâche comme terminée. Autrement dit, marquer ces zones comme des barres d’outils sans suivre le modèle de barre d’outils est probablement pire que de ne pas définir de rôle du tout. Si je me retrouve sur une barre d’outils, je m’attends à ce qu’elle se comporte d’une manière que l’ajout du seul rôle ne garantit pas automatiquement. Je veux juste être clair là-dessus, car une erreur courante que je constate lors de l’ajout d’accessibilité est d’ajouter ces rôles sans implémenter les comportements clavier associés. Ensuite, je me retrouve face à une multitude de contrôles qui ne se comportent pas comme je m’y attends, et lutter constamment contre ces attentes est pire que de ne pas en avoir du tout.
J’espère que cela a du sens. Je suis heureux de répondre à d’autres questions.
Salut Chris, le rôle scrollbar n’est peut-être pas exactement ce que tu recherches ici. Il faudra voir cela en action, mais jusqu’à présent, je ne l’ai jamais vu utilisé de cette manière. Il s’agit plutôt d’un élément de type « range » en HTML5 qui représente une position de défilement relative d’un conteneur. Les éléments « Aller au premier message » et « Aller au dernier message » sont de simples boutons qui peuvent déclencher un défilement de la vue, certes, mais je ne pense pas que ces boutons soient appropriés en tant que contenu d’un conteneur de barre de défilement, lequel est requis pour obtenir les attributs aria-value*.
P.S. Dans la communauté VS Code, je suis connu comme le guru des rôles ARIA. Je ne sais pas exactement ce qui m’a valu cette réputation, mais je suis connu pour être pointilleux concernant les rôles. Ils peuvent faire plus de mal que de bien, aussi il faudra peut-être revenir sur ce changement particulier. Je suis presque certain que ce sera le cas.
Par curiosité, avez-vous une personne spécialisée en accessibilité au sein de l’équipe ? Je suis enthousiaste à l’idée de l’audit d’accessibilité récent et des changements prévus à venir, mais comme Discourse alimente une grande partie d’Internet, il serait probablement judicieux qu’une personne disposant d’une expérience de terrain accompagne et conseille ces évolutions. Il est très facile de se tromper et d’aggraver involontairement la situation.
Par exemple, Slack prétend accorder une attention particulière à l’accessibilité et tente d’utiliser ARIA, mais leurs efforts semblent avoir rendu la zone de chat entièrement inaccessible via mon lecteur d’écran. Ou alors, si elle est accessible, je ne parviens pas à le comprendre malgré plusieurs décennies d’expérience. Je ne souhaite pas voir Discourse emprunter involontairement cette voie.
Quoi qu’il en soit, je fais cela et des choses similaires pour vivre, et je suis disponible. J’utilise également plusieurs forums Discourse, donc une accessibilité fiable serait une amélioration tangible de ma qualité de vie. Je suis ravi d’en discuter davantage avec toute personne intéressée.
@MarcoZehe Pour notre contrôle de chronologie, j’étais un peu indécis quant à savoir s’il fallait opter pour le rôle de barre de défilement ou celui de curseur. J’ai choisi le rôle de barre de défilement car le contrôle fait défiler la page et cela correspond à la description donnée par le W3C :
Un objet graphique qui contrôle le défilement du contenu dans une zone de visualisation, que le contenu soit entièrement affiché ou non dans cette zone.
Cela dit, c’est un contrôle assez unique que nous avons développé… il fait à la fois défiler la page et indique où vous vous situez dans la plage actuelle de publications (par exemple, il vous indique que vous êtes actuellement sur le message 6 sur 12). Il est possible qu’il n’existe pas de bonne façon de le marquer pour les lecteurs d’écran, et qu’il vaudrait mieux le masquer… car le défilement normal de la page fonctionne comme prévu sans lui. J’aimerais essayer et voir ce que vous en pensez en action, et si cela ne fonctionne pas, nous pourrons revenir en arrière.
Pour répondre à votre question @nolan, j’ai pris en charge l’organisation des recommandations en matière d’accessibilité et la réalisation de notre audit, mais la plupart de mon expérience précédente en accessibilité provient de la mise en œuvre de spécifications définies par d’autres. Nous n’avons pas d’expert dédié travaillant à temps plein sur l’accessibilité, car nous sommes encore plusieurs ordres de grandeur plus petits que Slack… mais cela pourrait être quelque chose pour lequel nous devrions engager quelqu’un dans l’intervalle afin de bien faire les choses et ne pas empirer les choses…
Merci à vous deux pour vos réponses, j’apprécie vraiment !
Suite au rôle de la barre d’outils, pour clarifier… dites-vous que ce rôle ne vaut rien du tout s’il ne suit pas ce modèle tel que décrit par le W3C ?
Mettez en place la gestion du focus afin que la séquence de tabulation du clavier inclue un point d’arrêt pour la barre d’outils et que les touches fléchées déplacent le focus entre les contrôles de la barre d’outils.
Dans ce cas, je n’implémenterai pas le rôle tant que nous n’aurons pas mis en place correctement le focus et les contrôles par les touches fléchées.
C’est exact : si vous utilisez le rôle, vous vous engagez à mettre en œuvre le patron de conception. Si vous n’êtes pas encore prêt à fournir le patron de conception, n’utilisez pas encore le rôle non plus.
Est-ce l’endroit approprié pour signaler les résultats de mon propre audit d’accessibilité sur une instance Discourse hébergée, ou dois-je ouvrir un nouveau sujet ?
Et :
le rapport d’accessibilité tiers et le travail ultérieur que j’ai mentionnés précédemment ne sont pas suivis publiquement.
Y a-t-il une chance que cette décision soit réexaminée ? Il serait utile d’avoir une certaine transparence à ce sujet que je pourrais partager avec mes clients.
Pour éviter que des éléments ne soient perdus, je recommande de créer un nouveau sujet ux (tagué #accessibilité) pour chaque constat de votre propre audit. Si vos constats sont étroitement liés, il peut être logique d’utiliser le même sujet pour chacun. L’objectif est de regrouper les éléments en petits blocs pouvant être suivis indépendamment et marqués comme « terminés », sans avoir à craindre d’avoir oublié un élément parmi une liste de 53 dans le message initial.
Utiliser le rôle sans implémenter le motif serait un peu comme styliser un élément pour qu’il ressemble à un bouton, puis le rendre réactif uniquement si quelqu’un passe la souris dessus et fait défiler la molette. Si je navigue jusqu’à une barre d’outils ou si je la mets en focus, et qu’elle expose tous ses boutons séparément ou ne répond pas aux flèches, alors cela ressemble à ce bouton étrange de la molette. Il faudrait réfléchir avant chaque interaction, alors qu’il prétend se comporter d’une manière qu’il n’a pas.
J’espère que cela clarifie un peu les choses. Savoir qu’un élément est une barre d’outils n’est utile que s’il se comporte comme une barre d’outils. Sinon, cela distrait.
Aww, c’est décevant. Je suis venu demander quel était le statut de toutes ces mises à jour qui semblaient en cours de déploiement au moment où j’ai posté ce message. Je n’ai pas encore lancé notre communauté, mais l’ancien forum PHP est sur le point de disparaître, donc c’est maintenant ou jamais. J’imaginais qu’il y aurait déjà eu des changements incroyables d’ici là.
Mais je n’ai pas réussi à accéder à la zone d’administration de mon site. Je peux bien sûr atteindre /admin, mais le lien vers le site n’est toujours pas accessible au clavier, peu importe la méthode que j’ai essayée. Cela rend les choses un peu compliquées lorsque je demande à des utilisateurs de lecteurs d’écran de m’aider à modérer.
Ensuite, j’ai essayé de rédiger cette réponse il y a 5 minutes, mais j’ai cliqué par erreur sur un bouton Modifier ou Citer. Cela m’a emmené vers ce qui semblait être une version éditable d’un message précédent que j’avais envoyé. J’ai essayé d’appuyer sur Entrée sur un lien intitulé Annuler, mais cela n’a pas fonctionné. Ni le rechargement de la page. Finalement, j’ai envoyé la réponse, puis j’ai trouvé et interagi avec une modale inaccessible, comme celle que j’avais signalée au départ, pour supprimer le message.
Quelque chose a-t-il changé à cet égard, ou existe-t-il déjà une feuille de route publique ? En tant qu’utilisateur de lecteur d’écran qui doit interagir avec des communautés Discourse qu’il le veuille ou non, je peux faire en sorte que cela fonctionne pour moi, mais je ne me sens pas très à l’aise en demandant à une communauté de personnes aveugles d’utiliser cette plateforme — ou du moins, de construire une communauté qu’elles apprécieraient sur Discourse.
Malheureusement, cela a fait apparaître une fenêtre modale demandant ce que vous souhaitiez faire de votre brouillon (abandonner/enregistrer/annuler), et il semble que la capture du focus de la fenêtre modale soit défectueuse…
Discourse me convient, mais j’aimerais vraiment voir des améliorations en matière d’accessibilité. Cela fait un moment que je n’ai pas utilisé l’interface d’administration ou administré un forum Discourse, mais je m’attendrais à ce que beaucoup de progrès aient été réalisés en trois mois.
Je comprends que ARIA puisse être difficile à mettre en œuvre, mais cela ne signifie en aucun cas qu’on ne peut pas avancer. @nolan, j’ai déjà rencontré le même problème — il m’a fallu un certain temps pour comprendre pourquoi la zone d’édition ne disparaissait pas quand je cliquais sur « Annuler ». J’aimerais vraiment utiliser Discourse comme forum pour ma propre communauté à l’avenir, mais je devrais peut-être y réfléchir à deux fois si des améliorations en matière d’accessibilité ne sont pas apportées. Et je détesterais devoir revenir à PHP.
Vous avez pratiquement quelqu’un qui vous propose de vous aider sur l’accessibilité. Désolé si j’ai l’air impatient — je sais que c’est difficile et que cela vous pose des défis. Mais @nolan et moi-même sommes tout à fait disposés à aider, en tout cas. Je serais ravi de configurer une instance de test Discourse.
