Test 7.1.3

Note technique du critère 7.1

Le critère 7.1 implémente la notion de « compatible avec les technologies d’assistance » telle que définie par les WCAG, ainsi que le recours à WAI-ARIA pour rendre un composant ou une fonctionnalité accessible. Le bon usage de WAI-ARIA est vérifié via les tests 7.1.1, 7.1.2, 7.1.3.

Note importante : dans un environnement HTML5, beaucoup de composants peuvent nécessiter JavaScript pour fonctionner ; en conséquence la fourniture d’une alternative à un composant JavaScript qui ne pourrait pas être rendu accessible devra bénéficier d’une méthode spécifique au composant en cause, permettant de le remplacer par une alternative accessible (et de le réactiver). Cela signifie que la désactivation de JavaScript pour l’ensemble de la page ne sera pas acceptée comme une méthode valable, à moins qu’elle ne remette pas en cause l’utilisation des autres composants.

Cas particuliers du critère 7.1

Il existe une gestion de cas particuliers pour le test 7.1.3 lorsque :

• La ponctuation et les lettres majuscules sont présentes dans le texte de l’intitulé visible : elles peuvent être ignorées dans le nom accessible sans porter à conséquence ;

• Le texte de l’intitulé visible sert de symbole : le texte ne doit pas être interprété littéralement au niveau du nom accessible. Le nom doit exprimer la fonction véhiculée par le symbole (par exemple, “B” au niveau d’un éditeur de texte aura pour nom accessible “Mettre en gras”, le signe “>” en fonction du contexte signifiera “Suivant” ou “Lancer la vidéo”). Le cas des symboles mathématiques fait cependant exception (voir la note ci-dessous).

Note : si l’étiquette visible représente une expression mathématique, les symboles mathématiques peuvent être repris littéralement pour servir d’étiquette au nom accessible (ex. : “A>B”). Il est laissé à l’utilisateur le soin d’opérer la correspondance entre l’expression et ce qu’il doit épeler compte tenu de la connaissance qu’il a du fonctionnement de son logiciel de saisie vocale (“A plus grand que B” ou “A supérieur à B”).

Définitions

Compatible avec les technologies d’assistance

Un contenu ou une fonctionnalité doit être compatible avec les technologies d’assistance des utilisateurs ainsi qu’avec les fonctions d’accessibilité des navigateurs et des autres agents utilisateurs via une API d’accessibilité.

Cela concerne, à la fois, la technologie, ses fonctionnalités et ses usages :

• La façon dont la technologie Web est utilisée doit être compatible avec les technologies d’assistance des utilisateurs. Cela signifie que la façon dont la technologie est utilisée a été testée dans une perspective d’interopérabilité avec des utilisateurs des technologies d’assistance dans la ou les langues du contenu ;
• La technologie fonctionne de façon native dans des agents utilisateurs largement distribués qui sont, eux-mêmes, compatibles avec l’accessibilité (comme HTML et CSS) ou avec un module d’extension largement distribué qui est, lui-même, compatible avec l’accessibilité.

La vérification de la compatibilité avec les technologies d’assistance nécessite de réaliser un certain nombre de tests spécifiques à la technologie utilisée, par exemple :

• Vérifier le nom, le rôle, le paramétrage et les changements d’états des composants d’interface ;
• Vérifier que la restitution d’un composant d’interface est correcte pour la ou les technologies d’assistance utilisées.

Composant d’interface

Un composant d’interface est un élément avec lequel l’utilisateur peut interagir, par exemple un bouton, un lien, une zone de saisie. Certains composants peuvent être plus complexes comme un menu, une fenêtre de dialogue, un système d’onglets. Enfin, un composant d’interface peut être basé sur des éléments natifs de HTML ou développés de toutes pièces en JavaScript et des attributs WAI-ARIA. En particulier pour les éléments ayant des attributs WAI-ARIA correspondant à un motif de conception il est recommandé de considérer le document WAI-ARIA 1.1 Authoring Practices lors de leur implémentation.

Étiquette de champ de formulaire

Texte à proximité du champ de formulaire permettant d’en connaître la nature, le type ou le format des informations attendues. L’étiquette peut être associée au champ de formulaire de plusieurs manières :

• Par l’utilisation d’une balise <label> ;
• Par l’utilisation de l’attribut WAI-ARIA aria-label ;
• Par l’utilisation d’une liaison entre le texte et le champ par l’attribut WAI-ARIA aria-labelledby ;
• Par l’utilisation de l’attribut title.

Note importante : lorsque plusieurs de ces techniques sont présentes sur un même champ, le calcul du « nom accessible », c’est-à-dire ce qui sera restitué, obéit à un ordre strict :

• aria-labelledby ;
• Sinon aria-label ;
• Sinon <label> ;
• Sinon title.

Cet ordre doit être utilisé pour l’évaluation de la pertinence de l’étiquette (critère 11.2). Par exemple, même dans le cas de la présence d’un <label>, c’est le passage de texte référencé par aria-labelledby qui doit être pris en compte.

Référence : Accessible name and description calculation.

Note importante au sujet de l’utilisation de placeholder : lorsque l’attribut placeholder est présent, il est susceptible d’être restitué à la place de l’attribut title. Par conséquent, lorsque ces deux attributs title et placeholder sont présents, ils doivent être identiques.

Note au sujet des étiquettes liées par aria-labelledby : Il s’agit d’un ou de plusieurs passages de texte identifiés par des id et liés par aria-labelledby sur le modèle suivant : aria-labelledby="ID1 ID2 ID3…".

Note : l’attribut aria-label ne peut pas être utilisé pour indiquer le caractère obligatoire d’un champ.

Intitulé visible

Texte affiché faisant office d’intitulé visible à l’écran au sein d’un bouton ou d’un lien.

Texte affiché faisant office d’étiquette pour un champ formulaire.

Ce texte peut être constitué de texte ou d’une image contenant du texte.

Motif de conception

Un motif de conception (Design Pattern) est un modèle défini dans le document WAI-ARIA 1.1 Authoring Practices qui décrit la structure, les rôles et propriétés et le comportement clavier que doit respecter un composant JavaScript (widget).

Il est recommandé que les composants développés en JavaScript utilisant des attributs WAI-ARIA correspondant à un motif de conception respectent celui-ci. Attention cependant, les motifs de conception ne sont pas tous adaptés à un usage non applicatif, en particulier pour les sites proposant un affichage en contexte mobile.

Note 1 : compte tenu du manque de support de certaines propriétés et de certains rôles WAI-ARIA et de la grande variabilité des situations dans lesquelles un composant JavaScript peut être proposé, il est possible d’adapter des motifs de conception à des contextes ou des utilisations particulières. Dans ce cas, le motif de conception adapté doit :

• Respecter la structure générale : par exemple un ensemble de panneaux (rôle WAI-ARIA tabpanel) d’un système d’onglets est forcément lié à un ensemble d’onglets (rôle WAI-ARIA tablist) ;
• Utiliser en remplacement d’un rôle ou d’une propriété WAI-ARIA mal supporté, un rôle ou une propriété WAI-ARIA équivalent, offrant un comportement et une restitution similaire.

Note 2 : Le fait d’enrichir un motif de conception de rôles ou propriétés WAI-ARIA supplémentaires dont la compatibilité avec l’accessibilité est contrôlée par le test de restitution sur l’environnement de test (ou « base de référence ») ne constitue pas une adaptation d’un motif de conception. Par exemple l’ajout de l’attribut WAI-ARIA aria-hidden sur les panneaux (rôle WAI-ARIA tabpanel) d’un système d’onglets ne définit pas un motif de conception adapté.

Script

Code généralement écrit sous forme d’une liste de commandes (par exemple JavaScript). Les langages interprétés côté client nécessitent un navigateur compatible sur lequel l’exécution du langage est active. Les commandes d’un langage de script côté client peuvent être embarquées ou contenues dans un fichier externe. Dans les deux cas, l’insertion se fait via la balise <script>.