Globalement il y a un point positif, l’accessibilité se fait de plus en plus par le haut.
C’est-à-dire que ce sont les Framework et API, qui ‘l’intègrent, comme dans ce cas.
Ca allège le travail des développeurs, qui n’ont pas le temps pour ça.
Et puis, le HTML5, qui a introduit ARIA, est très accessible naturellement.
Je voulais vous écrire un article sur le sujet.
Mais je m’aperçois, que mes conseilles ne valent plus grand-chose, grâce à HTML5.
Et puis un exemple, je parlais de l’accessibilité des formulaires à un ami.
Et il me répond que de toute façon il ne fait plus ses formulaires. Il passe par une librairie tierce.
On fait de moins en moins de HTML à la main.
Il n’empêche, que l’accessibilité du Web passe par une bonne utilisation des composants.
Un titre de niveau 1 par page, et des sous titres pour structurer le document et la navigation. Car on peut naviguer avec un lecteur d’écran par titre, et on s’attend à trouver sous le seul titre de niveau 1 le contenu principal.
Il faut bien nommer les liens hypertextes, car quand on arrive dessus le lecteur d’écran lit le texte entre les balises <a> et </a>. Et on n’a que ça comme information pour cliquer dessus.
Bien renseigner les alternatives textuelles, pour les images car « 145gfl4df.jpg », c’est pas terrible comme nom.
Dans cette librairie il faut renseigner les alternatives textuelles des graphiques, mais ça ne va pas dire le contenu ou les chiffres.
Je suis un peu sceptique.
Car les alternatives textuelles sont faites pour les lecteurs d’écrans, qu’utilisent les non-voyants.
Les mal voyants utilisent surtout des loupes numériques avec améliorateur de couleurs, qui intègrent parfois un lecteur d’écran. Mais en général ils ne l’utilisent pas tous.
Les lecteurs d’écrans intègrent maintenant des OCR, pour lire les textes contenus dans des images, d’une page web ou autres. Je l’utilise surtout pour lire les PDF images qu’on m’envoie.
Il ne faut pas oublier, qu’il faut utiliser les balises pour leur usage et non pour leur apparence.
Par exemple il y a de plus en plus de bouton qui sont dessinés en CSS, comme ils n’ont pas de type ou de rôle bouton le lecteur d’écran n’est pas capable de les interpréter.
Il faut utiliser le HTML de façon sémantique et non visuel.
Les codes JavaScript doivent gérer à la fois la sourie et surtout le clavier, car les non-voyants n’utilisent pas la sourie.
Je vais essayer plus tard la librairie, pour me faire une idée.
1 |
0 |