Glossaire
Cette page décrit la terminologie clé utilisée dans l'interface utilisateur d'axe Auditor que les utilisateurs du système doivent comprendre. Elle inclut des définitions et des explications des termes, abréviations et acronymes qui pourraient vous être inconnus.
Tableau de conformité d'accessibilité du tableau de bord : Le tableau de conformité indique le score global de conformité à l'accessibilité sur l'ensemble des pages et/ou composants définis dans le cadre du cas de test. Les pourcentages sont calculés en fonction du nombre total de points de contrôle passés ou échoués dans le cadre défini. Le point de contrôle sera compté comme échoué s'il échoue au moins une fois sur l'une des pages ou composants du cadre défini.
Technologie d'assistance : Les exécutions de tests permettent de spécifier les logiciels et appareils utilisés par les personnes handicapées pour interagir avec les logiciels et sites web. Certains tests nécessiteront l'utilisation d'un lecteur d'écran, tel que NVDA ou JAWS sur PC, ou VoiceOver sur Mac. Pour plus d'informations, lisez https://en.wikipedia.org/wiki/Assistive_technology
Attest : Faisant partie de la suite de produits de conformité à l'accessibilité d'entreprise de Deque, axe DevTools est le moteur de règles d'accessibilité haut de gamme qui exécute des tests automatisés complets à l'intérieur d'axe Auditor. En tant que produit autonome, c'est une bibliothèque JavaScript légère, rapide et portable qui fonctionne sur votre serveur de développement local dans le même navigateur que vos tests fonctionnels ou unitaires, s'intégrant parfaitement au cadre de test ou au navigateur de votre choix. Dans tout cycle de développement agile mature, les développeurs et testeurs sont habilités à détecter les problèmes d'accessibilité tôt et à les résoudre rapidement en utilisant les références intégrées et les modèles de solutions tirés de l'aide contextuelle approfondie qui exploite la base de connaissances en accessibilité de Deque University.
Point de contrôle : Une méthode éprouvée de test des exigences d'accessibilité créée par l'équipe d'experts en accessibilité de Deque qui accroît la cohérence et la précision des résultats de test. Basés sur les critères de réussite WCAG, ils offrent une catégorisation et une interprétation plus explicites de ces lignes directrices, où les échecs sont généralement séparés par type de contenu. Les Points de contrôle Deque aident les évaluateurs à 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 applicable de la liste maîtresse des 66 Points de contrôle Deque (et leurs exigences) qui font partie intégrante de la méthode Deque pour l'égalité numérique.
Statut de réalisation : Les trois états de réalisation liés aux exécutions de tests dans axe Auditor sont "non commencé" (cas de test assigné à l'utilisateur, mais pas encore commencé), "en cours" (soit les tests automatisés ou manuels ont été commencés, mais tous les points de contrôle n'ont pas encore été affectés d'un résultat pour toutes les pages constituant l'exécution de test), et "complet" (signifiant que tous les points de contrôle pour toutes les pages ont été marqués avec un résultat de réalisation soit Passé, Échoué ou N/A pour les tests automatisés et manuels).
Données de conformité et impact : Un groupe de 6 champs d'information liés qui vous donne un aperçu rapide du type d'information de conformité et de l'impact sur l'accessibilité associés à cette règle. Une liste des normes applicables à la règle, qui peut inclure les niveaux A et AA de la W3C WCAG 2.0, ainsi que les directives de la section 508 des États-Unis et/ou les meilleures pratiques de la méthode Deque. La personnalisation des règles et des contrôles automatisés associés permet de tester les normes spécifiques à l'organisation. Les classifications de gravité (Bloquant, Critique, Grave, Modéré ou Mineur) font référence aux niveaux de violation de conformité (échec de la règle) qui décrivent la gravité de l'impact des problèmes sur l'accessibilité d'un site ou d'une page.
Composant : Un composant représente des sections globales et réutilisables du site web. L'utilisateur peut également définir des composants pour faire partie ou section d'une page particulière. Axe Auditor s'attend à ce que des sélecteurs appropriés soient définis pour identifier les composants d'une page.
Tableau de bord : Le tableau de bord d'une exécution de test complétée se compose de trois graphiques indiquant le niveau de conformité à l'accessibilité, l'impact des problèmes sur les personnes avec différents handicaps et les principaux problèmes avec le nombre de fois où ils se sont répétés. Toutes ces données de graphiques sont basées sur la méthodologie Deque-Way utilisée dans axe Auditor pour tester selon une norme donnée. Par exemple, selon Deque-Way, nous évaluons 66 points de contrôle pour chaque page ou composant si la norme sélectionnée est le niveau A & AA de la WCAG 2.0.
Type de ressource numérique
: Ce champ est utilisé pour définir le type de ressource ou de propriété testée. L'avantage est que seuls les points de contrôle pertinents pour la ressource sélectionnée (les méthodologies de test, de remédiation et de meilleures pratiques) s'afficheront pour le test manuel. Les points de contrôle non applicables seront cachés, il n'y aura donc que les points de contrôle pertinents à examiner. Les options à choisir sont :
- Web de bureau
- Web mobile
- Mobile natif Android
- Mobile natif iOS
- Kiosque
- Documents MS Excel
- Documents MS PowerPoint
- Documents MS Word
- Logiciel de bureau Windows
Handicaps affectés : Un ou plusieurs des éléments suivants est affiché pour indiquer quels handicaps sont affectés lorsque la règle n'est pas respectée :
- Déficit d'attention
- Cognitif
- Daltonisme
- Surdité
- Dyslexie
- Malentendant
- Basse vision
- Crises d'épilepsie
- Utilisateurs de clavier voyants
- Parole
Environnement : Les exécutions de tests permettent de spécifier le type de serveur sur lequel se fait le test. Par exemple, un serveur de production serait utilisé pour un site en ligne.
Dossier : Un dossier est simplement un conteneur pour les cas de test utilisé pour les organiser. Il est utilisé pour grouper catégoriquement les cas de test connexes. Consultez votre responsable de l'assurance qualité avant de créer un nouveau cas de test pour déterminer le dossier le plus approprié avec lequel l'associer. Lorsqu'un nouveau cas de test est créé et qu'aucun dossier n'est sélectionné, il sera automatiquement créé dans le dossier Désorganisé par défaut. Les cas de test existants peuvent être déplacés dans différents dossiers à tout moment.
Impact : L'impact sur l'utilisateur est un indicateur utile pour prioriser les efforts de remédiation. Les niveaux par défaut sont associés à chaque Point de contrôle Deque selon ce que les experts en accessibilité de Deque ont déterminé comme étant généralement vrai pour un type particulier de problème d'accessibilité, mais les évaluateurs peuvent utiliser leur jugement pour les modifier. Les impacts Bloquant, Critique et Grave se produisent lorsque les utilisateurs rencontrent des obstacles significatifs ou sont bloqués par le contenu du site, ce qui les rend plus vulnérables aux actions en justice. Les problèmes mineurs et modérés ne sont pas aussi graves, mais doivent tout de même être traités pour que la page soit considérée comme entièrement conforme. Les tests de points de contrôle couvrent des lignes directrices d'accessibilité qui peuvent avoir les cinq niveaux suivants utilisés pour catégoriser l'impact des problèmes sur l'accessibilité dans l'application axe Auditor.
- Bloquant : Entraîne des obstacles catastrophiques pour les personnes en situation de handicap. Ces problèmes les empêcheront certainement d'accéder aux fonctionnalités ou au contenu fondamentaux, sans possibilité de contournement. Ce type de problème met votre organisation à haut risque. Priorisez la résolution immédiatement, et déployez comme hotfixes dès que possible. Devrait être extrêmement rare. Un exemple de problème bloquant est un SC 2.3.1 --- Trois flashs ou moins, qui peut provoquer des crises.
- Critique : Ce problème entraîne un blocage du contenu pour les individus handicapés. Tant qu'une solution n'est pas mise en place, le contenu sera complètement inaccessible, rendant votre organisation très vulnérable aux actions en justice. La remédiation doit être une priorité absolue.
- Grave : Ce problème cause d'importants obstacles pour les personnes en situation de handicap, et les empêchera partiellement d'accéder aux fonctionnalités ou au contenu fondamentaux. Les personnes utilisant des technologies d'assistance éprouveront une frustration significative en conséquence. Les problèmes relevant de cette catégorie sont des problèmes majeurs, et la remédiation devrait être une priorité. Devrait être très courant.
- Modéré : Ce problème cause quelques obstacles pour les individus handicapés mais ne les empêcherait pas d'accéder aux éléments ou contenus fondamentaux. Cela pourrait rendre votre organisation vulnérable aux actions en justice. Cette violation doit être résolue avant qu'une page puisse être considérée comme entièrement conforme.
- Mineur : Ceci est considéré comme un problème ayant moins d'impact pour les utilisateurs qu'un problème modéré. Pour qu'une page soit considérée entièrement conforme, ce problème doit être résolu mais peut être traité en dernier.
Problème : Dans le contexte d'axe Auditor, chaque problème se compose d'un résumé requis, d'un niveau d'impact, ainsi que d'une association avec un Point de contrôle Deque Way. Les informations supplémentaires pouvant être stockées dans un enregistrement de problème incluent un type de problème, un type de description, une description, des indicateurs de révision, du code source, des captures d'écran et une recommandation de remédiation. Chaque problème concerne une page de test particulière.
Type de problème : Fait référence au type d'échec ou de meilleure pratique. Les 5 types de problèmes suivants sont utilisés pour catégoriser les problèmes dans l'application axe Auditor :
- Accessibilité : Le problème impacte la capacité d'un utilisateur handicapé à accéder au contenu ou aux fonctionnalités du site. Échoue le test de point de contrôle.
- Meilleures Pratiques : Le problème affecte la capacité d'un utilisateur handicapé à accéder au contenu ou à la fonctionnalité du site, mais ne contrevient pas au test de point de contrôle.
- Agent Utilisateur : Le problème résulte de l'interaction de l'agent utilisateur avec la page, pas nécessairement du contenu de la page lui-même.
- Fonctionnalité : Le problème est dû à un problème de fonctionnalité de la page et doit être considéré comme un défaut fonctionnel.
- Utilisabilité : Le problème affecte la capacité de tous les utilisateurs à accéder au contenu ou à la fonctionnalité du site.
Méthode : La méthode d'un problème indique comment l'expert en la matière a trouvé un problème, soit par automatisation, soit manuellement. Nous utilisons les outils Deque pour les résultats des tests d'automatisation et la méthode Deque Way pour les résultats des tests manuels.
Autres Ressources Liées : Liens externes vers des pages sur des sites non-Deque reconnus comme sources réputées d'informations de qualité sur la règle spécifique.
Page : Une page dans axe Auditor fait référence à une « page sous test » ou une « page de test ». Sur un écran de création de cas de test, la boîte de dialogue Ajouter une page est utilisée pour ajouter les pages à tester. Une page représente la page individuelle, le composant, ou le contenu à l'intérieur d'un cas de test que vous souhaitez tester pour l'accessibilité. Bien que vous spécifiez une URL et un nom pour la page, la portée à tester peut être la page entière, ou une zone de la page (qui peut être un module, un écran, un widget, une section ou un élément).
Plateforme : Les systèmes d'exploitation et navigateurs sur lesquels le site doit être testé. Par exemple, « Windows et Firefox » ou « Android et Chrome ». Les tests automatisés seront effectués via un navigateur connecté sur une plateforme donnée.
Pages de Cours Associées de Deque University : Un lien vers le sujet est suivi par un lien entre parenthèses vers le cours dans lequel le sujet est contenu. Cela vous mène directement à la page de Deque University où un niveau de détail élevé est fourni sur la nature de la règle et pourquoi elle est importante.
Version : Les exécutions de test permettent de spécifier le numéro de version du produit testé. Par exemple, 1.0 serait le premier cycle de version du produit.
Pages de Cours Associées de Deque University : Un lien vers le sujet est suivi par un lien entre parenthèses vers le cours dans lequel le sujet est contenu. Cela vous mène directement à la page de Deque University où un niveau de détail élevé est fourni sur la nature de la règle et pourquoi elle est importante.
Technologies Pertinentes : Une ou plusieurs technologies pertinentes sont affichées pour démontrer les types de technologies dans lesquelles les règles peuvent être exécutées.
Recommandation de Correction : La recommandation de correction est la suggestion de nos experts Deque sur la façon de résoudre un problème particulier. Cela sera d'une grande aide pour les développeurs. Parfois, cela indique également comment ce problème affecte une personne ayant un handicap et le type de handicap qui souffre de cet échec.
Directives de la Section 508 : Des sous-sections spécifiques des directives de la Section 508 sont référencées lorsque cela est applicable.
Sélecteur : Un sélecteur est un moyen d'identifier un élément en utilisant certaines techniques (exemple : xpath, id, classe css) sur un DOM de page web qui aide à identifier un composant particulier.
Gravité : Bloquant, Critique, Grave, Modéré et Mineur sont les cinq catégories de gravité d'un problème (échec de règle), en lien avec les différentes directives et meilleures pratiques applicables.
Portée : La portée d'un cas de test est un ensemble d'URL de pages et de composants à évaluer pour la conformité à l'accessibilité par rapport à la norme définie. Chaque page ou composant est considéré comme une unité de test par l'application axe Auditor.
Code Source : Le code source est le code DOM rendu d'un élément cible d'un problème. Il aide les développeurs à identifier l'élément du problème très facilement.
Norme : Le champ Norme vous permet de sélectionner soit WCAG 2.0 Niveau A, WCAG 2.0 Niveau AA, WCAG 2.1 Niveau A, WCAG 2.1 Niveau AA, WCAG 2.0, Section 508 ou Air Carrier Access Act (ACAA) lors de la création ou de la modification d'un cas de test existant. Ce paramètre affine les règles automatisées et les tests de point de contrôle manuel qui doivent être testés uniquement par rapport à ceux qui sont applicables à la norme sélectionnée.
Statut : Les trois états du statut d'une exécution de test dans axe Auditor sont « non commencé » (cas de test attribué à l'utilisateur, mais pas encore commencé), « en cours » (tests automatisés ou manuels ont commencé, mais tous les points de contrôle n'ont pas encore été assignés à un résultat pour toutes les pages qui composent l'exécution de test), et « terminé » (ce qui signifie que tous les points de contrôle pour toutes les pages ont été marqués avec un résultat de complétion soit Passé, Échoué, ou N/A dans le test manuel).
Cas de Test : Les cas de test représentent le scénario de test, les étapes et les informations sur le produit requises pour une évaluation spécifique. Ils sont constitués d'au moins une page ou d'un composant à tester, et sont nommés. Les informations supplémentaires incluent une description du cas de test, la norme applicable, et les informations sur le produit. Les pages à tester contenues dans un cas de test incluent chacune un nom de page, une URL et une portée --- qui peut être soit la page entière ou une zone spécifique de la page (module, écran, widget, section ou élément) --- des éléments cibles (formulaires, vidéo, audio, CAPTCHA, contenu clignotant), et des instructions connexes telles que celles à utiliser pour naviguer vers la page.
Fiabilité du Test : Un test par rapport à une règle inclut plusieurs vérifications qui, après exécution, produisent un résultat collectif. La fiabilité du test dépend des résultats qui peuvent être identifiés de manière définitive par des moyens automatisés. Trois catégories de vérifications incluent « aucune ne doit passer », « une doit passer », et « toutes doivent passer » pour chaque test. Les tests automatisés sont soit considérés comme Fiables, Moyennement fiables, ou Non fiables --- auquel cas une évaluation manuelle est requise.
Exécution de Test : Une exécution de test est une instance d'un cas de test qui a été attribuée à un utilisateur pour effectuer une évaluation par rapport à une combinaison spécifique de plateforme OS, version de navigateur et technologie d'assistance. Nous créons un nombre d'exécutions de test si nous devons évaluer le cas de test donné par rapport à plusieurs combinaisons de OS, Navigateur et AT. Chaque exécution de test peut être attribuée à un utilisateur différent.
Unité de Test : Une unité de test peut être une page ou un composant d'un cas de test. Le nombre d'unités de test d'un cas de test est équivalent à la somme du nombre de pages et de composants d'un cas de test.
Méthodologie de Test : La Méthodologie Deque Way est notre approche définie par l'équipe d'experts en accessibilité de Deque pour comprendre et interpréter les WCAG de manière précise et plus facile. Cela rendra les équipes d'accessibilité des clients plus efficaces si elles l'adoptent.
Tableau des Principaux Problèmes du Tableau de Bord : Le tableau des principaux problèmes indique les principaux points de contrôle qui ont échoué à plusieurs reprises sur la portée des pages et/ou des composants définis. La liste est présentée dans un ordre décroissant afin que l'utilisateur voie d'abord le point de contrôle principal avec le plus grand nombre d'échecs. Ce tableau affiche un maximum de 10 points de contrôle principaux avec le plus grand nombre de problèmes.
Sujets : Trop nombreux pour être listés ici, tous les Noms des Sujets : Sous-sujets applicables sont affichés pour représenter la catégorie générale à laquelle la règle appartient. Ces associations servent à regrouper ensemble les types de règles/problèmes similaires.
Tableau de l'Impact Utilisateur du Tableau de Bord : Le tableau de l'impact utilisateur indique comment ces problèmes d'accessibilité identifiés affecteront les personnes avec différents handicaps. Vous pouvez trouver les définitions de la gravité en cliquant sur l'icône d'information sous le tableau. Consultez la section "impact" de ce glossaire pour comprendre comment les différents problèmes avec différents niveaux d'impact affecteraient la capacité d'une personne handicapée à utiliser la fonctionnalité de la page.
Critères de Réussite des WCAG : Les Critères de Réussite (CR) sont rédigés sous forme d'énoncés testables qui ne sont pas spécifiques à une technologie. Les sous-sections des directives WCAG concernées sont listées. Les catégories de problèmes de point de contrôle de la méthode Deque sont basées sur ces regroupements de directives d'accessibilité connexes.
