Réflexions autour de JS et Jaws

Bonjour,

Je m'interroge actuellement sur ce qu'il convient de faire, ou d'éviter, dans des sites qui commencent de + en + à employer des js "performants" (perso j'utilise jQuery)
et pour lesquels on recherche une accessibilité minimale, voire Accessiweb bronze ou plus .

En gros, prenons l'exemple d'un diaporama sympa (des div présents ds le code généré et masqués/affichés par le script).

D'une part, la navigation par tab est difficile à gérer (cas où le script insère des boutons pour défiler le diaporama dans un sens ou l'autre par exemple ces liens ou boutons ne sont jamais vu -différents scripts regardés)
et d'autre part un Jaws semble avoir bien du mal à décrire un élément qui change pendant qu'il passe dessus.

Je suppose que beaucoup ont déjà réfléchi à ca mais ca me travaille.

Quelques commentaires/suggestions ?

Merci

Bonjour,

L'exemple donné est trop vague pour qu'on puisse analyser les problèmes d'accessibilité qu'il pose (s'il y en a), et proposer des solutions.

Hum..
Oui je comprends c'est assez théorique. J'essaye encore:

Avec un lecteur vocal, et JS actif.

un diaporama par JS qui fait défiler, disons toutes le 3 secondes, des contenu avec une image est-il considéré comme accessible sachant que :

-ce qui défile est déjà bien présent dans le html (une suite de div par exemple)
-l'effet est décrit comme un div défilant derrière une "découpe" où on ne voit au travers qu'un seul à la fois.
-On considère que l'ensemble du code de ce diaporama respecte au mieux les règles et ne poserai pas de pb d'accessibilité si l'empilement de ces div étaient totalement affiché l'un au dessus de l'autre dans la page (cas de JS désactivé).

Mais puisque JS fait bouger les div, s'ils ne contiennent que des images passives, à un instant t si on passe dessus par TAB on doit entendre le ALT en cours.
Quid si ca bouge pendant la lecture vocal de ce ALT ?

Et
Si ce div comporte aussi un href on a encore moins le temps d'avoir la lecture vocale de l'ensemble et le temps d'activer éventuellement le lien..non ?

elz64 a écrit :
Quid si ca bouge pendant la lecture vocal de ce ALT ?

Déjà, il faut voir ce que tu appelles «bouger». Si à l'initialisation du JavaScript tu modifies la mise en page des items de contenu pour les placer les uns à côté des autres dans un conteneur de largeur fixe (DIV dont on calcule la largeur en JS), et qu'ensuite tu affiches les items un par un dans un conteneur en overflow:hidden, en modifiant le positionnement du DIV de largeur fixe (en position relative par exemple), ça devrait rester transparent pour un lecteur d'écran. Ton effet d'animation et le fait que certains contenus sont masqués (car en dehors de la zone de visibilité) ne devraient pas être perceptibles.

Si par contre tu utilises du display:none, visibility:hidden ou éventuellement de l'opacity:0, alors ça peut effectivement poser problème. Il me semble qu'on peut avoir des choses comme: le focus est sur un élément visible, cet élément est masqué sans action de l'utilisateur via un display:none, le focus se retrouve en tout début de document. On crée ainsi une zone «piège» qui va renvoyer l'utilisateur au début du document de manière imprévue et non compréhensible. Mais le comportement exact serait à vérifier par l'expérimentation. Pour info, pour un test de ce type tu peux utiliser une version d'évaluation de Jaws, ou encore NVDA.

Une remarque: l'accessibilité d'une animation de ce genre ne se limite pas à la lecture avec un lecteur d'écran et à l'utilisation au clavier. Il y a notamment des règles sur les flash lumineux et les animations interruptibles. Voir du côté du RGAA ou d'Accessiweb (ou directement des WCAG 2, mais ça peut être plus ardu) pour identifier les règles en la matière.

merci

Effectivement tu réponds à mes interrogations.

Je sais qu'il y a d'autres critères à évaluer, mais ce n'était pas le but de ma question. C'est bien autour des focus et de savoir ce qu'on montre ou pas à un lecteur vocal que ce situe ma perplexité.

Par contre tu m'a remis le doigt sur " l'interruptabilité " des animations. Il faut donc bien avoir un test de hover souris ET de focus clavier pour stopper l'animation. Auquel cas dans l'hyothèse 1 de ta réponse un Jaws devrait bien lire ce qu'il faut au focus de l'élément défilant qui se trouve stopper temporairement.

Avec le foisonnement de scripts ou de plug-in jQuery, il est bon de se poser 5 minutes pour ne pas faire n'importe quoi.

C'est une mauvaise pratique, à mon sens, de modifier des trucs automatiquement dans une page sans action de l'utilisateur.

Je pense que ton diaporama devrait être démarré par une action consciente de l'utilisateur. Dès lors, un utilisateur de JAWS ne le déclencherait pas, et donc pas de problème !

Bonjour,

julienw a écrit :
C'est une mauvaise pratique, à mon sens, de modifier des trucs automatiquement dans une page sans action de l'utilisateur.

Effectivement, c'est déconseillé par WCAG (cf critère 3.2.5, niveau AAA).

Ce qui peut perturber jaws, c'est la modification/création/suppression/déplacement d'éléments dans le DOM et l'affichage/masquage d'éléments par display ou visibility.

Jaws est parfois assez curieux lorsqu'il s'agit de prendre en compte ou pas les changements dynamiques : parfois, le tampon virtuel s'actualise tout seul en pleine lecture, et parfois il faut le demander explicitement avec insert+escape. Conformément à la loi de Murphy, c'est généralement pas le comportement qui arrange dans un contexte précis qui se produit. Il y a des différences entre navigateurs et versions de jaws encore en plus, donc IL ne faut vraiment pas miser là-dessus.

Le plus sage serait en effet d'arrêter l'animation lorsqu'il y a focus.... ou mieux, comme déjà dit, ne pas proposer d'animation démarrant automatiquement du tout, mais ce n'est peut-être pas facile à éviter.

En outre, je me méfierais des trucs tout faits. J'ai vu une fois un plugin JQUERY de défilement horizontal automatique apparament inoffensif qui en réalité dupliquait des éléments du DOM pour son usage propre. Il faut donc bien contrôler ce que fait le script...

Une erreur qu'on rencontre également très très souvent, c'est les gens qui vont planquer des div tout en bas de la page quand ils font des boîtes de dialogue et autres affichages contextuels ou optionnels. Ca n'a rien à faire tout en bas de la page, ça devrait plutôt être ajouté au bon endroit dans le DOM, juste en-dessous du lien qui propose d'afficher ces informations supplémentaires par exemple. Ou alors, mettre le focus correctement sur le premier bouton ou champ de la boîte au moment où on la fait apparaître.

Merci de vos contributions. Ca va dans mon sens.

JE viens de penser à quelque chose : arrêter l'animation s'il y a focus ne fait pas tout. Parce que ça ne met pas à l'abri de celui qui parcourt la page avec les flèches de direction (ce qui est mon cas souvent). Rien n'est focusé dans ce cas, et il y a pourtant risque de téléscopage.

Regardez par exemple comment réagit jaws avec le bandeau tournant « à la une » de la page d'accueil du site du zéro. Comme il change assez vite, si on n'a pas de chance, on lit parfois le début d'une information et la fin d'une autre...

oui c'est juste on a déjà remarqué ce pb de durée d'affichage qui doit être assez long pour que statistiquement le pb soit minimisé.

Mais on ne peut pas totalement bannir ces effets incontournables. L'objectif accessibilité peut être atteint alternativement par mise à dispo d'un template plus adapté (choix au niveau du menu de contournement par exemple).