1178 sujets

Accessibilité du Web

RGAA 3 et Javascript

Hello !

Avec la publication officielle de RGAA 3.0 (https://references.modernisation.gouv.fr/rgaa-3-0) il n'est plus nécessaire de prévoir un alternatif au JavaScript, vu que le JS un langage permettant l'accessibilité.

Bien sûr il faudra bien que le code généré d'un module JS soit accessible et qu'on puisse le contrôler au clavier.

Ma question est donc, si j'ai bien compris, qu'il n'est plus nécessaire de prévoir un alternatif sans JavaScript pour quand le JavaScript n'est pas activé au présent dans le navigateur de l'internaute ? même si ça rend inaccessible ton contenu web ? (je pense notamment aux menu déroulants, modals, ou aux sliders utilisant JavaScript).

Et autre question: est-ce que quelqu'un aurait un lien vers des tableaux / listes avec tous les changements / ajouts de RGAA 3 par rapport à la version 2.2 ?
Modifié par Underdog (09 Jun 2015 - 16:48)
Bonjour,

Pour commencer, Aurélien Lévy de la société Temesis a écrit un billet concernant les différences entre RGAA2 et 3, et tu trouveras à la fin un lien vers le fichier au format xlsx correspondant.

Concernant les alternatives à JavaScript, le besoin d’alternative existe toujours. Cependant il ne passe plus par la stratégie éculée utilisant la balise <noscript>, mais par de l’amélioration progressive (par exemple, coder dans un premier temps un lien vers une page, puis enrichir avec JavaScript en transformant le lien en bouton et en lui adjoignant les actions liées au script).

Dans tes exemples :
- un menu déroulant peut être simplement déroulé par défaut quand pas de JS ;
- une modale peut être un simple lien renvoyant vers une page plutôt qu’ouvrir une fenêtre, ou même être une section dans la page que l’on rejoint via une ancre ;
- un slider…Même s’il n’existe que très peu de raisons pertinentes de s’en servir, je dirais que par défaut tu n’affiches que le premier élément, puis tu charges les suivants avec JavaSript quand il est présent et actif.

En plus de rendre tous les contenus accessibles sans JavaScript, cette méthode permet également de travailler une base saine et valide - mais aussi d’améliorer sensiblement les performances (quand c’est bien fait) puisqu’on attend généralement le chargement du DOM pour enrichir l’interface avec JavaScript.

À noter que rendre les scripts compatibles avec les technologies d’assistance n’est pas forcément une mince affaire, puisque ton slider par exemple devra être utilisable au clavier (ce qui sous-entend : des boutons activables avec la barre espace, une navigation possible avec les flèches droite et gauche, la possibilité de mettre en pause quand il y a un défilement automatique, etc.) Smiley cligne .

Ai-je répondu à tes questions ?
Modifié par Ten (10 Jun 2015 - 08:51)
Bonjour,

quelques petites précisions en fait vous avez tous les deux raisons Smiley cligne .
L'obligation est de fournir une interface accessible donc soit il faut faire en sorte que l'interface avec javascript soit accessible soit fournir une interface alternative accessible.

La question n'est donc pas sur le support ou non de javascript mais sur l'accessibilité des contenus générés via javascript

Si vous choisissez l'option de l'interface alternative car vous ne pouvez/voulez pas rendre accessible la version avec js, attention il ne suffira pas par exemple de faire un menu qui s'affiche quand on recharge la page sans javascript. Il est nécessaire d'avoir un lien/bouton dans l'interface avec js qui permet de passer d'une version à l'autre. En fonction de la solution de mise à disposition de l'alternative ce lien pointera soit sur une nouvelle page (alternative coté serveur par exemple) ou modifiera la page courant (alternative par amélioration progressive).

c'est un peu tiré par les cheveux mais il est tout à fait possible d'imaginer une solution qui via js prend le contenu d'un noscript pour le rendre visible quand l'utilisateur clique sur un bouton

Un autre point important, si vous choisissez de faire une version accessible avec js et que votre interface contient de l'ARIA il faudra vérifier sa restitution dans la base de référence (sans ARIA ça ne sera pas obligatoire) et si l'ARIA que vous utilisez correspond à un modèle de conception il faudra respecter celui si.

L'accessibilité à l'ancienne à base de texte masqué a encore de beaux jours si vous voulez éviter de vous prendre la tête Smiley smile
A tout ce qui a déjà été dit, j'ajouterais ceci :

La grosse erreur qui est hélas souvent faite même avec les meilleures volontés du monde et qu'il faut bien comprendre, c'est que la disponibilité ou non de javascript n'a plus rien à voir avec l'accessibilité aujourd'hui. Si ton script primaire n'est pas accessible, alors il ne faut pas obliger les utilisateurs à désactiver javascript pour qu'ils puissent utiliser la version alternative. Le 99% des utilisateurs ne savent pas comment désactiver javascript et ne savent même pas ce que c'est.

ET même moi qui connais bien javascript: quand je navigue en tant q'utilisateur normal hors développement, si c'est pas accessible avec mon lecteur d'écran ou si je n'arrive pas à faire ce que je veux faire, je fais comme tous les utilisateurs normaux: je ferme l'onglet et je vais voir ailleurs.

Si version alternative il y a, il faut absolument que ce qui permet de l'activer soit lui-même accessible; sinon ça ne sert à rien.

Le plus gros fail de ce genre que je peux te citer, c'est la'udiodescription à la télévision grand public. Les films en audiodescription c'est une excellente chose ! Mais comme les magnifiques menus de ma télévision ne sont pas vocalisés, j'ai besoin d'une tierce personne pour m'activer l'audiodescription. Du coup si je suis seul je l'ai dans l'os.

JE sais, ça n'a pas grand chose à voir mais je pense qu'avec ça tu vois où je veux en venir.

Le mieux est bien sûr de rendre ton script accessible. Ca t'éviterait de devoir développer une version alternative; deux fois moins de travail et aucun risque de faire cette bêtise de base. Avec un peu d'effort et si tu acceptes de renoncer aux choses vraiment trop exotiques, c'est pas si horrible que ça
Ten a écrit :


Pour commencer, Aurélien Lévy de la société Temesis a écrit un billet concernant les différences entre RGAA2 et 3, et tu trouveras à la fin un lien vers le fichier au format xlsx correspondant.


Super, c'est exactement ce qu'il me fallait ! Smiley biggrin

Toutes vos explications sont bien claires, je vous remercie !
goetsu0 a écrit :

Si vous choisissez l'option de l'interface alternative car vous ne pouvez/voulez pas rendre accessible la version avec js, attention il ne suffira pas par exemple de faire un menu qui s'affiche quand on recharge la page sans javascript. Il est nécessaire d'avoir un lien/bouton dans l'interface avec js qui permet de passer d'une version à l'autre. En fonction de la solution de mise à disposition de l'alternative ce lien pointera soit sur une nouvelle page (alternative coté serveur par exemple) ou modifiera la page courant (alternative par amélioration progressive).

c'est un peu tiré par les cheveux mais il est tout à fait possible d'imaginer une solution qui via js prend le contenu d'un noscript pour le rendre visible quand l'utilisateur clique sur un bouton


Est-ce que vous auriez des exemples de sites qui utilise le technique que tu décris ici ? J'ai l'impression que ce cas est très rare..
goestu0 a écrit :

Si vous choisissez l'option de l'interface alternative car vous ne pouvez/voulez pas rendre accessible la version avec js, attention il ne suffira pas par exemple de faire un menu qui s'affiche quand on recharge la page sans javascript. Il est nécessaire d'avoir un lien/bouton dans l'interface avec js qui permet de passer d'une version à l'autre. En fonction de la solution de mise à disposition de l'alternative ce lien pointera soit sur une nouvelle page (alternative coté serveur par exemple) ou modifiera la page courant (alternative par amélioration progressive).

c'est un peu tiré par les cheveux mais il est tout à fait possible d'imaginer une solution qui via js prend le contenu d'un noscript pour le rendre visible quand l'utilisateur clique sur un bouton


Underdog a écrit :

Est-ce que vous auriez des exemples de sites qui utilise le technique que tu décris ici ? J'ai l'impression que ce cas est très rare..


Allez hop, déterrage de sujet ! Avoir des exemples de sites qui utilisent aujourd'hui la technique décrite par goetsu0 m'intéresserait également Smiley smile

Merci !
Bonjour, sujet un peu vieux mais si cela peux aider qq, il existe une interface d'accessibilite
pas mal
<snip>

Édité par un admin ainsi que le reste de la conversation parce qu'aucun démarchage commercial n'est autorisé sur ce forum.
Les 2 membres bannis postaient de plus du même endroit donc se connaissaient ce qui n'apparait pas clairement dans leurs messages. Mais peu importe, publicité = ban.
Modifié par Felipe (17 Sep 2018 - 17:25)
PatrickSfez a écrit :
Voir la video Smiley cligne Accessibilité numérique
<snip>

Juste venir s'inscrire sur un site communautaire pour vendre sa soupe est une démarche vraiment nulle.
Vous auriez pu faire l'effort de proposer un tutorial. Mai c'est vrai qu'un commercial a une compétence technique proche de 0.
Au final, vous n'incitez pas les webmasters à améliorer l'accessibilité des sites Web. Juste leur piquer du blé.
Modifié par Felipe (17 Sep 2018 - 17:25)
pourquoi cette haine !
Vérifiez les capacités de notre interface et contactez-nous si vous le souhaitez.
Merci Smiley cligne
Sujet clos
Aller à