Conformité WCAG 2.0: dois-je prendre en charge les navigateurs qui ne prennent pas en charge JavaScript?
WCAG 2.0 a des exigences de robustesse: "Le contenu doit être suffisamment robuste pour pouvoir être interprété de manière fiable par une grande variété d'agents utilisateurs, y compris les technologies d'assistance", mais il ne mentionne pas explicitement JavaScript.
Maintenant, j'ai un projet où je dois répondre aux recommandations WCAG 2.0. Dois-je prendre en charge les navigateurs/agents utilisateurs qui ne prennent pas en charge JavaScript?
La réponse courte (et pour éviter d'explorer comment vous envisagez d'analyser le contenu de votre site Web) est oui, elle mentionne javascript - http: //www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat.html
Si la technologie d'assistance ne peut pas interpréter correctement votre contenu lorsque Javascript est désactivé sur votre page (ou si le navigateur Web utilisé ne prend pas en charge Javascript), il ne répondra pas aux exigences d'accessibilité de niveau A.
Les deux sont de bonnes réponses, prises ensemble, mais les deux sont en quelque sorte faux à certains égards également. WCAG est indépendant de la technologie, il ne va donc pas dire quelles technologies (telles que javascript) doivent être prises en charge.
L'essentiel, auquel @daniel a fait allusion, est que tout le code HTML généré, que JS soit activé ou non, doit être sémantiquement correct pour que la technologie d'assistance (comme un lecteur d'écran ou un appareil braille ou une loupe d'écran) puisse le comprendre.
Si vous avez des éléments importants de votre interface utilisateur qui sont créés à la volée dans JS, et JS est désactivé, alors votre page peut ne pas être accessible à certains utilisateurs, donc à cet égard, vous devrez prendre en charge un navigateur non JS, mais uniquement à cause de la façon dont vous avez codé votre page. Si tous les éléments importants sont là sans utiliser JS, alors ça irait. Ce n'est donc pas vraiment une déclaration de savoir si les navigateurs non JS doivent être pris en charge, c'est si votre html sera complet et utilisable sans JS.
Mise à jour: 14 novembre 2018
Grande discussion dans les commentaires. C'est une question simple mais une réponse compliquée. J'ai lu les directives de conformité au moins une douzaine de fois ou plus en pensant à ce message (et en retardant ainsi ma réponse).
@TripeHound a abordé un point clé,
Si insister sur JS pour que le site fonctionne est acceptable, et que vous passez WCAG avec JS activé , alors tout est OK.
comme l'a fait @Daniel,
si JS est désactivé mais il passe tous les critères lorsque JS est activé (ha! ne se produit jamais)
que si la page prise en charge par JS est conforme aux WCAG, alors vous pouvez déclarer que vous comptez sur JS et que vous n'auriez pas à prendre en charge une page non JS . Mais encore une fois, c'est uniquement si votre page JS résultante était conforme. S'il n'était pas conforme, alors vous auriez à supporter un non -Version JS.
Donc, la réponse courte est le redouté "ça dépend".
Cela vaut également la peine d'être lu le point de vue de WebAIM sur ce sujet .
Alors que WCAG 1.0 de 1999 exigeait que les pages soient fonctionnelles et accessibles avec un script désactivé, WCAG 2.0 et toutes les autres directives modernes vous permettent d'exiger JavaScript, mais le contenu scripté ou les interactions doivent être conformes aux directives .
La déclaration de WebAIM aide, mais elle ne fait pas autorité. Certes, leur opinion est basée sur les lignes directrices, mais simplement parce que quelqu'un déclare quelque chose, cela ne le rend pas vrai. Heureusement, si vous lisez (et relisez) les directives de conformité, en particulier l'exigence # 5 , je pense que la déclaration de WebAIM dit la même chose mais en anglais plus simple.
Et ils ont un qualificatif quelque peu attendu:
Si votre page Web ou application nécessite des scripts, assurez-vous de prendre en compte les utilisateurs sans JavaScript. Bien que cela ne signifie pas nécessairement que toutes les fonctionnalités doivent fonctionner sans script (bien que ce soit clairement optimal), si cela ne fonctionne pas sans script, vous devez éviter une présentation confuse ou non fonctionnelle qui peut sembler fonctionner, mais pas parce que du manque de support JavaScript.
Ce qualificatif est quelque peu évoqué dans ma réponse originale.
Étant donné que l'OP a 3 ans, je ne suis pas sûr que quiconque (à part nous 3 :-)) verra cette discussion. Mais j'ai appris quelque chose.
Techniquement, d'un point de vue juridique, non vous n'avez pas besoin de supporter les utilisateurs handicapés JS pour passer l'accessibilité.
Clint a référencé 4.1 "Compatible" dans sa réponse .
Les lignes directrices réelles pour cette section sont 4.1.1 et 4.1.2.
4.1.1 consiste à s'assurer que votre code HTML est valide. Passez votre HTML à travers un validateur HTML et s'il passe, vous êtes prêt à partir.
4.1.2 consiste à utiliser correctement les rôles et les attributs aria.
Aucune des lignes directrices n'indique que le site doit fonctionner avec JS désactivé.
Il y a cette citation de 4.1 "Compatible" sous le titre " Advisory Techniques for Guideline 4.1 ":
- Ne pas afficher le contenu qui repose sur des technologies qui ne sont pas prises en charge par l'accessibilité lorsque la technologie est désactivée ou non prise en charge.
Cela suggérerait qu'un support sans JS est requis pour passer l'accessibilité cependant le bloc de texte au-dessus de ce point indique ceci:
Ces techniques ne sont ni nécessaires ni suffisantes pour répondre à des critères de réussite , mais peuvent rendre certains types de contenu Web plus accessibles à davantage de personnes.
Par conséquent, le support sans JS est certainement encouragé mais il n'est pas nécessaire pour passer toute forme d'accessibilité WCAG d'un point de vue légal.
Vous pouvez rendre une page html vide avec JS désactivé et tant qu'elle est HTML valide, elle techniquement n'échoue même pas aux exigences d'accessibilité de niveau WCAG AAA.