Accessibilité de ZDS aux lecteurs d'écran et au clavier

Bonjour,

Pour ceux qui ne seraient pas encore au courant, je suis un utilisateur de lecteur d'écran. Si vous ne savez pas ce que c'est, je vous invite à vous renseigner sur wikipédia.

ZDS étant je pense un projet assez ouvert et commençant à atteindre une taille intéressante, je pense qu'il serait temps de se pencher sur l'accessibilité du site aux lecteurs d'écran et au clavier, de même qu'à la sémantique moderne. Même si personnellement je classe ce site déjà assez haut par rapport à d'autres sites que je visite régulièrement (et notamment plus haut que le méchant concurrent qui s'appelle open et qui n'est pas ouvert), il y a toujours moyen de s'améliorer.

Je crée ce topic unique pour recenser tous les bugs et les suggestions liées à l'accessibilité et à la sémantique; je pense qu'il est inutile de créer un topic différent pour chaque problème rencontré.

Ma première requête va être la suivante: améliorer la simplicité d'utilisation des pages « liste de topics » pour le clavier. Je dis première requête parce qu'il risque d'y en avoir bientôt d'autres.

Les pages « liste de topics » est à mon sens celles les moins pratiques de tout le site aujourd'hui quand on navigue au lecteur d'écran. Voilà pourquoi je commence par celle-là. La liste des topics n'a aucune sémantique utile pour les lecteurs d'écran permettant une lecture plus simple actuellement. Si on veut choisir un sujet à aller voir, on n'a qu'une seule possibilité: appuyer des centaines de fois sur tab jusqu'à tomber sur quelque chose qui a l'air interressant; au passage, on se tape des liens moins utile comme le profil de l'auteur, celui de la dernière réponse, des mots-clés pas toujours en nombre égal ce qui complexifie encore un peu.

Plusieurs possibilités pour faire mieux :

Possibilité1: Revenir à des tableaux classiques ! Ca peut vous paraître bizarre, car on vous a probablement toujours dit que les tableaux étaient à réserver à des données tabulaires. Eh bien, en fait, une liste où on retrouve pour chaque ligne les mêmes informations (titre, auteur, nombre de réponses, mots-clés, dernière réponse), c'est pourtant bien des données tabulaires, où chaque titre de sujet est une cellule d'en-tête. D'ailleurs, visuellement, je suis presque sûr que l'information est présentée dans des colonnes bien organisées. Alors pourquoi un ramassis de span informe ??? Pour un lecteur d'écran c'est plus simple un tableau dans ce cas, car on a des moyens de naviguer par ligne ou par colonne au lieu de se taper toutes les cellules dans l'ordre à la suite. Par conséquent, pas besoin de lire l'auteur, le nombre de réponses, les mots-clés et le dernier posteur des sujets dont le titre ne m'intéresse de toute façon pas; par ailleurs, il n'est pas mauvais de rappeler que le titre est la porte d'entrée d'un sujet, c'est ce qui va me permettre de décider si je clique ou pas pour le lire.

Possibilité 2: différencier les titres de sujets en les mettant en <h1-6>. Sachant que le titre de sujet est l'information la plus importante et que le reste (auteur, mots-clés, etc.) le sont beaucoup moins, c'est un choix qui paraît affreusement logique, plutôt que l'actuel ramassis de span informes. Avec un lecteur d'écran, c'est plus facile car on a une fonctionnalité pour naviguer rapidement de titre en titre, et ce sur toutes les plateformes, aussi bien PC que mobile. Si les titres étaient en <h1-6>, alors de nouveau, plus besoin de se taper les métadonnées d'un sujet qui ne m'intéresse pas. Si ça ne m'intéresse pas, zoup, je passe au titre suivant, et donc au titre de sujet suivant.

Voilà, ceci marque la fin de ma première requête. A bientôt pour d'autres, très probablement; à mesure que je passe du temps et que je découvre ce site.

Note: j'ai fait exactement la même suggestion sur PDP il y a quelque temps, et ils l'ont fait; ils ont choisi la possibilité n°2.

Si vous choisissez la possibilité n°2 et que votre code n'est pas trop mal fichu (pour cela je pense qu'on peut vous faire confiance), ça devrait vous prendre . . . 30 secondes à peine pour modifier.

Merci de m'avoir lu et désolé pour la longueur.

Merci pour les retours, je crée le ticket qui va bien.

Personnellement les deux solutions me vont : quoiqu'en disent certains, les listes de topics sont bel et bien des données tabulaires (il suffit de voir la présentation) à mon sens. Cela dit, je n'ai aucune préférence entre les deux solutions.

Salut QuentinC,

Je trouve toujours super intéressant l'avis d'un mal voyant pour améliorer l'accessibilité. J'apprends toujours beaucoup de choses et je me rends compte que leurs usages des produits (web, mobile, etc.) sont très différents des usages des autres.

A tout hasard, serais-tu un utilisateur Android ?

je vote pour la 1 !

J'étais persuadé que c'était un tableau perso oO

Yop !

Vu que c'est moi qui ait écrit ce code, je pense pouvoir répondre.

Si on passe par un tableau, ça n'améliorera pas la lisibilité car dans la même cellule on aura : tags, titre, sous-titre, auteur et date de création. En fait, visuellement tout ça serait dans la même cellule, ça ne t'avancerait pas à grand chose.

Je tiens à souligner qu'il est possible de naviguer d'un topic à l'autre dans la liste via les touches J et K (ça n'est indiqué nul part, c'est vrai). J'aimerais au passage savoir si de tels raccourcis de navigation sont utilisables par des personnes comme toi. Sachant que lorsque l'on navigue via ces touches, le focus est mis sur le lien qui contient titre et sous-titre, j'ai l'impression que c'est relativement propre comme solution.

On peut toujours rajouter un h4 sur les titres des sujets, mais ça me semble assez bourrin en fait.

A tout hasard, serais-tu un utilisateur Android ?

pas du tout ! Je n'ai aucun appareil estampillé Google chez moi. Je suis tout ce qui est de plus classique: PC sous Windows 7, IE comme navigateur principal (SVP ne trollez pas là-dessus), et j'ai un iPhone5 avec iOS7 comme téléphone.

Si on passe par un tableau, ça n'améliorera pas la lisibilité car dans la même cellule on aura : tags, titre, sous-titre, auteur et date de création. En fait, visuellement tout ça serait dans la même cellule, ça ne t'avancerait pas à grand chose.

Ah, et pourquoi donc ?

Si vous choisissez la variante tableau, il faut évidemment qu'il y ait suffisament de cellules différentes: 1/titre, 2/auteur, 3/nb.rép, 4/tags et 5/date et nom dernier posteur par exemple; sinon ça n'a effectivement absolument aucun intérêt.

Je tiens à souligner qu'il est possible de naviguer d'un topic à l'autre dans la liste via les touches J et K (ça n'est indiqué nul part, c'est vrai). J'aimerais au passage savoir si de tels raccourcis de navigation sont utilisables par des personnes comme toi. Sachant que lorsque l'on navigue via ces touches, le focus est mis sur le lien qui contient titre et sous-titre, j'ai l'impression que c'est relativement propre comme solution.

Tu vas être déçu, mais non.

En fait, il faut savoir qu'avec la plupart des lecteurs d'écran actuels, quand on navigue sur le web, on navigue en fait dans une version virtualisée de la page, dans une vue virtuelle.

Quand on est dans cette vue virtuelle, la plupart des touches normales nous servent à naviguer dans la page et ne sont pas transmis au navigateur, i.e. pas de onkeydown. Par exemple, avec NVDA et Jaws, la touche H permet d'atteindre directement le titre suivant; F permet d'atteindre le champ de formulaire suivant, etc. Avec VoiceOver sur iPhone, un balayage droite permet d'atteindre l'élément suivant et on peut choisir le type d'élément qu'on veut atteindre avec ce qu'on appelle le rotor. Ce mode de vision virtuelle s'appelle curseur virtuel, mode document, ou mode web.

Quand il s'agit de taper du texte dans une zone de texte, on change de mode et on revient dans celui où toutes les touches sont normalement interceptés. Ce mode s'appelle le mode application, le mode formulaire, le curseur PC (les appellations diffèrent un peu selon le lecteur d'écran utilisé) Dans ce mode, on n'a pas accès à la navigation rapide (avec la touche H citée précédemment par exemple).

Le webmaster peut avoir une influence sur quel mode devrait être utilisé en priorité, au moyen d'ARIA. Ca peut être extrêmement utile de pouvoir utiliser une page entièrement en mode application si on se trouve sur une page web qui s'utilise un peu comme une application de bureau (l'exemple classique, le webmail). Or pour que ça fonctionne bien, il faut que la gestion du clavier soit irréprochable; la moindre erreur conduit à une non-accessibilité partielle ou totale (impossibilité pure et simple de lire, d'atteindre ou de manipuler certains éléments).

IL se trouve que gèrer correctement le clavier jusque dans les moindres détails est extrêmement difficile, très peu ont vraiment réussi. Du coup le mode application est pratiquement toujours une nuisance s'il est imposé en-dehors des formulaires.

Tu comprends donc que tes touches J et K ne fonctionne pas vraiment, et n'ont absolument aucun intérêt pour un lecteur d'écran sur ZDS, sauf si ça s'inscrit dans le cadre d'une application web complète qui est capable de gérer tout à la perfection. Vous pourriez le faire, mais ça risquerait de vous prendre un temps absolument démentiel, et ça ne se justifierait pas vraiment pour toutes les parties du site (éventuellement pour les forums, mais certainement pas pour les tutoriels)

Ca peut par contre avoir un intérêt pour un utilisateur qui est empêché d'utiliser une souris pour une autre raison que la cécité. Mais il faut que ça soit pratique, intuitif, logique et bien documenté; sinon, ça ne sert à rien. Tu penses bien que personne ne va se taper 36 modes d'emploi différents pour 36 sites qui font chacun à leur façon. ET en l'occurence, JK, ça n'a pas vraiment de logique, sauf peut-etre pour ceux qui sont habitués aux jeux vidéo et qui, parfois, utilise IJKL ou WASD comme pavés fléchés alternatifs.

Je te donnerais bien un exemple de bonne utilisation du mode application imposé, mais c'est mon propre jeu qui est dans ma signature…

On peut toujours rajouter un h4 sur les titres des sujets, mais ça me semble assez bourrin en fait.

Et pourtant, ça serait la solution de loin la plus simple.

J'espère que mes explications n'ont pas été trop compliquées; merci de m'avoir lu jusqu'au bout!

En passant, pourquoi dans la zone de texte de réponse, il n'y a la place à peine que pour 2 ou 3 mots par ligne ? C'est assez chiant quand on se relit en fait.

En passant, pourquoi dans la zone de texte de réponse, il n'y a la place à peine que pour 2 ou 3 mots par ligne ? C'est assez chiant quand on se relit en fait.

Ce doit être un effet de bord du mode "lecteur d'écran", parce qu'en desktop elle fait environ 100 caractères.

Il n'y a pas d'attribut cols sur le textarea de réponse, du coup ça doit être la largeur par défaut de ton lecteur d'écran.

Je dois avouer avoir complètement oublié le fait que les lecteurs d'écrans utilisaient déjà tout le clavier à leur sauce.

Du coup, je pense qu'on va opter pour des h4 sur les titres dans la liste des sujets.

Pourquoi pas un tableau : parce que la mise en page actuelle n'est pas inscriptible dans un tableau de façon à ce que ça améliore la praticité aux lecteurs d'écrans. Pour te donner une idée, dans la première colonne, il y a des icônes qui permettent de savoir si le sujet est résolu, épinglé ou fermé avec un texte alternatif. Ensuite dans une deuxième colonne, on a le titre, dessous il y a le sous-titre et dessous on a l'auteur et la date de création. Et très sincèrement, à moins d'avoir une construction très complexe, on arrivera à rien de très propre ni pratique rien que sur cette colonne (à moins que tu ne puisses me proposer quelque chose, je ne suis pas infaillible mais là rien ne me vient).

Pour les touches J et K, pour te donner une idée, des sites tels que Twitter, Facebook, Google+. Donc a priori ce sont des sites présentent beaucoup de listes de contenus, ce qui ne semblait pas déconnant, si on met à part le fait que ces touches ne sont pas "accessibles" depuis ton lecteur d'écran.

Édit : Pourquoi J et K ? Parce que VI

En tous les cas, merci de ton retour, je ferais ce qui est possible pour améliorer tout ça. N'hésites pas si d'autres choses te chagrinent, ou si tu as des liens vers des sites qui expliquent comment améliorer tout ça.

Pendant qu'on y est, as tu des remarques sur le contenu généré automatiquement ? Soit les messages sur le forum et les articles et tutos, tout ce qui est généré depuis du markdown ?

La chaîne va être refaite a moyen terme et le générateur de html depuis le markdown va être changé. Donc si tu as des complaintes avec la génération actuelle, c'est le moment !

Pendant qu'on y est, as tu des remarques sur le contenu généré automatiquement ? Soit les messages sur le forum et les articles et tutos, tout ce qui est généré depuis du markdown ?

Si on fait abstraction de mathjax qui ne génère pas du contenu accessible, je n'ai pas remarqué de grosses énormités jusqu'à maintenant; quelques détails tout au plus.

Si, il y a quand même quelque chose: les numéros de ligne dans les extraits de code. Si je mets le code suivant :

1
2
3
4
5

#include<iostream>
int main (int argc, char** argv) {
std::cout << "Hello, world!" << std::endl;
return 0;
}

J'obtiens ceci avec mon lecteur d'écran :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

1
2
3
4
5
6
7
#include<iostream>
int main (int argc, char** argv) {
std::cout << "Hello, world!" << std::endl;
return 0;
}

Du coup ces numéros de ligne sont une nuisance totalement inutile. Pour les masquer aux lecteurs d'écran en ne touchant à rien pour le reste du monde, en plus, c'est très simple, il suffit d'ajouter l'attribut aria-hidden="true" sur le div qui contient ces numéros. Il faut faire très attention quand on joue avec cette attribut mais ici il est particulièrement justifié.

Pour mathjax, je crains que vous ne puissiez pas y faire grand chose. Pour le moment, je suis passé en mode de compatibilité, de cette façon mathjax croit qu'il a à faire à IE7 et laisse les expressions en LaTeX inchangées; c'est toujours mieux que d'avoir toutes les expressions mathématiques remplacées par "zone d'édition" (ne me demandez pas pourquoi "zone d'édition", je n'en sais fichtre rien, les gens de mathjax on just fait totalement n'importe quoi)

Sinon, profitez de cette refonte pour vous assurer que toutes les images ont toujours un texte alternatif, que quand il manque parce que l'auteur ne l'a pas mis mieux vaut le laisser vide (vide mais pas absent) que de le remplir avec une valeur par défaut générique genre "image utilisateur" (c'est du bruit pour rien). S'assurer aussi qu'il n'est pas possible de foutre en l'air trop facilement la hiérarchie de titrage car c'est le moyen n°1 pour naviguer et se repérer sur un site; et voir aussi (j'en ai pas encore vu ici, je ne sais pas s'il y en a ) que les trucs comme les zones rétractables i.e. secret sont bien commandables au clavier (le plus simple pour y arriver, c'est avec un bête lien, tout simplement)

Après, le reste, c'est des critiques que j'adresserais au langage markdown lui-même tel qu'il est interprété sur ce site, ça n'a plus rien à voir avec l'accessibilité. Principalement, l'obligation de laisser une ligne blanche selon moi inutiles avant le début d'une liste ou d'un code, et la non traduction de \n vers <br />.

Je dois dire que, globalement, je classe ZDS à un niveau d'accessibilité très bon par rapport à la moyenne pas très folichonne des autres sites que je visite normalement. Ca ne te surprendra sûrement pas, mais tout en bas du classement, on trouve les sites de presse et les réseaux sociaux.

EDIT: C'est quoi ces conneries ? J'écris mon pavé, je fais envoyer, et seulement là, on me demande mon login et mon mot de passe… et en plus la zone de texte est de nouveau vide. Heureusement que j'ai été prévenant en copiant avant d'envoyer.

l'obligation de laisser une ligne blanche selon moi inutiles avant le début d'une liste ou d'un code

D'après ce que j'ai compris du travail de Kje, ça ne sera plus utile une fois qu'il aura terminé donc pour ça, tu seras moins embêté.

et la non traduction de \n vers <br />.

Il y avait eu un débat à ce propos et en fait c'est une sorte de norme d'avoir comme comportement de mettre un <br/> uniquement si le saut à la ligne est précédé de deux espace blancs.

D'après ce que j'ai compris du travail de Kje, ça ne sera plus utile une fois qu'il aura terminé donc pour ça, tu seras moins embêté.

En fait au début de la refonte, ce sera pareil (par compatibilité). Une fois que tout sera passé a pandoc, j'ai proposé de changer ce comportement (qui se fera en une ligne). On verra en temps voulu.

Pour les saut de lignes qui ne font pas de br, ça c'est la norme en markdown. Ça a de gros impacts de le changer.

Pour le reste, je prend note et j'essaierai d'en tenir compte au max.

Pour ce qui est du "Image utilisateur" c'est l'assistant d'édition Markdown que Thunderseb a fait qui rend comme ça par défaut, il faudrait qu'on le retire. Même quand on est voyant c'est gênant, car c'est affiché en légende des images.

Pour le secret, je te laisse faire le test ci-dessous, tu me diras si ça fonctionne correctement.

Pour le secret, je te laisse faire le test ci-dessous, tu me diras si ça fonctionne correctement.

Avec firefox ça fonctionne nickel, si je clique sur le lien le texte caché apparaît.

Avec IE je vois d'office le texte masqué. Test d'accessibilité concluant et très bon choix par défaut, mais la fonctionnalité elle-même de marche pas.

J'ai une question plus profonde. J'imagine qu'il y a certaines choses qui vont être dur à rendre facilement pour que ce soit agréable pour le lecteur lambda et à la fois pour un lecteur avec ce type de problématique. Est ce qu'un mode "accessibilité", activable par les préférence, ne serait pas plus simple ? Ça demande probablement de faire rentrer un membre déficient visuel dans l'equipe de dev pour au moins nous conseiller régulièrement en fonction des ajouts, mais bon, pourquoi pas ?

J'ai une question plus profonde. J'imagine qu'il y a certaines choses qui vont être dur à rendre facilement pour que ce soit agréable pour le lecteur lambda et à la fois pour un lecteur avec ce type de problématique. Est ce qu'un mode "accessibilité", activable par les préférence, ne serait pas plus simple ? Ça demande probablement de faire rentrer un membre déficient visuel dans l'equipe de dev pour au moins nous conseiller régulièrement en fonction des ajouts, mais bon, pourquoi pas ?

Faire une version spécial accessibilité, c'est la mauvaise approche pour plusieurs raisons :

1. Tôt ou tard, ça va te demander le double de boulot; tu vas maintenir deux sites ou presque, à la fin ça risque de t'emm**** plus qu'autre chose de la faire évoluer en même temps que la version principale; résultat après quelques mois ou années, la version spécial accessibilité finira par ne plus être totalement à jour, il y aura des bugs et des fonctionnalités manquantes, et ceux qui l'utiliseront seront frustrés.
2. Ca peut provoquer une sorte de stigmatisation, et c'est exactement ce qu'on ne veut pas. On aimerait pouvoir utiliser les mêmes choses que tout le monde, et ça nous enferme dans notre propre monde que de ne pas pouvoir.
3. Le troisième point est un peu trollesque, mais comment je fais pour activer ce mode spécial la première fois que j'arrive sur le site ? Ca paraît con mais c'est loin d'être une évidence, il existe des appareils qui ont une synthèse vocale activable, mais on a besoin d'une personne qui voit clair pour aller l'activer. Dommage! Dans le même ordre d'idée, il y a un mode d'accessibilité pour ne pas être obligé d'utiliser le drag&drop dans le CMS wordpress, mais pour l'activer c'était hyper compliqué, bien caché, et j'ai dû faire croire que j'utilisais IE6…

pour le 3 on peut simplement le demander à l'inscription, tant que son acces est facile. Pour les 2 autres je comprend et me doutais de la réponse, mais je me devais de poser la question, je ne connais pas trop les problèmes que vous pouvez rencontrer.

Pour les 2 autres je comprend et me doutais de la réponse, mais je me devais de poser la question, je ne connais pas trop les problèmes que vous pouvez rencontrer.

Pas de problème. En plus ici pour ZDS un mode spécial ne serait vraiment pas pertinent, dans la mesure où l'accessibilité du site est déjà très bonne de base; c'est juste des détails çà et là qui sont à corriger.

Pour expliquer aussi Juste pour dire, l'ex SDZ était aussi relativement bon à l'époque de la v3. Avec la v4 ils ont tout cassé, et quand je suis allé poliement leur demander dans leur uservoice, on a fini par m'envoyer ch*** prétextant qu'on n'avait pas le temps. ET pourtant javais commencé soft avec quelques alt manquants sur des boutons, ça leur aurait pris même pas 5 minutes. D'ailleurs c'est toujours pas corrigé ET ça ne le sera probablement jamais.

et pourtant ils ont un cours "handiaccessible"

et pourtant ils ont un cours "handiaccessible"

"Faites ce que je dis, ne faites pas ce que je fais."

Bref. En tout cas c'est vraiment intéressant d'avoir des retours d'utilisateurs sur ce genre de points plutôt que des bêtes guidelines.

pas du tout ! Je n'ai aucun appareil estampillé Google chez moi. Je suis tout ce qui est de plus classique: PC sous Windows 7, IE comme navigateur principal (SVP ne trollez pas là-dessus), et j'ai un iPhone5 avec iOS7 comme téléphone.

C'est bien dommage. Quand l'API sera mise en place, l'application Android viendra très certainement plus rapidement qu'une application iOS. Je connais les bonnes pratiques d'accessibilité dans le développement Android, j'ai déjà bossé avec des malvoyants mais des retours utilisateurs pendant le développement auraient été un bon plus.