Robuste
Le problème
Les mécanismes permettant l’interactivité ne sont pas toujours perceptibles ou utilisables avec les technologies d’adaptation informatique. Toutes les fonctionnalités d’interactivité doivent donc être soigneusement testées avec ces outils. Lorsqu’il n’est pas possible d’assurer la compatibilité, il faut s’assurer que les contenus sont utilisables sans ces fonctionnalités, même si elles contribuent à l’enrichissement de l’expérience de l’utilisateur.
La solution
Validation du code
Dans les WCAG 1.0, on exigeait une validation complète du code en priorité de niveau 2. Puis, lors de la publication initiale des WCAG 2.0, l’exigence de validation a été réduite aux types d’erreurs qui peuvent poser problème du point de vue de l’accessibilité (critère 4.1.1).
Il faut toutefois savoir que cette exigence n’est maintenant plus applicable. En effet, dans la version de travail des WCAG 2.2, le critère 4.1.1 de validation syntaxique est abandonné. Depuis ce changement, le critère 4.1.1 est considéré comme satisfait par défaut pour les versions WCAG 2.0 et 2.1.
Pour plus d’explications à ce sujet, voir la note accompagnant l’énoncé du critère 4.1.1.
Utilisation de JavaScript
À propos de l’utilisation de JavaScript, WCAG 1.0 est beaucoup plus sévère que WCAG 2.0, ce qui s’explique en partie par le fait qu’en 1999, le support de JavaScript dans les outils d’adaptation informatique était très déficient.
Dans WCAG 2.0, on n’exige plus que la page demeure utilisable sans JavaScript, mais plutôt que l’utilisation de JavaScript soit compatible avec les technologies d’adaptation informatique (donc conforme au Document Object Model (DOM) du W3C). Voir les techniques de programmation proposées par le W3C (en anglais).
Si vous utilisez des menus déroulants :
Si le système de navigation comporte des menus déroulants ou présenté sous forme d’arborescence, mais que l’en-tête de chacun des menus conduit à une page intermédiaire où l’on retrouve tous les liens contenus dans le menu déroulant, ce menu est tout de même jugé accessible, puisque l’utilisateur dispose d’un autre moyen pour accéder au même contenu.
Deux techniques peuvent être utilisées pour rendre un menu déroulant accessible :
- La Boite à outils de l’expérience Web propose un menu basé sur l’utilisation des techniques WAI-ARIA prévue à cet effet. Ce type de composant interactif oblige cependant l’utilisateur d’un lecteur d’écran a passer en « mode interactif » aussi appelé « mode formulaire », ce qui peut être un peu déroutant au début. Une aide contextuelle est donc souhaitable pour donner à l’utilisateur un minimum d’information sur son utilisation.
- Le site du Laboratoire de promotion de l’accessibilité du Web propose une façon simple de configurer des accordéons. Dans cet exemple, les boutons déclencheurs sont enchassés dans des titres de niveau 2. Dans un menu qui utiliserait cette technique, ce devrait plutôt être des éléments de liste et un texte hors écran devrait préciser que le bouton donne accès à un sous-menu.
Si vous utilisez des pages dont le contenu est mis à jour sans rechargement de la page :
Le contenu modifié de façon dynamique doit répondre aux trois conditions suivantes :
- Le contenu généré doit être accessible;
- Le concepteur doit prévoir une façon d’avertir l’utilisateur de toute mise à jour du contenu;
- L’utilisateur doit disposer d’un moyen simple de se déplacer à ce nouveau contenu.
Notes :
- Le W3C a développé une spécification appelée WAI-ARIA. Il met aussi à jour périodiquement des notes sur l’utilisation d’ARIA en HTML et un guide de bonnes pratiques WAI-ARIA.
- Il est évidemment toujours possible de proposer une version de remplacement de ce contenu, version qui ne ferait pas appel à ce type de fonctionnalités.
Si un message d’état apparait à l’écran :
Il s’agit d’un nouveau critère de succès introduit par WCAG 2.1. Il y a deux critères principaux qui déterminent si quelque chose répond à la définition d’un message d’état:
- Le message fournit à l’utilisateur des informations sur le succès ou les résultats d’une action, sur l’état d’attente d’une application, sur la progression d’un processus ou sur l’existence d’erreurs;
- Le message n’est pas délivré via un changement de contexte comme un déplacement du focus ou l’apparition d’une boite de dialogue.
Des informations peuvent être ajoutées aux pages sans que cela correspondent à la définition d’un message d’état. Par exemple, la liste des résultats obtenus à partir d’une recherche n’est pas considérée comme un message d’état et n’est donc pas couverte par ce critère de succès. Toutefois, les courts messages texte affichés sur l’achèvement ou l’état de la recherche, tels que « Recherche en cours… », « 18 résultats trouvés » ou « Aucun résultat trouvé » sont des message d’état s’ils ne reçoivent pas le focus.
Ces messages d’état peuvent être transmis en utilisant l’une des deux techniques ARIA suivantes : en utilisant role="alert" ou avec l’attribut aria-live (voir à ce sujet la technique ARIA19).
Vous trouverez des explications beaucoup plus complètes ainsi que de nombreux exemple dans la section : Understanding Success Criterion 4.1.3: Status Messages.
Les règles qui s’appliquent à la compatibilité avec les outils d’adaptation
4.1.1 Analyse syntaxique (niveau A) : à moins que les spécifications ne le permettent, dans un contenu implémenté via un langage de balisage, les éléments ont des balises de début et de fin complètes, ils sont imbriqués conformément à leurs spécifications, ils ne contiennent pas d’attributs dupliqués et chaque ID est unique.
NOTE : Ce critère de succès doit être considéré comme toujours satisfait pour tout contenu utilisant HTML ou XML.
NOTE : Depuis que ce critère a été écrit, le HTML Living Standard a adopté des exigences spécifiques régissant la façon dont les agents utilisateurs doivent gérer les balises incomplètes, l’imbrication incorrecte d’éléments, les attributs en double et les ID non uniques.
Bien que la norme HTML traite certains de ces cas comme non conformes pour les auteurs, il est considéré comme « autorisant ces fonctionnalités » aux fins de ce critère de succès, car la spécification exige que les agents utilisateurs prennent en charge le traitement cohérent de ces cas. En pratique, ce critère n’apporte plus aucun avantage aux personnes handicapées en soi.
Les problèmes tels que les rôles manquants en raison d’éléments imbriqués de manière inappropriée ou d’états ou de noms incorrects en raison d’un ID en double sont couverts par différents critères de succès et doivent être signalés selon ces critères plutôt que comme des problèmes avec 4.1.1.
4.1.2 Nom, rôle et valeur (niveau A) : pour tout composant d’interface utilisateur (comprenant mais n’étant pas limité aux éléments de formulaire, liens et composants générés par des scripts), le nom et le rôle peuvent être déterminés par un programme informatique ; les états, les propriétés et les valeurs qui peuvent être paramétrés par l’utilisateur peuvent être définis par programmation ; et la notification des changements de ces éléments est disponible aux agents utilisateurs, incluant les technologies d’assistance.
NOTE : Ce critère de succès s’adresse d’abord aux auteurs qui développent ou programment leurs propres composants d’interface utilisateur. Toutefois, les contrôles HTML standards se conforment déjà à ce critère de succès lorsqu’ils sont utilisés conformément à la spécification.
4.1.3 Messages d’état (niveau AA) : Dans un contenu implémenté via un langage de balisage, les messages d’état peuvent être déterminés par un programme informatique grâce à un rôle ou des propriétés afin qu’ils puissent être présentés à l’utilisateur par des technologies d’assistance sans recevoir le focus.
Voir aussi :
- Version française pour WCAG 2.0 (2010) :
- Vérifier les différences avec la version anglaise pour WCAG 2.2 (2023), qui inclut une documentation révisée pour WCAG 2.0 et 2.1 :
