Glossaire Axe Developer Hub

a11y

Abréviation basée sur des chiffres (ou numéronyme) pour le mot «accessibilité», avec «11» (onze) représentant le nombre de caractères entre le «a» de départ et le «y» final dans accessibilité. Prononcé comme allié.

Clé API

Pour l'autorisation, vous allez générer une clé API dans les Paramètres du compte Axe. Vous pouvez utiliser la même clé API pour plusieurs projets, bien que vous deviez utiliser une clé API Axe Developer Hub uniquement pour les projets web et une clé API Axe DevTools Mobile uniquement pour les projets mobiles.

Considérez votre clé API comme un identifiant secret : ne l'intégrez pas dans le contrôle de version, ne la partagez pas et stockez-la dans une variable d'environnement ou dans le gestionnaire de secrets de votre plateforme CI/CD.

Axe Developer Hub

Axe Developer Hub vous permet de créer de nouveaux projets de test et vous montre les résultats de vos exécutions de tests d'accessibilité. Vous pouvez créer autant de projets que nécessaire pour visualiser et gérer l'accessibilité de vos sites web et applications mobiles.

Référence

Une référence est l'analyse antérieure que le Developer Hub conserve constante afin qu'une comparaison puisse mesurer les changements. L'analyse utilisée comme référence dépend du type de comparaison : une comparaison inter-branche utilise la dernière exécution de pipeline sur la branche par défaut, et une comparaison au sein de la branche, avec la Action GitHub, utilise l'analyse du commit précédent qui a des résultats sur la même branche.

bonnes pratiques

Les bonnes pratiques de Deque sont des techniques éprouvées par le temps qui fournissent 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 les ensembles de règles d'accessibilité établis, suivre les meilleures pratiques de Deque peut améliorer l'accessibilité et la qualité globale de la page testée. Il convient de noter que le non-respect des directives des meilleures pratiques de Deque n'indique 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 meilleure pratique en matière d'accessibilité 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 des règles de bonnes pratiques.

ID de build

Le ID de build est automatiquement généré en tant qu'UUID lorsqu'il n'est pas fourni par l'utilisateur, et il est utilisé pour lier les analyses ensemble comme une seule session de test. Lors de l'exécution d'une suite de tests sur plusieurs machines ou environnements, fournir un ID de build reliera toutes ces exécutions ensemble et sera affiché comme une seule session dans Developer Hub.

Comparaison inter-branche

Une comparaison inter-branche compare la dernière analyse d'une branche avec la dernière exécution de pipeline de la branche par défaut du projet. Elle apparaît dans la vue Branches et montre ce qui changerait si la branche était fusionnée immédiatement.

Structure de données

La structure de données d'un projet est soit répertoire Git, soit Sans Git : elle détermine si ses résultats contiennent des informations Git (dépôt, branche et commit) ou non. La structure de données d'un projet est définie par son verrouillage du projet.

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 la page. Si vous corrigez un problème avec des doublons, tous ses doublons disparaîtront car ils sont tous le même problème.

Deux résultats sont traités comme le même problème lorsque les trois critères 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 de ces critères 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'affectent pas le fait qu'un résultat soit considéré comme un doublon.

La déduplication s'applique actuellement uniquement aux projets web. Les résultats mobiles n'ont pas de sélecteur CSS, cette comparaison ne correspond donc jamais, et chaque résultat mobile est traité comme nouveau dans chaque comparaison, sans possibilité de modifier ce paramètre.

La même comparaison détermine si un résultat web est nouveau : un résultat qui ne correspond à rien dans la référence applicable est compté comme nouveau. Voir Pourquoi les mêmes problèmes continuent-ils d'être signalés comme nouveaux ? pour savoir comment corriger cela.

Test E2E

Les tests de bout en bout, ou e2e, se réfèrent à tester la fonctionnalité entière de l'application web en testant son implémentation réelle. Avec Axe Developer Hub, vous pouvez tester des scénarios e2e pour des problèmes d'accessibilité.

Règles expérimentales

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

répertoire Git

répertoire Git est une structure de données à laquelle un projet Developer Hub peut se verrouiller : la suite de tests du projet utilise un dépôt Git. L'utilisation de Git vous permet d'associer les défauts d'accessibilité au code sur différentes branches et dans des commits spécifiques, ce qui facilite leur résolution.

Sans Git

Sans Git est l'autre structure de données à laquelle un projet Developer Hub peut se verrouiller : la suite de tests du projet n'utilise pas de dépôt Git. Bien qu'il ne soit pas obligatoire, un dépôt Git vous permet d'associer les défauts d'accessibilité à des modifications spécifiques du code, ce qui facilite leur résolution.

Impact

Un niveau impact est attribué à chaque violation d'accessibilité, classé en quatre niveaux du moins au plus impactant : mineur, modéré, sérieux et critique. Cette mesure aide à prioriser les efforts de remédiation, et les experts en accessibilité de Deque attribuent par défaut un niveau d'impact à chaque type de violation.

Les défauts avec des niveaux d'impact sérieux ou critique présentent des obstacles importants ou insurmontables pour les utilisateurs ayant des déficiences, avec la responsabilité légale la plus élevée. Bien que les problèmes de niveaux mineur et modéré ne soient pas aussi graves, ils restent cruciaux pour la conformité et pour répondre aux besoins de ceux ayant des déficiences.

Les quatre niveaux utilisés pour catégoriser l'impact des problèmes d'accessibilité sont :

1. Mineur : Les problèmes qui affectent les utilisateurs ayant des déficiences moins que des problèmes modérés mais qui nécessitent tout de même une résolution pour une conformité complète.

2. Modéré : Quelques obstacles existent pour les utilisateurs ayant des déficiences mais ne les empêcheraient pas d'accéder aux contenus ou flux de base. Ces problèmes peuvent rendre votre organisation vulnérable aux actions en justice et devraient être résolus avant d'atteindre une conformité complète.

3. Sérieux : Les utilisateurs ayant des déficiences feront face à des obstacles significatifs en interagissant avec le site, provoquant frustration et difficulté à accéder aux contenus liés. La remédiation doit être une priorité élevée pour éviter des actions en justice.

4. Critique : Les utilisateurs ayant des déficiences sont complètement bloqués pour accéder ou interagir avec une fonctionnalité de la page web, rendant le contenu inaccessible et laissant votre organisation hautement vulnérable aux poursuites. La remédiation des problèmes critiques devrait être une priorité absolue.

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 lors de la création d'un nouveau projet. Modifier votre suite de tests vous permet d'ajouter des tests d'accessibilité à votre suite de tests existante avec des changements minimes à la suite elle-même.

Nécessite une révision

Un résultat Nécessite une révision est celui où axe-core n'a pas pu déterminer avec certitude si quelque chose constitue une violation, il faut donc qu'une personne l'inspecte. Consultez Nécessite une révision dans le glossaire d'Axe DevTools pour le Web pour la définition complète. Le Hub des développeurs Axe n'affiche pas les résultats Nécessite une révision dans son interface utilisateur et ne les inclut pas dans les totaux de problèmes ou dans le score d'accessibilité. Ils apparaissent uniquement dans le Export JSON Axe Universal et dans les résultats au format complet retournés par le API de sessions et résultats.

Administrateur Organisationnel

Un administrateur organisationnel (admin de l'organisation) est un utilisateur disposant de privilèges administratifs pour toute son entreprise dans Axe Account. Les admins d'organisation peuvent voir tous les projets de leur entreprise et gérer les membres et les paramètres des projets, quel que soit leur statut de membre d'un projet donné. Le statut d'admin d'organisation prévaut sur les rôles au niveau du projet. Les admins d'organisation doivent avoir une licence active Axe Developer Hub ou Axe DevTools for Mobile pour créer de nouveaux projets ou envoyer des résultats aux projets dont ils sont membres dans Axe Developer Hub mais peuvent gérer les projets existants sans licence.

État de la Page

Le état de la page fait référence à l'état du modèle d'objet de document (DOM) d'une page web à un moment précis. Voir différents états de page est utile pour les sites web complexes avec des écrans de connexion ou une interface utilisateur dynamique, comme les applications à page unique (SPAs). Exemples d'état DOM incluent :

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

Lorsque vous utilisez Watcher, le package rescanne les pages web chaque fois qu'il détecte des modifications du DOM et enregistre un nouvel état de page à chaque fois.

Exécution de pipeline

Un exécution de pipeline est une analyse déclenchée par un pipeline CI/CD, plutôt qu'une exécution locale depuis la machine d'un développeur. Le Developer Hub signale séparément les exécutions de pipeline afin qu'il sache toujours quelle analyse d'une branche est autoritaire. Une exécution de pipeline configurée sur la branche par défaut du projet est requise pour que les comparaisons inter-branche aient une référence ; sans cela, chaque problème est signalé comme nouveau. Voir Informations sur le pipeline et Axe Watcher dans les environnements d'intégration continue (CI).

Projet

Un projet dans Axe Developer Hub contient des résultats d'accessibilité, des informations sur les exécutions de tests et des données Git (branches et commits). Vous créez et nommez un nouveau projet dans Developer Hub, ce qui génère un ID de projet à utiliser avec vos tests pour identifier le projet et associer les données de résultats au projet. Une fois qu'un projet a intégré sa première session réussie, sa structure de données et, pour les projets Git, son dépôt, sont fixés par son verrouillage du projet.

Administrateur du projet

Un administrateur du projet est un membre de projet avec des permissions élevées. Les admins de projet peuvent faire tout ce qu'un membre de projet peut faire, plus gérer les paramètres du projet, ajouter ou supprimer des membres, et changer les rôles des membres. Lors de l'utilisation d'Axe Watcher, la clé API d'un admin de projet est nécessaire pour exécuter des tests dans un pipeline.

ID de Projet

Un ID de Projet est généré automatiquement lorsque vous ajoutez un nouveau projet, afin d'associer vos données de résultats à ce projet. Un ID de projet et une clé API sont nécessaires pour envoyer les résultats d'accessibilité à Developer Hub. Associez un ID de projet à une suite de tests/dépôt : cela est imposé par le verrouillage du projet, qui fixe la structure de données et le dépôt d'un projet après sa première session réussie.

Verrouillage du projet

Une fois qu'un projet a intégré sa première session réussie, il se verrouillages sur la structure de données de cette session et, pour les projets Git, sur le dépôt de cette session. Un projet verrouillé rejette toute exécution ultérieure avec une structure de données ou un dépôt différent lors de l'ingestion ; les résultats ne sont pas enregistrés. Les paramètres du projet affichent la structure de données et le dépôt verrouillés en lecture seule. Voir Exécution rejetée : la structure de données ou le dépôt ne correspond pas au projet.

Membre du Projet

Un membre du projet est un utilisateur qui a été ajouté à un projet Axe Developer Hub. Les membres de projet peuvent exécuter des tests et voir les résultats au sein du projet. Les membres doivent avoir une licence active pour accéder au projet.

Analyse

Une analyse est les résultats d'accessibilité que Developer Hub reçoit du test de votre produit, et ce que couvre une analyse diffère selon le type de projet.

Pour les projets web, une analyse est l'ensemble complet des résultats produits par votre suite de tests lors d'une exécution, quel que soit le nombre de pages visitées, envoyé au Developer Hub via Axe Watcher, l'Axe DevTools pour Web CLI ou les API Web, qui téléversent via le CLI. Chaque page vérifiée peut produire un ou plusieurs états de la page, un pour chaque état DOM distinct détecté, comme une application monopage changeant d'état sans recharger la page ; l'analyse est la collection complète des états de page de cette exécution.

Pour les projets mobiles, une analyse est le résultat du test d'un seul écran d'application avec l'Axe DevTools Mobile Analyzer. Tester plusieurs écrans lors d'une même séance produit plusieurs analyses, qui sont regroupées sous une même session.

SHA

Lorsque vous créez un commit avec Git, un ID est créé pour identifier de manière unique le commit. Cet ID unique est appelé un SHA (nommé d'après les algorithmes de hachage sécurisés, un groupe de fonctions de hachage cryptographiques).

Tag

Un tag groupe des règles appartenant à une directive d'accessibilité spécifique, comme WCAG. Pour plus d'information sur les règles et les tags auxquels ces règles appartiennent, voir Descriptions des Règles axe-core

WCAG

WCAG, ou Directives pour l'Accessibilité du Contenu Web, sont un ensemble de directives développées par le World Wide Web Consortium (W3C) pour aider à rendre le contenu web plus accessible aux personnes handicapées. Ces directives fournissent un cadre pour créer des sites web et des contenus numériques accessibles qui peuvent être utilisés par des personnes ayant un large éventail de handicaps.

Les trois niveaux de conformité du WCAG sont définis par un ensemble de critères de réussite décrivant des éléments spécifiques de contenu web qui doivent être respectés pour atteindre ce niveau de conformité. Le niveau de conformité A est le niveau minimal, tandis que le niveau de conformité AAA est le plus strict. Le niveau de conformité AA exige la conformité aux critères de réussite des niveaux A et AA. La conformité à tous les 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ée en 2008 et a fourni des directives plus complètes pour rendre le contenu web accessible à des personnes ayant une plus large gamme de handicaps.

WCAG 2.1 a été publiée en 2018. Elle s'appuie sur les versions précédentes et inclut de nouveaux critères de réussite pour traiter les problèmes d'accessibilité qui ont émergé depuis la sortie de WCAG 2.0. WCAG 2.1 fournit également plus de directives sur l'accessibilité mobile, l'accessibilité basse vision et les handicaps cognitifs et d'apprentissage.

WCAG 2.2, la version la plus récente de ces directives, a été publiée en 2023 et propose neuf nouveaux critères de réussite par rapport à WCAG 2.1. Elle offre des directives améliorées pour répondre aux besoins des utilisateurs ayant des handicaps cognitifs ou d'apprentissage, des utilisateurs avec une basse vision, et des utilisateurs ayant des handicaps sur des appareils mobiles. Elle est compatible avec WCAG 2.1.

Comparaison au sein de la branche

Une comparaison au sein de la branche compare l'analyse d'un commit avec l'analyse du commit précédent qui a des résultats sur la même branche. Elle apparaît dans la vue Commits et montre ce qu'un commit spécifique a introduit ou corrigé.