Accéder au contenu.
Menu Sympa

accessibilite - Re: [Accessibilite] Navigateurs Web et exécution d e code JavaScript

Objet : Liste de diffusion du groupe de travail Accessibilité (liste à inscription publique)

Archives de la liste

Re: [Accessibilite] Navigateurs Web et exécution d e code JavaScript


Chronologique Discussions 
  • From: Philippe Vayssière <philippe AT vayssiere.fr>
  • To: accessibilite AT april.org
  • Subject: Re: [Accessibilite] Navigateurs Web et exécution d e code JavaScript
  • Date: Fri, 13 Jul 2012 19:05:33 +0200

Bonjour et bienvenue Fabien,

je connais peu le détail des navigateurs utilisés mais en majorité il s'agit des mêmes navigateurs, avec en plus une assistance technique (AT) dépendant du ou des handicap.
Typiquement Internet Explorer ou Firefox avec le lecteur d'écran JAWS, Firefox avec NVDA, Safari avec VoiceOver.
Un peu plus de détails avec http://www.paciellogroup.com/blog/2012/02/rough-guide-browsers-operating-systems-and-screen-reader-support/ (note le "Rough Guide" dans le titre).
Il n'y a pas que les lecteurs d'écran dans la longue liste des assistances techniques : le cas particulier de l'accessibilité, c'est que les cas particuliers sont importants (et des fois j'enfonce les portes ouvertes).

_javascript_ : les navigateurs qui exécutent _javascript_ transmettent le DOM modifié aux assistances techniques, pas le code HTML brut qu'ils ont reçu du serveur.
Si une page est lue du début à la fin, que la lecture de la page en est à la moitié et que la partie modifiée par un script se situe vers le début, jamais cette modification ne sera répercutée à l'utilisateur (sauf en utilisant Accessible Rich Internet Applications - ARIA - correctement avec une AT supportant ARIA, donc très récente. Plus précisément les Live Regions ici). Il y a évidemment bien d'autres cas, obstacles, bonnes et mauvaises pratiques puisqu'on peut faire plein de choses avec du JS !

ARIA utilisable ?
Aucun navigateur sur aucun OS ne respecte ou n'implémente tout ARIA mais on peut déjà faire des choses assez sympas avec. À condition encore une fois que l'AT soit récente. Et là se pose le problème du renouvellement. Si ORCA ou NVDA sont libres, si VoiceOver est mis à jour à chaque mise à jour d'iOS et que de façon peu durable les smartphones sont des objets technologiques renouvelés assez rapidement, ce n'est pas le cas général loin de là.
Le support d'ARIA dans les navigateurs évolue rapidement, idem dans les AT sauf que leur mise à jour n'est pas fréquente, idem pour HTML5 souvent associé à ARIA : il faut accepter de beaucoup chercher, se creuser la tête, attendre pour certaines fonctionnalités un meilleur support, etc de manquer de bibliothèques prêtes à l'emploi (embêtant pour moi qui suis intégrateur un peu front-end mais pas développeur).

Respecter le référentiel Accessiweb permet de respecter les critères de succès correspondants des WCAG 2.0 et les tests du RGAA sont également très proches, il y a le choix.

Avec ou sans _javascript_ ?
Mmh bonne question merci de l'avoir posée, huhu.
J'esssaie dans des pages web habituelles que ça fonctionne sans _javascript_ (et que ça se dégrade sans bloquage en l'absence d'images, de CSS, sur un vieux navigateur, etc). Mais de façon très pragmatique je comprend qu'une page très riche en fonctionnalités nécessite l'usage de JS et ne fonctionne pas sans. L'important est d'avertir l'utilisateur, au minimum. Si c'est pour restreindre les fonctionnalités d'un projet ou exploser le budget et le temps nécessaires, ça n'ira pas. On peut aussi se concentrer sur les fonctionnalités les plus utilisées ou importantes et tant pis pour l'accessoire qui nécessitera JS.
Ça dépend vraiment de l'usage.
Ceci dit je vois encore beaucoup des pages qui fonctionneraient très facilement sans JS, par ignorance que JS est désactivé chez certains ou par ignorance des bonnes pratiques de codage. Ou parce que personne n'a testé en se mettant à la place de l'utilisateur.
Si tu dois réaliser quelque chose de complexe, mieux vaut à mon avis se concentrer sur la réussite du projet avec JS, fignoler l'ergonomie, la facilité d'utilisation, l'accessibilité JS activé en pensant à de futures améliorations possibles (du style "là, là et là il aurait fallu gérer côté serveur des échanges avec le visiteur mais je le fais en JS faute de temps ; mais en y pensant à l'avance je fais un choix qui me permettra de me contenter de modifications et m'évitera de devoir tout recoder plus tard". Anticiper, c'est le mot que je cherchais) plutôt que de ne jamais finir ...


Cordialement,
Ph. Vayssière


Le 13/07/2012 17:27, Fabien Bourgeois a écrit :
Une nouvelle question de béotien - veuillez me pardonner - mais j'aurais connaître les navigateurs aujourd'hui employés par des personnes en situation de handicap. Notamment :

- Gecko et Firefox
- les navigateurs Webkit (Chromium, Midori, Epiphany et autres)
- les navigateurs textes (Elinks, w3m...)

Comment considérer le _javascript_ ?
J'ai cru saisir que le pire était un code qui modifie le DOM, notamment dans le temps ou à la volée.

Cela dit, si l'on considère l'emploi d'un navigateur capable d'exécuter ce type de script, un _javascript_ associé convenablement à la norme ARIA parait utilisable, je me trompe ?

L'on m'a dit que la meilleure façon d'être réellement accessible, en dehors du fait de respecter AccessiWeb, était de fournir une version du site ou de l'application Web utilisable sans _javascript_ et évidemment sans perte de fonctionnalité.

Ce postulat est-il valide ?





Archives gérées par MHonArc 2.6.16.

Haut de le page