Discussion :

[vermine]

amCharts 3.20 : WAI-ARIA et accessibilité aux malvoyants
pour l'outil JavaScript de graphiques en tout genre

amCharts est une bibliothèque JavaScript graphique avancée et indépendante qui convient à n'importe quel besoin de visualisation de données. Elle propose différents types de graphiques à intégrer dans vos pages Web : en colonnes, linéaires, par zone, en étape, comme un radar, le camembert, les bulles, les jauges, etc. Avec son côté « responsive », cette bibliothèque convient tout aussi bien pour les affichages sur desktop que sur écrans tactiles.

C'est grâce à un éditeur visuel que vous constituez vos graphiques. C'est un gain de temps qui limite le nombre d'erreurs. Vous pouvez créer, sauvegarder et partager vos graphiques.

La version 3.20 est sortie, il y a quelque temps déjà (oups, désolé pour le retard). On y trouve par exemple :

• les libellés descriptifs WAI-ARIA sont automatiquement ajoutés aux éléments clefs. Cela permet aux utilisateurs malvoyants d'avoir une idée du contenu du graphique ;
• des propriétés d'accessibilité pour améliorer l'expérience utilisateur ;
• une correction concernant le positionnement des jauges ;
• une amélioration pour PeriodSelector et le bouton YTD ;
• etc.

Démonstration

Téléchargement

Source : Blog officiel

Et vous ?

Avez-vous testé les nouveautés de amCharts ? Comment les trouvez-vous ?

Retrouver les cours et tutoriels sur les frameworks JavaScript.

[CoderInTheDark]

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.

[CoderInTheDark]

Tout d’abord, je dois revenir sur mon précédent message. On m’a fait remarquer, que j‘ étais un peu réducteur en réduisant la déficience visuelle de façon binaire entre les non-voyants et les non-voyants. Le sujet est plus complexe notamment pour les malvoyants.
Concernant les non-voyants on est obligé d’utilisé un lecteur d’écran, qui retourne l’information par une synthèse vocale ou par le braille ou bien les deux. C’est avant tout un choix personnel. Par exemple je connais des non-voyants, qui travaillent sous linux en terminal qu’avec le braille, et ils sont très rapides. . Et il y a beaucoup de déficient visuel, qui ne lise pas le braille, et qui utilisent l’ordinateur au clavier et avec la synthèse vocale. Personnellement j’utilise surtout le braille pour relire le code, quand il manque une parenthèse ou une cote. Car c’est plus précis, que la synthèse vocale. Mais dans tous les cas le composant doit proposer un texte accessible et exploitable par la technologie d’accessibilité, l’utilisateur choisira son mode de restitution.
Concernant les malvoyants . Ils utilisent une loupe numérique, qui agrandit le texte à l’écran. Les alternatives textuelles ne sont pas exploitées par défaut par les loupes. C’est pourquoi je ne comprends pas très bien la finalité de cette intégration d’ARIA, pour les malvoyants. Néanmoins les loupes intègrent aussi des lecteurs d’écran, qui peuvent être activé sur demande. Et un certain nombre de malvoyants utilisent des lecteurs d’écrans, car lire à l’écran est trop fatigant pour eux, ou le niveau de zoom à utiliser est tellement important, que cela est contreproductif.

Concernant la librairie, il faut noter que rendre les graphiques accessibles aux déficients visuels est un défi dur à réussir. J’ai testé la librairie en allant sur la page de démonstration, mais je n’ai
Pas pu tester tous les graphiques.

Le texte est bien annoncé. Mais il est lu d’un bloque, car tous les éléments sont collées. Sans séparateurs ou espaces Donc c’est impossible de comprendre car cela va trop vite. Il faut donc utiliser le braille, mais l’absence de séparateurs est toujours problématique, et c’est un vrai cauchemar avec les chiffres. De plus il est très difficile de faire la correspondance entre les nombres et leur libellé.
Une solution alternative serait de copier le texte accessible dans le presse papier pour l’exploiter dans un bloc note, ou dans un tableur. Si un texte est formaté avec des tabulations on peut le coller dans une feuille et les données seront bien séparées dans les cellules et alignées avec les bons titres de colonnes et de lignes.
Mais je ne suis pas parvenu à le faire dans ce cas. Car l’accessibilité n’a pas fonctionnée avec NVDA, qui permet de coller le texte accessible dans le presse papier. J’ai juste pu travailler avec Jaws.
Certains graphiques peuvent être parcourus de lignes en lignes, mais sur les lignes les informations sont collées.

Globalement l’absence d’’espaces ou de séparateurs dans le texte accessible est rédhibitoire. Donc pour l’instant cette librairie n’est pas exploitable par les déficients visuels.
Si on y réfléchit un graphique est un outil d’accessibilité pour les voyants. Il permet de rendre plus compréhensible les données représentées de façon tabulaire. Un camembert permet de mieux voir la répartition de la population étudiée. Des courbes permettent de voir l’évolution dans le temps.
Pour réaliser un diagramme avec un tableur il suffit de rédiger les données dans une feuille de les sélectionner et d’utiliser un assistant pour générer le graphique. C’est surtout cette information qu’il faudrait retourner à la technologie d’assistance, comme je l’ai expliqué plus haut.

Sinon il y a-t-il quelqu’un d’autres sur cet article et accessoirement sur la discussion?