Glossaire

a11y

Une abréviation pour accessibilité : interprétée comme la lettre a suivie de 11 caractères, puis de la lettre y.

Agora

Agora est le dépôt interne d'artéfacts de Deque. Il est basé sur une instance de Artifactory. Grâce à Agora, les utilisateurs peuvent télécharger des composants Axe DevTools, gérer et distribuer des ensembles de règles personnalisés, et plus encore.

Clé API

Une clé API autorise le CLI, Axe Watcher ou les APIs web à envoyer les résultats d'accessibilité vers Axe Developer Hub ou Axe Reports. Traitez votre clé API comme une information confidentielle : ne la soumettez pas au contrôle de version ni ne la partagez, et stockez-la dans une variable d'environnement ou dans le gestionnaire de secrets de votre plateforme CI/CD.

ARIA

Accessible Rich Internet Applications (ARIA) est une spécification technique publiée par le World Wide Web Consortium, ou W3C, qui définit des moyens d'augmenter l'accessibilité des pages web, en particulier le contenu dynamique et les composants d'interface utilisateur développés avec Ajax, HTML, JavaScript, et les technologies associées.

Technologie d'assistance

Certaines personnes en situation de handicap peuvent ne pas être en mesure d'interagir seules avec des logiciels et des sites web. Ces personnes ont besoin de technologies d'assistance pour utiliser Internet de manière équitable. Une forme très courante de technologie d'assistance est un lecteur d'écran. Ces dispositifs lisent le texte à l'écran à haute voix pour les personnes malvoyantes ou aveugles. Il existe de nombreux lecteurs d'écran différents selon la plateforme. Quelques exemples sont NVDA ou JAWS sur PC, VoiceOver sur Mac ou TalkBack sur Android.

Bonnes Pratiques

Les bonnes pratiques de Deque sont des techniques éprouvées qui produisent les résultats d'accessibilité souhaités lorsque des méthodes formelles spécifiques font défaut ou sont insuffisantes. Bien qu'elles ne soient pas officiellement incluses dans des ensembles de règles d'accessibilité établis, le suivi des bonnes pratiques de Deque peut améliorer l'accessibilité et la qualité globale de la page web testée. Il convient de noter qu'un non-respect des lignes directrices des bonnes pratiques de Deque ne signifie pas automatiquement un échec. De plus, un jugement d'expert est nécessaire pour considérer l'adéquation dans le contexte des objectifs de l'application, du site ou de la page. Parfois, la technique d'accessibilité selon les bonnes pratiques n'est pas applicable ou pratique pour résoudre un problème spécifique. Voir Bonnes Pratiques pour les règles qui composent l'ensemble de règles des bonnes pratiques.

Plateforme d'Automatisation de Navigateur

Pour Axe Watcher, un plateforme d'automatisation de navigateur est un cadre 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

• Cypress
• Playwright ou Playwright Test
• Puppeteer
• WebdriverIO ou WebdriverIO Testrunner
• WebDriverJS

Point de Contrôle

Une méthode éprouvée pour le test des exigences d'accessibilité créée par l'équipe d'experts en a11y de Deque qui augmente la cohérence et l'exactitude des résultats de test. Basés sur les Critères de Réussite WCAG, ils fournissent une catégorisation et une interprétation plus explicite de ces directives, où les échecs sont généralement séparés par type de contenu. Les Points de Contrôle Deque aident les réviseurs à produire des résultats de test cohérents et précis lors des évaluations d'accessibilité. Un point de contrôle se réfère à la section la plus pertinente et la plus applicable de la liste maîtresse des Points de Contrôle Deque (et leurs exigences) qui sont une partie importante de la Voie Deque vers l'égalité numérique.

Tests de Composants

Avec Cypress ou Playwright et Axe Watcher, vous pouvez tester des composants individuels (comme les composants React) en isolation. Cela contraste avec Tests de bout en bout, qui teste l'ensemble de l'application web dans sa mise en œuvre réelle. Axe Developer Hub peut détecter des problèmes d'accessibilité dans des scénarios de bout en bout et peut tester des composants en isolation avec Cypress. Voir Tests de bout en bout.

Surcharge de Configuration

Un surcharge de configuration vous permet de personnaliser les paramètres pour des exécutions de test spécifiques via la propriété (JavaScript/TypeScript) configurationOverrides ou (Java) Classe ConfigurationOverrides dans votre configuration de test. Ces surcharges doivent être conformes aux paramètres de configuration globaux de votre organisation et peuvent inclure des modifications des normes d'accessibilité, des bonnes pratiques, des règles expérimentales et des versions d'axe-core.

Ensemble de Règles Personnalisées

Un ensemble de règles personnalisées est construit à partir d'un fichier JSON contenant les données de règles (règles et vérifications) passées aux composants Axe DevTools pour ajouter de nouvelles règles, changer la sévérité/l'impact d'une règle ou retirer une règle du test.

Dupliquer

Un dupliquer 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 duplicatas, tous ses duplicatas disparaîtront car ils sont tous le même problème.

Deux résultats sont considérés comme le même problème lorsque les trois éléments suivants correspondent :

• La règle qui a été violée.
• L'élément. Axe Developer Hub identifie l'élément par son sélecteur CSS et son XPath, ainsi que par son sélecteur d'ascendance lorsque ancestry est activé. Une correspondance sur l'un quelconque de ceux-ci suffit.
• L'URL de la page, comparée dans son intégralité, y compris toute chaîne de requête.

Rien d'autre n'est comparé. En particulier, le titre de la page et le HTML de l'élément n'ont aucun effet sur le traitement d'un résultat comme doublon.

La même comparaison détermine si un problème est nouveau : un résultat qui ne correspond à rien dans la référence applicable est compté comme nouveau. Cela signifie que si l'URL d'une page ou ses sélecteurs d'élément changent entre les analyses, le même problème sous-jacent est signalé comme nouveau à chaque fois. Voir Utilisation de sélecteurs dynamiques pour savoir comment corriger cela.

Tests de bout en bout

Le test de bout en bout, ou bout en bout, se réfère à tester l'ensemble des fonctionnalités de l'application web en testant sa mise en œuvre réelle. Avec Axe Developer Hub, vous pouvez tester des scénarios e2e pour détecter des problèmes d'accessibilité et tester des composants individuels en isolation avec Cypress. Voir aussi Tests de Composants.

Événement

Pour suivre l'utilisation de l'API ou du CLI, la bibliothèque de métriques crée des événements et les envoie au service d'usage. Les événements contiennent des informations sur l'utilisation telles que le nombre de règles d'accessibilité enfreintes lors d'un scan de page web et la date et l'heure à laquelle un scan d'accessibilité a été complété.

Règles expérimentales

Règles expérimentales sont encore en cours de développement et de test pour répondre aux nouvelles technologies ou à une compréhension et sensibilisation accrues des problèmes d’accessibilité. Ces règles ne devraient pas être utilisées dans des environnements de production car elles sont encore en développement et peuvent occasionner des faux positifs. Finalement, les règles de cet ensemble pourraient devenir 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.

Flush

La fonction flush écrit les résultats de vos tests Axe Watcher sur le serveur Deque et est nécessaire pour s'assurer que les résultats sont enregistrés par Axe Developer Hub. Vous devez appeler la fonction flush dans votre suite de tests.

Gitless

Gitless est l'une des deux formes de données auxquelles un projet Developer Hub peut être verrouillé : la suite de tests du projet n'utilise pas un dépôt Git. Un projet se verrouille sur Gitless, ou sur Git, en fonction de sa première session réussie ; une exécution ultérieure avec l'autre forme de données est rejetée plutôt qu'acceptée. Vous n'êtes pas obligé d'utiliser un dépôt Git, mais un dépôt Git vous permet d'associer des défauts d'accessibilité à des modifications de code spécifiques, facilitant ainsi leur résolution. Voir Verrouillage de projet.

Configuration globale

configuration globale fait partie de Configuration d'Axe qui vous permet de définir diverses options en un seul endroit pour être partagées entre différents produits Deque. Votre administrateur peut autoriser certains paramètres à être modifiés par les utilisateurs.

Jeton d'identité

Un Jeton d'identité est un jeton de sécurité émis par JFrog qui vous permet d'accéder au dépôt d'artefacts Agora de Deque. Les jetons d'identité doivent être copiés au moment de leur création car c'est la seule occasion de les accéder. Ils expirent après un intervalle de temps désigné, généralement un an.

Impact

Chaque infraction en matière d'accessibilité se voit attribuer un niveau d'impact. L'impact est une métrique utile lors de la priorisation des efforts de remédiation. Par défaut, chaque type d'infraction se voit attribuer un niveau d'impact par les experts en accessibilité de Deque. Ces valeurs sont généralisées pour la plupart des situations, de sorte que les utilisateurs peuvent les modifier à leur discrétion dans le cadre de la personnalisation de leur ensemble de règles. Les niveaux d'impact graves ou critiques correspondent à des utilisateurs handicapés rencontrant des obstacles significatifs ou insurmontables. Ceux-ci entraînent le plus grand degré de responsabilité légale. Les problèmes mineurs et modérés ne sont pas aussi sérieux, mais représentent néanmoins des enjeux importants pour les utilisateurs handicapés et nécessitent une attention pour que la page soit pleinement conforme. Les quatre niveaux suivants sont utilisés pour catégoriser l'impact des problèmes d'accessibilité détectés :

• Critique : Ce niveau d'impact signifie que les utilisateurs handicapés seront empêchés complètement d'accéder ou d'interagir avec une fonctionnalité sur la page web. Tant qu'une solution n'est pas mise en œuvre, le contenu sera totalement inaccessible. Cela rend votre organisation très vulnérable aux poursuites judiciaires. La réparation des problèmes critiques doit être une priorité absolue.

• Sérieux : Ce niveau d'impact signifie que les utilisateurs handicapés rencontreront de sérieux obstacles lors de l'interaction avec le site. Ces utilisateurs ressentiront une frustration significative lorsqu'ils tenteront d'accéder au contenu lié. Tant qu'une solution n'est pas mise en œuvre, certains contenus seront difficiles ou impossibles à accéder, rendant votre organisation vulnérable à des actions en justice. La réparation doit être une priorité élevée.

• Modéré : Ce niveau d'impact signifie que certains obstacles existent pour les utilisateurs handicapés, mais qu'ils ne les empêcheraient pas d'accéder aux flux ou contenus de base. Les problèmes ayant un impact à ce niveau peuvent rendre votre organisation vulnérable à des actions en justice. Ils nécessitent une résolution avant que la page ne soit entièrement conforme et doivent être corrigés.

• Mineur : Un problème qui a moins d'impact pour les utilisateurs handicapés qu'un problème modéré. Le problème peut constituer une priorité plus basse que les problèmes modérés, sérieux et critiques, mais nécessite toujours une résolution pour qu'une page soit entièrement conforme.

Incomplet

Un résultat incomplet signifie qu'axe-core n'a pas pu déterminer avec certitude si quelque chose est une violation, donc une inspection humaine est nécessaire. Parce qu'axe-core vise zéro faux positif, il ne signale comme violations que les problèmes certains et enregistre tout ce qui est incertain séparément. Incomplet et nécessite une révision sont deux noms pour le même type de résultat ; celui que vous voyez dépend du composant Axe DevTools que vous utilisez. Un résultat incomplet peut ou non se révéler être un problème d'accessibilité.

Test guidé intelligent (TGI)

Le test guié intelligent (IGT) est un composant interactif de test d'accessibilité des extensions de navigateur Web Axe DevTools conçu pour trouver les erreurs d'accessibilité qui ne peuvent pas être détectées par des tests automatisés. IGT pose à l'utilisateur des questions simples sur la page web en cours de test et utilise ce retour d'information pour localiser plus d'erreurs d'accessibilité que ce qui serait possible avec les tests automatisés. Pour en savoir plus sur les tests guidés intelligents, visitez le Documentation des tests guidés intelligents.

Problème

Une violation des directives d'accessibilité (telles que définies par les normes comme WCAG 1.0, WCAG 2.0, Section 508 et WAI-ARIA) identifiée dans le code d'une page web ou d'une application web.

Résultats d'accessibilité JSON

Lorsque vous testez un site web pour des problèmes d'accessibilité en utilisant les API ou la CLI d'Axe DevTools, vos résultats sont enregistrés sous forme de fichier JSON qui est appelé dans la documentation un fichier résultats d'accessibilité JSON. Vous pouvez télécharger ce fichier sur Axe Reports (ce qui vous permet de suivre l'accessibilité de votre site web au fil du temps via le site Axe Reports). Vous pouvez également filtrer et convertir localement le fichier de résultats d'accessibilité JSON en .csv, .xml ou .html en utilisant la CLI. Voir Rapports avec l'interface de ligne de commande pour plus d'informations. Alternativement, les API vous permettent également de convertir les fichiers de résultats d'accessibilité JSON en rapports lors d'un test (voir ci-dessous Rapports pour plus d'informations).

Mode manuel

Par défaut, Axe Developer Hub analyse automatiquement chacune de vos pages web et ré-analyse les pages dès qu'il détecte un nouvel état de la page. Vous pouvez désactiver ce comportement automatique en

• (JavaScript/TypeScript) En définissant la propriété autoAnalyze sur objet de configuration axe à false.
• (Java) En appelant la méthode setAutoAnalyze() avec false.

Vous pouvez également remplacer le comportement d'analyse automatique en

• (JavaScript/TypeScript) En appelant la méthode stop().
• (Java) En appelant la méthode AxeWatcherController.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().

Bibliothèque de métriques

Une bibliothèque interne utilisée par les API et les CLI de Deque pour rapporter les informations d'utilisation au service d'utilisation.

Suite de tests modifiée

Un suite de tests modifiée est une suite de tests que vous avez modifiée selon les instructions fournies par Axe Developer Hub lorsque vous avez créé un nouveau projet. Modifier votre suite de tests vous permet d'ajouter des tests d'accessibilité à votre suite de tests existante avec des changements minimaux à la suite elle-même.

Nécessite une révision

Un problème nécessite une inspection par une personne pour déterminer s'il s'agit d'une véritable violation des normes d'accessibilité. Nécessite une révision signifie la même chose que incomplet : axe-core n'a pas été capable de déterminer avec certitude si le problème est une violation. Si vous débutez dans les tests d'accessibilité, ou travaillez sur un site avec de nombreux problèmes connus, traitez d'abord les violations. Lorsque vous arrivez aux résultats nécessitant une révision, consultez un expert en accessibilité numérique avant de décider de les corriger ou de les ignorer.

État de la page

L'état de la 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 monopage (SPA). Exemples d'état du DOM :

• La visibilité des éléments
• Le contenu des éléments
• L'état coché des boutons radio et des cases à cocher

Le package Watcher rescanne les pages web lorsqu'il détecte des modifications au DOM et enregistre un nouvel état de la page à chaque fois.

Projet

Un projet dans Axe Developer Hub contient les résultats d'accessibilité, les informations de test et les données Git (branches et commits). L'association entre ces informations et le projet se fait par le ID de projet du projet. Lorsque vous créez et nommez un nouveau projet dans Axe Developer Hub, il génère un ID de projet que vous utilisez avec vos tests pour identifier le projet.

Rapports

Le reporting fait référence au téléversement d'un fichier résultats d'accessibilité JSON vers Axe Reports ou à sa conversion locale en un rapport (.csv, .xml ou .html) pour une utilisation dans une autre application.

RGAA

Le RGAA, ou Référentiel Général d'Amélioration de l'Accessibilité, est la norme d'accessibilité web du gouvernement français. Elle est largement basée sur les WCAG 2.1 et fournit des critères techniques spécifiques pour évaluer l'accessibilité du contenu web. La version actuellement supportée est le RGAA 4, identifié par l'ID de règles rgaav4.

Règle

Une règle correspond à un critère de réussite des lignes directrices pour l'accessibilité. Elles sont définies par des fichiers d'objets JSON et contiennent un identifiant, une description et des métadonnées d'aide ainsi qu'un ou plusieurs contrôles et des paramètres optionnels.

Section 508

Un amendement à la Loi sur la Réhabilitation des États-Unis de 1973 qui exige que les agences fédérales rendent leur technologie électronique et d'information accessible aux personnes handicapées. Il comprend seize dispositions basées sur des lignes directrices d'accès développées par les Directives pour l'accessibilité du contenu web (WCAG) développées par le World Wide Web Consortium (W3C) mais ne sont pas identiques aux normes WCAG 1.0 ou 2.0.

SHA

Lorsque vous créez un commit Git, cela génère un identifiant qui identifie de manière unique le commit. L'identifiant unique est appelé un SHA (un acronyme pour Secure Hash Algorithms, un groupe de fonctions de hachage cryptographiques).

Service d'utilisation

Un service web REST qui enregistre les métriques d'utilisation pour Axe DevTools pour le Web (API et CLI). C'est soit le service public fourni par Deque, soit votre propre service. Pour plus d'informations, voir Le service d'utilisation d'Axe DevTools pour le Web.

Violation

Un problème identifié par Axe DevTools qui enfreint une ou plusieurs normes d'accessibilité.

Watcher

Le composant de code que vous intégrez dans votre suite de tests s'appelle Watcher. Deque propose plusieurs éditions du package pour les langues prises en charge et les frameworks de test. Vous intégrez le package Watcher dans votre suite de tests de site web pour analyser les pages web et rapporter les résultats à Axe Developer Hub, où vous pouvez voir les résultats. Le package Watcher analyse également le commit Git et la branche actuels et associe les tests avec cela.

WCAG

Les WCAG, ou Web Content Accessibility Guidelines, ont été développées par le World Wide Web Consortium (W3C) et expliquent comment rendre le contenu web plus accessible aux personnes handicapées. WCAG 1.0 a été publié en mai 1999. WCAG 2.0 a été publié en décembre 2008. WCAG 2.0 s'applique généralement à des technologies plus avancées et est plus précisément testable avec des tests automatisés et l'évaluation humaine. WCAG 2.1 a été publié en juin 2018. Ces lignes directrices contiennent des critères de réussite qui définissent des critères testables pour des éléments spécifiques. WCAG 2.2, la itération la plus récente des lignes directrices, a été publiée en 2023 et offre neuf nouveaux critères de réussite par rapport à WCAG 2.1.

Enveloppement

L'Enveloppement fait référence à la modification d'une plateforme d'automatisation de navigateur (comme Cypress) pour appeler le code de test d'accessibilité (dans le package Watcher) chaque fois qu'une fonction de la plateforme d'automatisation de navigateur est appelée. L'enveloppement vous permet d'intégrer les tests d'accessibilité dans vos suites de tests existantes avec des changements minimes à votre code.