Robuste

Le problème

Les mécanismes permettant l’interactivité ne sont pas toujours perceptibles ou utilisables avec les technologies d’adaptation informatique utilisées par les personnes ayant des limitations visuelles, motrices ou cognitives. Toutes les fonctionnalités d’interactivité doivent donc être soigneusement testées avec ces outils.

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 WCAG 2.1) : 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 anglaise pour WCAG 2.2 (2023) :

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 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.

Les critère 4.1.2 et 4.1.3 font référence à la spécification WAI-ARIA. Vous trouverez les explications utiles dans cette section.

Explications techniques

Utilisation de JavaScript

À propos de l’utilisation de JavaScript, WCAG 1.0 était beaucoup plus sévère que WCAG 2.0. Cela 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.

À partir de 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 composants interactifs

Pour des contenus HTML de base tels des en-têtes de section, des liens, des listes, et du texte de façon générale, y compris le texte de remplacement des images, les outils d’adaptation tendent à se comporter de manière équivalente.

Toutefois, quand il s’agit de programmation et d’interactivité, des différences peuvent survenir selon les outils d’adaptation employés, les versions de ces outils, et les navigateurs Web utilisés en combinaison. C’est pourquoi il est crucial de porter une attention toute particulière aux composants interactifs.

La banque de composants Web accessibles du Laboratoire fournit des exemples de composants interactifs développés pour en maximiser la compatibilité et l’utilisabilité avec des outils d’adaptation. Chaque fiche de composant documente les principales caractéristiques fonctionnelles et techniques à surveiller pour assurer cette robustesse.

Pour les personnes exerçant un rôle technique (ex. : conception et développement Web), nous recommandons la lecture de la section WAI-ARIA et HTML5 des notes de cours. WAI-ARIA est une spécification du W3C dont les diverses techniques permettent de communiquer aux outils d’adaptation des informations sur le nom, le rôle, l’état, les propriétés et les valeurs de chaque composant interactif. En plus de la spécification WAI-ARIA, le W3C met à jour périodiquement des notes (en anglais) sur l’utilisation d’ARIA en HTML et un Guide des pratiques de conception ARIA.

Il demeure possible d’offrir une version de remplacement de contenus interactifs qui ne fait pas appel à ce type de fonctionnalités. Par exemple, comme solution de rechange accompagnant une carte interactive, on pourrait proposer un affichage en texte structuré des adresses et informations présentes. De même, si la navigation d’un site Web comporte des menus déroulants ou présentés sous forme d’arborescence, mais que l’en-tête de chaque menu conduit à une page intermédiaire reprenant tous les liens du menu déroulant, cette navigation est tout de même jugée accessible. En effet, l’utilisateur dispose d’un autre moyen pour accéder au même contenu. Bien entendu, la version de remplacement doit répondre à l’ensemble des critères d’accessibilité du niveau de conformité visé.

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 exemples dans la section : Understanding Success Criterion 4.1.3: Status Messages.