Glossaire

a11y

Abréviation d'accessibilité : interprétée comme la lettre a suivie de 11 caractères puis de la lettre y.

Agora

Agora est le référentiel d'artefacts interne de Deque. Il est basé sur une instance 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 bien plus encore.

ARIA

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

Technologie d'assistance

Certaines personnes handicapées peuvent ne pas être en mesure d’interagir seules avec les logiciels et les 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 le lecteur d’écran. Ces appareils 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.

Point de contrôle

Une méthode éprouvée pour tester les exigences d'accessibilité créée par l'équipe d'experts a11y de Deque qui augmente la cohérence et la précision des résultats des tests. Sur la base des critères de réussite WCAG, il fournit une catégorisation et une interprétation plus explicites de ces directives, dans lesquelles les échecs sont généralement séparés par type de contenu. Les points de contrôle Deque aident les examinateurs à produire des résultats de test cohérents et précis lors des évaluations d’accessibilité. Un point de contrôle fait référence à la section la plus pertinente et la plus applicable de la liste principale des points de contrôle Deque (et de leurs exigences) qui constituent une partie importante de la voie Deque vers l'égalité numérique.

Ensemble de règles personnalisé

Un ensemble de règles personnalisé est créé à partir d'un fichier JSON contenant des données des règles (règles et contrôles) transmises aux composants axe DevTools pour ajouter de nouvelles règles, modifier la gravité/l'impact d'une règle ou supprimer une règle des tests.

Événement

Pour suivre l'utilisation de l'API ou de la CLI, la bibliothèque de métriques crée des événements et les envoie au service d'utilisation. Les événements contiennent des informations sur l'utilisation, telles que le nombre de règles d'accessibilité violées lors d'une analyse de page Web et la date et l'heure auxquelles une analyse d'accessibilité a été effectuée.

Jeton d'identité

Un jeton d'identité est un jeton de sécurité émis par JFrog qui vous permet d'accéder au référentiel d'artefacts Agora de Deque. Les jetons d'identité doivent être copiés au moment de la création car c'est la seule possibilité d'y accéder. Ils expirent après un intervalle de temps déterminé, généralement un an.

Impact

À chaque violation d’accessibilité est attribué un niveau d’impact. L’impact est une mesure utile pour prioriser les efforts de remédiation. Par défaut, chaque type de violation se voit attribuer un niveau d'impact par les experts en accessibilité de Deque. Ces valeurs sont généralisées à la plupart des situations, les utilisateurs peuvent donc utiliser leur jugement pour les modifier dans le cadre de la personnalisation de leur ensemble de règles. Les niveaux d’impact graves ou critiques correspondent aux utilisateurs handicapés rencontrant des obstacles d’utilisation importants ou insurmontables. Ceux-ci comportent le plus haut degré de responsabilité juridique. Les problèmes mineurs et modérés ne sont pas aussi graves, mais représentent toujours des problèmes importants pour les utilisateurs handicapés et nécessitent d'être résolus pour que la page soit entièrement 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 ne pourront pas accéder ou interagir avec une fonctionnalité de la page Web. Tant qu’une solution ne sera pas mise en œuvre, le contenu sera totalement inaccessible. Cela rend votre organisation très vulnérable aux poursuites judiciaires. La résolution des problèmes critiques devrait être une priorité absolue.

• Grave : ce niveau d'impact signifie que les utilisateurs handicapés seront confrontés à de sérieux obstacles lors de leurs interactions avec le site. Ces utilisateurs ressentiront une frustration importante lorsqu’ils tenteront d’accéder au contenu associé. Tant qu’une solution n’est pas mise en œuvre, certains contenus seront difficiles ou impossibles à accéder, rendant votre organisation vulnérable aux poursuites judiciaires. La remédiation devrait être une priorité absolue.

• Modéré : Ce niveau d’impact signifie que certains obstacles existent pour les utilisateurs handicapés, mais ils ne les empêcheraient pas d’accéder aux flux ou au contenu de base. Les problèmes ayant un impact à ce niveau peuvent rendre votre organisation vulnérable à des poursuites judiciaires. Ils nécessitent une résolution avant qu'une page soit entièrement conforme et doivent être remédié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é inférieure aux problèmes modérés, graves et critiques, mais nécessite néanmoins une résolution pour qu'une page soit entièrement conforme.

Intelligent Guided Testing (IGT)

Intelligent Guided Testing (IGT) est un composant de test d'accessibilité interactif des extensions de navigateur axe DevTools Web conçu pour trouver les erreurs d'accessibilité qui ne peuvent pas être détectées dans les tests automatisés. IGT pose à l'utilisateur des questions simples sur la page Web testée et utilise ces commentaires pour localiser davantage d'erreurs d'accessibilité qu'il ne serait possible avec des tests automatisés. Pour en savoir plus sur les tests guidés intelligents, consultez la documentation des tests guidés intelligents.

Problème

Une infraction aux directives d'accessibilité (telles que définies par des normes telles que 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 détecter des problèmes d'accessibilité à l'aide des API ou de la CLI de axe DevTools, vos résultats sont enregistrés sous forme de fichier JSON qui est référencé dans la documentation comme un fichier de résultats d'accessibilité JSON . Vous pouvez téléverser ce fichier sur axe Reports (qui vous permet de surveiller l'accessibilité de votre site Web au fil du temps via le site Web axe Reports). Vous pouvez également filtrer et convertir le fichier de résultats d'accessibilité JSON localement au format .csv, .xml ou .html à l'aide de la CLI. Consultez Création de rapports avec la CLI pour plus d'informations. En outre, les API vous permettent également de convertir des fichiers de résultats d'accessibilité JSON en rapports lors d'une exécution de test (voir Reporting ci-dessous pour plus d'informations).

Bibliothèque de métriques

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

Besoin d'examen

Un problème nécessite un examen par un humain pour déterminer si le problème constitue une violation réelle des normes d’accessibilité.

Rapportage

La création de rapports fait référence au téléchargement d'un fichier résultats d'accessibilité JSON vers axe Reports ou à sa conversion locale en un rapport (un fichier .csv, .xml ou .html) à utiliser dans une autre application.

Règle

Une règle correspond à un critère de réussite d'une ligne directrice d'accessibilité. Ils sont définis par des fichiers objets JSON et contiennent un identifiant, une description et des métadonnées d'aide ainsi qu'une ou plusieurs vérifications et paramètres facultatifs.

Section 508

Un amendement à la loi américaine sur la réadaptation de 1973 qui oblige les agences fédérales à rendre leurs technologies électroniques et informatiques accessibles aux personnes handicapées. Il comprend seize dispositions basées sur les directives d'accès élaborées par le WCAG (Web Content Accessibility Guidelines) du World Wide Web Consortium (W3C), mais qui ne sont identiques ni aux normes WCAG 1.0 ni aux normes WCAG 2.0.

Service d'utilisation

Un service Web RESTful qui enregistre les métriques d'utilisation d'axe DevTools for Web (API et Interface de Ligne de Commande). Il s'agit soit du service public fourni par Deque, soit de votre propre service. Pour plus d'informations, consultez The axe DevTools for Web Usage Service.

Violation

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

WCAG

Les WCAG, ou Directives pour l'accessibilité des contenus Web, 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 largement aux technologies plus avancées et est plus précisément testable avec des tests automatisés et une évaluation humaine. Les WCAG 2.1 ont été publiées en juin 2018. Ces Directives contiennent des critères de réussite qui définissent des critères testables pour des éléments spécifiques. WCAG 2.2, la version la plus récente des Directives, a été publiée en 2023 et propose neuf nouveaux critères de réussite par rapport aux WCAG 2.1.