Glossaire du axe Developer Hub
Termes utiles pour comprendre axe Developer Hub
a11y
Abréviation basée sur le nombre (ou numéronyme) pour accessibilité avec 11 (onze) représentant le nombre de caractères entre le a commençant par et le y se terminant par dans accessibilité. Prononcé ally.
Clé API
Une clé API est créée par axe Developer Hub chaque fois que vous créez un nouveau projet. La clé relie les exécutions de tests et leurs résultats à un projet donné. Il doit être défini dans la suite de tests pour permettre à ses résultats d'être associés à un projet spécifique.
axe Developer Hub
axe Developer Hub vous permet de créer de nouveaux projets de test et vous montre les résultats de vos tests d'accessibilité. Vous pouvez filtrer les résultats par date, ID de session et gravité. Vous pouvez surveiller vos résultats d'accessibilité et les regrouper par ID de session. Vous pouvez créer autant de projets que vous le souhaitez pour surveiller différents sites Web.
Le package @axe-core/watcher
Vous intégrez le package @axe-core/watcher dans la suite de tests de votre site Web pour analyser les pages Web et signaler les résultats à axe Developer Hub où vous pouvez afficher les résultats. Le package @axe-core/watcher analyse également le commit et la branche Git actuels et associe les exécutions de test au commit actuel. Seul Google Chrome est pris en charge par le package @axe-core/watcher lors du test de votre site Web. Voir Configuration requise.
Bonnes pratiques
Les meilleures pratiques Deque sont des techniques éprouvées qui fournissent les résultats d'accessibilité souhaités lorsque des méthodes formelles spécifiques font défaut ou sont insuffisantes. Bien qu'ils ne soient pas officiellement inclus dans les règles d'accessibilité établies, le suivi des meilleures pratiques Deque peut améliorer l'accessibilité et la qualité globale de la page Web testée. Il convient de noter que le non-respect des directives de bonnes pratiques Deque n’indique pas automatiquement un échec. De plus, le jugement d’un expert est nécessaire pour évaluer la pertinence dans le contexte des objectifs de l’application, du site ou de la page. Parfois, les meilleures pratiques en matière d’accessibilité ne sont pas applicables ou réalisables pour résoudre un problème spécifique. Consultez Meilleures pratiques pour connaître les règles qui composent l'ensemble de règles des meilleures pratiques.
Plateforme d'automatisation du navigateur
Une plateforme d'automatisation de navigateur est un framework que vous utilisez pour automatiser les tests de votre site Web. Les plateformes incluent Cypress, Playwright, Puppeteer, WebdriverIO et WebDriverJS. Pour plus d'informations, voir
Test des composants
Avec Cypress ou Playwright, vous pouvez tester des composants individuels (tels que les composants React) de manière isolée. Comparez cela avec e2e Testing, qui teste l'intégralité de l'application Web dans son implémentation réelle. Axe Developer Hub ne peut détecter les problèmes d'accessibilité que dans des scénarios de bout en bout et n'est pas conçu pour tester les composants de manière isolée. Voir Test de bout en bout.
Remplacement de la configuration
Un remplacement de la configuration vous permet de personnaliser les paramètres pour des exécutions de tests spécifiques via la propriété configurationOverrides dans votre configuration de test. Ces remplacements doivent être conformes aux paramètres de configuration globaux de votre organisation et peuvent inclure des modifications des normes d'accessibilité, des meilleures pratiques, des règles expérimentales et des versions axe-core.
Dupliquer
Une duplication est le même problème d'accessibilité observé sur le même nœud du modèle d'objet de document (DOM) dans plusieurs états de page. Si vous corrigez un problème avec des doublons, tous ses doublons disparaîtront car ils représentent tous le même problème.
Tests e2e
Les tests de bout en bout, ou e2e, font référence au test de l'ensemble des fonctionnalités de l'application Web en testant sa mise en œuvre dans des conditions réelles. Avec axe Developer Hub, vous pouvez tester des scénarios e2e pour les problèmes d'accessibilité, mais vous ne pouvez pas tester des composants individuels de manière isolée, comme le proposent Cypress et Playwright. Voir aussi Test des composants.
Règles expérimentales
Des règles expérimentales sont encore en cours d’élaboration et de tests pour répondre aux nouvelles technologies ou pour une compréhension et une sensibilisation accrues aux problèmes d’accessibilité. Ces règles ne doivent pas être utilisées dans les environnements de production, car elles sont encore en développement et sont sujettes à de faux positifs. À terme, les règles de cet ensemble de règles pourraient faire partie des normes d’accessibilité. Les règles expérimentales sont désactivées par défaut. Voir Règles expérimentales pour les règles qui composent cet ensemble de règles dans la dernière version d'axe-core.
Vider
La fonction vider écrit les résultats de vos tests sur le serveur Deque et est nécessaire pour garantir que les résultats sont enregistrés par axe Developer Hub. Vous devez appeler la fonction vider dans votre suite de tests.
Gitless
Gitless fait référence à l'utilisation du package @axe-core/watcher sans référentiel Git. Vous n'êtes pas obligé d'utiliser un référentiel Git, mais un référentiel Git vous permet d'associer des défauts d'accessibilité à des modifications de code spécifiques, facilitant ainsi leur résolution.
Configuration globale
La configuration globale fait partie de axe Configuration qui vous permet de définir diverses options en un seul endroit à partager entre différents produits Deque. Votre administrateur peut autoriser les utilisateurs à modifier certains paramètres.
Impact
Un niveau d'impact est attribué à chaque violation d'accessibilité, classée en quatre niveaux du moins au plus impactant : mineur, modéré, grave et critique. Cette mesure permet de hiérarchiser les efforts de correction, et les experts en accessibilité de Deque attribuent un niveau d'impact à chaque type de violation par défaut.
Les défauts ayant un niveau d'impact grave ou critique présentent des obstacles importants ou insurmontables pour les utilisateurs handicapés, entraînant la responsabilité juridique la plus élevée. Bien que les problèmes mineurs et modérés ne soient pas aussi graves, ils restent essentiels pour assurer la conformité et répondre aux besoins des personnes handicapées.
Les quatre niveaux utilisés pour catégoriser l’impact des problèmes d’accessibilité sont les suivants :
-
Mineur : problèmes qui affectent moins les utilisateurs handicapés que les problèmes modérés, mais qui nécessitent néanmoins une résolution pour une conformité totale.
-
Modéré : Certains obstacles existent pour les utilisateurs handicapés, mais ne les empêcheraient pas d’accéder au contenu ou aux flux de base. Ces problèmes peuvent rendre votre organisation vulnérable aux poursuites judiciaires et doivent être résolus avant d’atteindre la pleine conformité.
-
Sérieux : les utilisateurs handicapés seront confrontés à des obstacles importants lors de l'interaction avec le site, ce qui entraînera de la frustration et des difficultés d'accès au contenu associé. La correction devrait être une priorité absolue pour éviter des poursuites judiciaires.
-
Critique : les utilisateurs handicapés ne peuvent pas accéder ou interagir avec une fonctionnalité de la page Web, ce qui rend le contenu inaccessible et rend votre organisation très vulnérable aux poursuites judiciaires. La résolution des problèmes critiques devrait être une priorité absolue.
Mode manuel
Par défaut, axe Developer Hub analyse automatiquement chacune de vos pages Web et réanalyse les pages chaque fois qu'il détecte un nouvel état de page. Vous pouvez désactiver ce comportement automatique en définissant la propriété autoAnalyze sur l'objet de configuration axe sur false. Vous pouvez également remplacer le comportement d'analyse automatique en utilisant la méthode stop . Dans les deux cas, cela met Watcher en mode manuel. En mode manuel, les pages ne sont analysées que lorsque vous appelez la méthode analyze .
Suite de tests modifiée
Une suite de tests modifiée est une suite de tests que vous avez modifiée conformément aux instructions fournies par axe Developer Hub lorsque vous avez créé un nouveau projet. La modification de votre suite de tests vous permet d'ajouter des tests d'accessibilité à votre suite de tests existante avec des modifications minimales à la suite de tests elle-même.
État de la page
L' état de page d'une page Web fait référence à l'état de son modèle d'objet de document (DOM) à un moment précis. Les états de page sont utiles pour les sites Web complexes avec des écrans de connexion ou une interface utilisateur dynamique comme les applications à page unique (SPA). Voici quelques exemples d'état DOM :
- La visibilité des éléments
- Le contenu des éléments
- L'état coché des boutons radio et des cases à cocher
Le package @axe-core/watcher réanalyse les pages Web lorsqu'il détecte des modifications dans le DOM et enregistre un nouvel état de page à chaque fois.
Projet
Un projet dans axe Developer Hub contient les résultats d'accessibilité, les informations sur les exécutions de tests et les données Git (branches et commits). L'association entre ces informations et le projet se fait via la clé API du projet. Vous créez et nommez un nouveau projet dans axe Developer Hub, ce qui crée une clé API à utiliser avec vos tests pour identifier le projet.
ID de session
L' ID de session est généré automatiquement en tant qu'UUID et identifie la connexion d'un utilisateur sur une machine particulière. La plupart des utilisateurs n’ont généralement pas besoin de modifier l’ID de session. Toutefois, si vous devez faire une distinction entre différentes exécutions de test, vous pouvez utiliser différents ID de session. Vous devez utiliser un identifiant unique à l’échelle mondiale, comme un UUID, pour éviter d’éventuelles collisions d’identifiants de session au sein d’une même organisation.
Le SHA
Lorsque vous créez un commit avec Git, il crée un ID pour identifier de manière unique le commit. L'ID unique est appelé SHA (nommé d'après Secure Hash Algorithms, un groupe de fonctions de hachage cryptographique).
Balise
Un tag regroupe les règles qui appartiennent à une directive d'accessibilité spécifique comme WCAG. Pour plus d'informations sur les règles et les balises auxquelles ces règles appartiennent, voir Descriptions des règles axe-core
WCAG
Les WCAG, ou Directives pour l'accessibilité du contenu Web, sont un ensemble de directives élaborées par le World Wide Web Consortium (W3C) pour aider à rendre le contenu Web plus accessible aux personnes handicapées. Ces lignes directrices fournissent un cadre pour la création de sites Web et de contenus numériques accessibles qui peuvent être utilisés par des personnes souffrant d’un large éventail de handicaps.
Les trois niveaux de conformité des WCAG sont définis par un ensemble de critères de réussite qui décrivent des éléments spécifiques du contenu Web qui doivent être respectés pour atteindre ce niveau de conformité. Le niveau de conformité A est le niveau de conformité minimum, tandis que le niveau de conformité AAA est le plus strict. Le niveau de conformité AA requiert la conformité aux critères de réussite des niveaux A et AA. La conformité aux trois niveaux de critères de réussite (A, AA et AAA) est requise pour la conformité au niveau AAA.
WCAG 1.0 était la première version de ces directives et a été publiée en 1999. WCAG 2.0 a été publié en 2008 et a fourni des directives plus complètes pour rendre le contenu Web accessible aux personnes souffrant d'un plus large éventail de handicaps.
WCAG 2.1 a été publié en 2018. Il s'appuie sur les versions précédentes et inclut de nouveaux critères de réussite pour résoudre les problèmes d'accessibilité apparus depuis la sortie de WCAG 2.0. WCAG 2.1 fournit également des conseils supplémentaires sur l'accessibilité mobile, l'accessibilité aux personnes malvoyantes et les troubles cognitifs et d'apprentissage.
WCAG 2.2, l'itération la plus récente de ces directives, a été publiée en 2023 et propose neuf nouveaux critères de réussite par rapport aux WCAG 2.1. Il fournit des conseils améliorés pour répondre aux besoins des utilisateurs souffrant de troubles cognitifs ou d’apprentissage, des utilisateurs malvoyants et des utilisateurs handicapés sur les appareils mobiles. Il est rétrocompatible avec WCAG 2.1.
Encapsulation
L'encapsulation fait référence à la modification d'une plate-forme d'automatisation de navigateur (telle que Cypress) pour appeler le code de test d'accessibilité (dans le package @axe-core/watcher) chaque fois qu'une fonction de plate-forme d'automatisation de navigateur est appelée. L'encapsulation vous permet d'intégrer des tests d'accessibilité dans vos suites de tests existantes avec des modifications minimales de votre code.