Test 7.1.2

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

Alternative (à script)

Texte ou procédé associé au script via une technique appropriée et permettant de mettre à disposition une fonction ou un contenu similaire à celui proposé par script.

Note : lorsqu’une alternative à un procédé ou une fonctionnalité JavaScript est proposée, le moyen d’y accéder doit être fourni par le site lui-même. Il peut s’agir d’un lien ou d’un bouton permettant d’accéder à une page alternative fonctionnant sans JavaScript ou permettant de remplacer le(s) composant(s) par un composant alternatif fonctionnant sans JavaScript par exemple.

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.

Correctement restitué (par les technologies d’assistance)

Lorsqu’un critère, un test ou une condition de test demande de vérifier la restitution d’un dispositif, il faut s’assurer que ladite restitution est compatible avec l’accessibilité.

Le test consiste à vérifier que la restitution est pertinente pour au moins une des combinaisons de l’environnement de test (ou « base de référence ») utilisé pour déclarer qu’un élément, un dispositif ou une alternative est « compatible avec l’accessibilité ».

Par exemple : le test 1.3.8 demande de vérifier que l’alternative d’une image bitmap (balise <canvas>) porteuse d’information est correctement restituée.

On procède alors à un test avec les outils de l’environnement de test défini pour le site.

Si on constate que l’alternative est correctement restituée, le test est validé.

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