Principes de base des tests manuels
Les tests d'accessibilité manuels utilisent des tests, des outils et des techniques au clavier, visuels et cognitifs pour détecter les problèmes que les outils automatisés ne peuvent pas détecter. Étant donné que les outils automatisés ne couvrent pas tous les critères de réussite identifiés dans les WCAG, il est essentiel de ne pas exécuter de tests d'accessibilité automatisés, puis d'arrêter les tests.
À mesure que la technologie progresse, davantage de tests pourraient être couverts uniquement par les outils automatisés, mais aujourd'hui, des vérifications manuelles et des technologies d'assistance doivent être ajoutées à vos protocoles de test pour couvrir tous les points de contrôle WCAG applicables.
Avantages des tests d'accessibilité manuels:
- Plutôt simple et rapide à exécuter
- Détecter un pourcentage de problèmes plus élevé que les tests automatisés seuls
- Peu d'outils et d'expertise sont nécessaires pour réussir
Inconvénients des tests d'accessibilité manuels:
- Plus complexe et long que les tests automatisés
- Peut être difficile à répéter à grande échelle
- Nécessite davantage d'expertise en accessibilité pour exécuter des tests et interpréter les résultats
Comparons les éléments et les détails d'accessibilité actuellement détectés par un outil automatisé avec ceux qui ne le seront pas.
Types de tests manuels
Il existe de nombreux outils et techniques manuels à prendre en compte lorsque vous examinez votre page Web ou votre application pour déterminer l'accessibilité numérique. Les trois principaux domaines d'action des tests manuels sont la fonctionnalité du clavier, les avis visuels et les vérifications générales du contenu.
Nous aborderons chacun de ces sujets dans les grandes lignes dans ce module, mais les tests suivants ne visent pas à dresser une liste exhaustive de tous les tests manuels que vous pouvez ou devriez exécuter. Nous vous encourageons à commencer par une checklist d'accessibilité manuelle provenant d'une source fiable, puis à développer votre propre checklist de test manuel spécifique pour votre produit numérique et les besoins de votre équipe.
Vérifications au clavier
On estime qu'environ 25% de tous les problèmes d'accessibilité numériques sont liés à une mauvaise compatibilité du clavier. Comme nous l'avons vu dans le module Ciblage du clavier, cela concerne tous les types d'utilisateurs, y compris les personnes voyantes uniquement au clavier, les personnes malvoyantes ou aveugles, et les personnes qui utilisent un logiciel de reconnaissance vocale basé sur une technologie reposant également sur le contenu accessible au clavier.
Les tests du clavier permettent de répondre à des questions telles que:
- La page Web ou la fonctionnalité nécessite-t-elle une souris pour fonctionner ?
- L'ordre de tabulation est-il logique et intuitif ?
- L'indicateur de mise au point au clavier est-il toujours visible ?
- Vous arrive-t-il de rester coincé dans un élément qui ne devrait pas piéger l'attention ?
- Pouvez-vous naviguer derrière ou autour d'un élément qui devrait piéger l'attention ?
- Lors de la fermeture d'un élément sélectionné, l'indicateur de focus est-il revenu à un emplacement logique ?
Bien que l'impact de la fonctionnalité du clavier soit énorme, la procédure de test est assez simple. Il vous suffit de mettre de côté votre souris ou d'installer un petit package JavaScript et de tester votre site Web en utilisant uniquement votre clavier. Les commandes suivantes sont essentielles pour les tests avec le clavier.
Contrôles visuels
Les contrôles visuels se concentrent sur les éléments visuels de la page et utilisent des outils tels que la loupe ou le zoom dans le navigateur pour examiner l'accessibilité du site Web ou de l'application.
Grâce aux vérifications visuelles, vous pouvez:
- Existe-t-il des problèmes de contraste des couleurs qu'un outil automatisé n'a pas pu détecter, comme du texte au-dessus d'un dégradé ou d'une image ?
- Existe-t-il des éléments qui ressemblent à des en-têtes, des listes et d'autres éléments structuraux, mais qui ne sont pas codés en tant que tels ?
- Les liens de navigation et les entrées de formulaire sont-ils cohérents sur l'ensemble du site Web ou de l'application ?
- Y a-t-il des flashs, des effets stroboscopiques ou des animations qui dépassent les recommandations ?
- L'espacement est-il correct dans le contenu ? Pour les lettres, les mots, les lignes et les paragraphes ?
- Pouvez-vous voir tout le contenu à l'aide d'une loupe ou d'un zoom dans le navigateur ?
Vérifications de contenu
Contrairement aux tests visuels qui se concentrent sur la mise en page, le mouvement et les couleurs, les vérifications de contenu se concentrent sur les mots de la page. Vous devez non seulement examiner le contenu publicitaire en lui-même, mais également examiner le contexte afin de vous assurer qu'il a du sens pour les autres utilisateurs.
Les vérifications du contenu permettent de répondre à ce type de questions:
- Les titres de page, les en-têtes et les libellés des formulaires sont-ils clairs et descriptifs ?
- Les alternatives aux images sont-elles concises, précises et utiles ?
- La couleur seule est-elle utilisée comme le seul moyen de transmettre un sens ou des informations ?
- Les liens sont-ils descriptifs ou utilisez-vous un texte générique tel que "en savoir plus" ou "cliquez ici" ?
- La langue d'une page a-t-elle changé ?
- Le langage simple est-il utilisé et tous les acronymes sont-ils écrits lorsqu'ils y sont référencés pour la première fois ?
Certaines vérifications de contenu peuvent être partiellement automatisées. Par exemple, vous pouvez écrire un outil lint JavaScript qui recherche "Cliquez ici" et vous suggère d'apporter une modification. Cependant, ces solutions personnalisées ont souvent besoin d'un humain pour remplacer le texte par un élément de contexte.
Démonstration: test manuel
Jusqu'à présent, nous avons exécuté des tests automatisés sur notre page Web de démonstration, et identifié et résolu huit types de problèmes différents. Nous sommes maintenant prêts à effectuer des vérifications manuelles pour voir si d'autres problèmes d'accessibilité peuvent être détectés.
Étape 1
Toutes les mises à jour d'accessibilité automatisées sont appliquées à notre nouvelle démonstration CodePen.
Affichez-le en mode débogage pour passer aux tests suivants. Ce point est important, car il supprime la <iframe> qui entoure la page Web de démonstration, ce qui peut interférer avec certains outils de test. Apprenez-en plus sur le mode débogage de CodePen.
Étape 2
Lancez le processus de test manuel en positionnant votre souris ou votre pavé tactile de côté, et naviguez de haut en bas dans le DOM en utilisant uniquement votre clavier.
Problème 1: indicateur de mise au point visible
Le premier problème lié au clavier devrait s'afficher immédiatement (ou plutôt vous ne devriez pas le voir), car l'indicateur de mise au point visible a été supprimé. Lorsque vous scannez le CSS dans la version de démonstration, vous devriez voir l'erreur "outline: none" dans le codebase.
:focus {
outline: none;
}
Nous allons résoudre ce problème.
Comme vous l'avez appris dans le module de sélection du clavier, vous devez supprimer cette ligne de code pour permettre aux navigateurs Web d'ajouter un curseur visible aux utilisateurs. Vous pouvez aller plus loin et créer un indicateur de mise au point stylisé selon l'esthétique de votre produit numérique.
:focus {
outline: 3px dotted #008576;
}
Problème 2: sélectionner l'ordre
Une fois que vous avez modifié l'indicateur de focus et qu'il est visible, veillez à parcourir la page à l'aide de la touche de tabulation. Vous devriez remarquer que le champ de saisie du formulaire utilisé pour s'abonner à la newsletter n'est pas sélectionné. Il a été supprimé de l'ordre de mise au point naturel par un index de tabulation négatif.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
Comme nous souhaitons que les utilisateurs puissent utiliser ce champ pour s'inscrire à notre newsletter, il nous suffit de supprimer l'index de tabulation négatif ou de le définir sur zéro pour que la saisie soit à nouveau sélectionnable au clavier.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>
Étape 3
Une fois la sélection au clavier effectuée, nous passons aux vérifications visuelles et du contenu.
Problème 3: contraste des couleurs des liens
En parcourant les tests du clavier, en parcourant la page de démonstration par la touche de tabulation, vous avez probablement remarqué que le clavier se concentrait sur trois liens visuellement masqués dans les paragraphes traitant des différentes pathologies.
Pour que notre page soit accessible, les liens doivent se démarquer du texte environnant et inclure un changement de style non coloré lors du passage de la souris et de la sélection au clavier.
Nous allons corriger ce problème.
Une solution rapide consiste à souligner les liens à l'intérieur des paragraphes pour les faire ressortir. Cela résoudra le problème d'accessibilité, mais cela pourrait ne pas convenir à l'esthétique de conception globale que vous espérez obtenir.
Si vous choisissez de ne pas ajouter de soulignement, vous devrez modifier les couleurs de manière à respecter les exigences à la fois pour l'arrière-plan et le texte.
Si vous étudiez la démo à l'aide de l'outil de vérification du contraste des liens, vous constaterez que la couleur des liens respecte les exigences de contraste des couleurs de 4,5:1 entre le texte de taille standard et l'arrière-plan. Cependant, les liens non soulignés doivent également respecter une exigence de contraste des couleurs de 3:1 par rapport au texte environnant.
Une option consiste à modifier la couleur du lien pour qu’elle corresponde aux autres éléments de la page. Mais si vous changez la couleur du lien en vert, le corps du texte doit également être modifié pour répondre aux exigences générales de contraste des couleurs entre les trois éléments: les liens, l'arrière-plan et le texte environnant.
Problème 4: contraste des couleurs des icônes
Un autre problème de contraste des couleurs manqué est les icônes de réseaux sociaux. Dans le module Couleur et contraste, vous avez appris que les icônes essentielles doivent respecter un contraste de couleur 3:1 par rapport à l'arrière-plan. Toutefois, dans la démo, les icônes des réseaux sociaux ont un rapport de contraste de 1,3:1.
Nous allons corriger ce problème.
Pour répondre aux exigences de contraste des couleurs 3:1, les icônes des réseaux sociaux sont modifiées en gris plus foncé.
Problème 5: présentation du contenu
Si vous examinez la mise en page du contenu du paragraphe, vous constaterez que le texte est entièrement justifié. Comme vous l'avez appris dans le module Typographie, cela crée des "rivières d'espace", ce qui peut rendre le texte difficile à lire pour certains utilisateurs.
p.bullet {
text-align: justify;
}
Pour réinitialiser l'alignement du texte dans la démonstration, vous pouvez remplacer le code par text-align: left; ou supprimer entièrement cette ligne du CSS, car à gauche est l'alignement par défaut pour les navigateurs. Veillez à tester le code au cas où d'autres styles hérités supprimeraient l'alignement du texte par défaut.
p.bullet {
text-align: left;
}
Étape 4
Une fois que vous avez identifié et corrigé tous les problèmes d'accessibilité manuels décrits dans les étapes précédentes, votre page devrait ressembler à notre capture d'écran.
Il est possible que vous rencontriez plus de problèmes d'accessibilité dans vos vérifications manuelles que dans ce module. Nous découvrirons bon nombre de ces problèmes dans le module suivant.
Étape suivante
Bravo ! Vous avez terminé les modules de test automatisé et manuel. Vous pouvez consulter notre nouveau CodePen, qui intègre tous les correctifs d'accessibilité automatisés et manuels.
Passez maintenant au dernier module de test axé sur les tests des technologies d'assistance.
Testez vos connaissances
Tester vos connaissances sur les tests d'accessibilité manuels
Quels éléments doivent respecter les normes WCAG concernant le contraste des couleurs ?