Nous devrions probablement opter pour le rôle pour l’instant… Je soupçonne que passer à H2 casserait beaucoup de thèmes.
Aucun problème, la PR est en cours de préparation.
Cela rend la navigation dans les listes de sujets beaucoup plus agréable avec NVDA : il suffit d’appuyer sur h, h, h pour passer d’un sujet à l’autre.
C’est dommage, h2 ou h3 aurait du sens pour la liste des sujets. Mais ce bateau a probablement pris la mer il y a plus de 8 ans.
Hmm, je ne suis pas sûr de ce que je pense de la nouvelle région. Cela ajoute un tout petit peu de texte supplémentaire à chaque publication, mais je ne pense pas que ce soit si grave, et cela apporte un peu plus de contexte à chaque publication lorsque vous naviguez avec les flèches. Je suppose que nous pouvons l’inverser ultérieurement si cela s’avère que les gens ne l’aiment pas ?
Je suppose que ces changements sont en ligne ici ? Il semble que oui, et ils rendent l’expérience de navigation par sujet beaucoup plus agréable. Merci beaucoup d’avoir agi si rapidement sur ce sujet ! Quand la nouvelle version sera-t-elle déployée sur les sites hébergés ?
Lorsque nous appuierons sur le bouton de déploiement
. Votre site est en cours de déploiement, il devrait être en ligne dans environ 20 minutes.
Je suppose que nous pouvons l’annuler plus tard si cela s’avère que les gens ne l’aiment pas ?
Oui, absolument. Si la communauté des personnes aveugles estime que cela crée plus de bruit qu’il n’est réellement utile, je serai ravi de revenir en arrière.
Les menus déroulants qui sont signalés à mon lecteur d’écran comme des éléments HTML
Nous pourrions éventuellement utiliser les régions ARIA live pour cela ; ARIA live regions - ARIA | MDN. L’exemple courant consiste à annoncer le nombre de résultats après la soumission d’une recherche, mais nous pourrions également utiliser un div vide marqué comme région live et y ajouter du texte du type « réponse publiée » lorsque nécessaire.
Les régions dynamiques ont l’air géniales, elles pourraient même être une solution possible aux problèmes du kit de sélection.
Ah, il semble que role=alert fonctionne également très bien avec nos différentes erreurs, je l’ajoute maintenant !
@nolan quelques corrections/améliorations supplémentaires aujourd’hui. (note : je réalise tous mes tests avec NVDA)
-
Si vous essayez de publier un message trop court, nous affichons un rôle ARIA d’alerte, ce qui permet au lecteur d’écran de vous indiquer ce qui ne va pas (message trop court, etc.).
-
J’ai amélioré la logique de focus des « modales » : nous mettrons désormais le focus sur les modales sans condition. Cela vous permettra de découvrir les différents raccourcis clavier. Un lien vers eux se trouve dans la section « Aller vers une autre liste de sujets ou une catégorie ».
Les modifications sont en cours de déploiement sur votre site.
Faites-moi savoir ce que vous en pensez !
Bon, je vais peut-être être un peu pointilleux ici. Mais la façon dont les sujets sont listés est un peu étrange. On dirait que toute la ligne est marquée comme un titre et non les colonnes individuelles. Comme je l’ai dit, c’est vraiment un détail mineur, donc je suis peut-être juste en train de chipoter.
Wow, ce sujet a visiblement fait beaucoup de bruit. Je suppose que l’activation des notifications du navigateur empêche la réception des e-mails — je dois vérifier si je peux corriger cela.
Ces changements sont excellents ! Merci pour eux !
Je suis d’accord sur le fait que les titres de la liste des sujets sont un peu étranges. Je préférerais que les titres n’englobent que les informations absolument essentielles, car si je veux le reste, je sais où le trouver.
Si vous regardez l’affichage des messages, par exemple, le rôle h2 que j’ai ajouté entoure uniquement le nom et l’heure du message. Ce sont probablement les détails qui m’intéressent le plus lorsque j’appuie sur h/H pour naviguer d’un message à l’autre. Pour la liste des sujets, je m’intéresse probablement uniquement au titre et à rien d’autre.
Ethin, j’espère que nous parlons du même problème ici et que j’ai bien compris votre intention. Faites-moi savoir si je me trompe.
Je tiens également à souligner, @Sam, que ce n’est pas compatible avec Orca. Je ne sais pas si @Ethindp peut aider pour la chasse aux bugs sous Linux ou autre, mais du moins, sur mon système (Ubuntu avec Orca/Firefox), les menus déroulants fonctionnent un peu.
Par exemple, si je crée un sujet, je peux développer le menu déroulant des catégories et saisir une catégorie. Je peux ouvrir la sélection d’état, mais si j’essaie d’ouvrir ce menu, il se comporte comme un bouton : je dois appuyer aveuglément (jeu de mots voulu) sur le menu des états et espérer tomber sur ce que je cherche. Je ne connais pas assez Orca ou les événements ATSPI pour savoir si ce qui fonctionne pour un lecteur d’écran fonctionnera aussi avec Orca, ou si cela demanderait plus de travail.
Vous ne pouvez pas contrôler les événements atspi depuis Firefox, donc ce n’est pas un problème. Le problème réside simplement dans le rôle présenté au lecteur d’écran : indiquez au navigateur, via ARIA, qu’un contrôle est une liste déroulante s’il se comporte comme tel. Rappelez-vous : suivez les modèles de conception ARIA, sauf si ce que vous essayez de faire n’a pas de modèle de conception (ce qui, je l’imagine, est assez rare ; ce document est très complet).
@nolan Oui, c’est bien à cela que je faisais référence. La navigation dans le tableau via les en-têtes (et les messages) me ralentit car :
- Toutes les colonnes sont des en-têtes, ou plusieurs en-têtes — cela se lit comme plusieurs. Donc, cela se lit ainsi : titre du sujet. Pause. Informations sur le sujet. Pause. Informations sur le sujet. Pause. etc. Orca, contrairement à NVDA, lit une ligne entière du tableau lors de la navigation avec les flèches (ou, dans ce cas, en utilisant la touche h pour y naviguer), au lieu de lire les colonnes individuellement comme le fait NVDA.
- Les messages sont similaires. Toutes les informations sur le message sont, encore une fois, des en-têtes séparés et sont lus comme décrit ci-dessus.
Une solution consisterait à fusionner les colonnes respectives contenant uniquement les informations importantes en un seul en-tête, si cela ne brise pas la mise en page visuelle. (Pour être honnête, je n’aime pas vraiment la navigation par en-têtes dans un tableau — ce n’est tout simplement pas ainsi qu’un tableau fonctionne, et les en-têtes ne sont pas vraiment censés être utilisés de cette manière.)
Un dernier petit problème : tous les en-têtes semblent être au même niveau. Cela pose problème car les lecteurs d’écran me permettent de naviguer sur la page en fonction des différents niveaux. Comme tous les en-têtes sont au même niveau, je ne peux pas sauter entre l’en-tête du sujet et l’en-tête des messages connexes — je dois donc lire l’intégralité du sujet, ce qui devient fastidieux, en particulier pour les sujets comportant un grand nombre de messages.
Pour le moment, nous avons le rôle d’en-tête ARIA sur toute la ligne. Je vais le déplacer pour qu’il ne s’applique qu’aux informations essentielles, à la première colonne du grand tableau (statut, titre, catégorie, nombre de messages non lus, etc.).
Devrais-je aller plus loin et placer le rôle uniquement sur le titre du sujet ? Je suppose que cela rend les choses un peu plus rapides, à condition de se rappeler de naviguer vers la gauche et la droite pour obtenir des informations sur le statut du sujet, la catégorie, etc.
@celtichawk merci ! @j.jaffeux est en train de chercher une solution pour les menus déroulants compatible avec JAWS, Orca et NVDA. Comme je l’ai mentionné, cela peut prendre un peu de temps, mais nous y travaillons actuellement et espérons pouvoir vous montrer quelque chose dans les prochaines semaines.
@ethindp Je pense avoir une idée pour la situation des en-têtes dans les sujets. Nous pouvons appliquer le rôle d’en-tête à un seul élément, comme “nom d’utilisateur”, puis lui attribuer une description ARIA du type “Sam a publié il y a 3 heures”. Ainsi, je suppose que cela s’afficherait comme suit :
“Région du message #3 Sam a publié il y a 3 heures” lorsque vous naviguez. Devrions-nous essayer cela ?
Je dirais que tu devrais essayer. J’aime vraiment cette idée. (Mon Dieu, les modèles sont géniaux !)
Hmm, la première colonne est probablement suffisante. En jouant un peu plus avec, j’aime le fait qu’elle lise non seulement le titre, mais aussi le statut de non-lu et le nombre de messages non lus. Je suppose que je pourrais m’en accommoder en laissant le reste être lu comme maintenant, car heureusement, cela est lu en dernier. Mais uniquement la première colonne correspond davantage à ce que j’attendrais.
Salut Nolan,
J’envisageais de modifier cela aujourd’hui, mais l’élément TD a déjà le rôle « rowheader ». Je crains de toucher à cela.
J’ai plusieurs options ici :
-
Changer le rôle sur le
TD(colonne de tableau) contenant toutes les informations clés. -
Ajouter le rôle sur le
SPANlink-top-line, qui contient des informations critiques mais exclut les catégories et les tags. -
Je ne veux vraiment pas le faire, mais nous pourrions ajouter un
DIVconteneur.
Quelle solution devrions-nous choisir ici ?
Claus a également soulevé des problèmes concernant le rôle de titre, qui est assez capricieux. Je pense que nous pourrions simplement attribuer le rôle de titre au seul élément « lien ».
De cette façon :
- Vous n’entendez aucune information sur le statut (verrouillé, épinglé, etc.)
- Vous appuyez sur H
- Vous entendez le titre du sujet
- Vous appuyez sur H
- Vous entendez le titre du sujet suivant
Si à tout moment vous souhaitez découvrir des particularités du sujet ou interagir de manière plus riche, appuyez sur la flèche haut ou bas pour obtenir plus d’informations.
Ce n’est pas une solution parfaite, mais cela semble être une amélioration par rapport au fait de se retrouver sur le lien « épinglé » ou d’avoir toute la ligne lue à haute voix.
En fait, l’utilisation d’un tableau pour afficher la liste des sujets d’un forum est vraiment excellente. Tous les lecteurs d’écran que je connais, à l’exception d’Orca, peuvent naviguer dans les tableaux. Si vous obtenez les bonnes informations sur les lignes et les colonnes, la navigation est efficace. La raison de demander des en-têtes pour les sujets était d’obtenir un moyen stable de naviguer dans un sujet ouvert. Je ne vois pas de bonnes raisons d’ajouter des en-têtes dans le tableau, mais si cela est bien fait, cela ne pose pas de problèmes.
Claus
Salut.
Je tiens à remercier chaleureusement les personnes de ce fil. J’administre quelques instances Discourse et j’ai remarqué la plupart des points évoqués ici. Je n’aurais jamais pris la peine de réfléchir à des solutions jusqu’à hier, où l’un des forums a été mis à jour et les choses ont changé, pour le mieux !
En tombant sur ce fil ce matin, je ressens beaucoup d’optimisme quant à la poursuite de cette amélioration.
Je n’ai pas beaucoup de suggestions précises ; vous avez couvert la plupart de mes points de friction, donc je dirais de continuer dans cette voie.
Il y en a un qui, à ma connaissance, n’a pas été mentionné, du moins pas dans ce fil : un moyen accessible de citer quelqu’un dans un fil. Quand je veux citer quelqu’un, je le fais généralement ainsi :
insérer la citation ici.
Mais j’aimerais pouvoir utiliser la méthode de citation appropriée. Je ne connais pas assez le Markdown pour l’écrire directement, et même si c’était le cas, cela semblerait un peu fastidieux. Je suis curieux de savoir quelles autres astuces les gens utilisent pour citer d’autres personnes dans un fil, surtout si vous ne pouvez pas utiliser de souris ?