Tests manuels d'accessibilité

Principes de base des tests manuels

Les tests d'accessibilité manuels utilisent le clavier, des tests visuels, cognitifs, des outils, et des techniques pour identifier les problèmes que les outils automatisés ne peuvent pas détecter. Comme automatisé 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 avant d'arrêter les tests.

À mesure que la technologie progresse, un plus grand nombre de tests pourraient être couverts uniquement par des outils automatisés, mais aujourd'hui, des vérifications manuelles et des technologies d'assistance doivent être ajoutées à vos protocoles de test afin de couvrir tous les points de contrôle des WCAG applicables.

Avantages des tests d'accessibilité manuels:

  • Plutôt simple et rapide à exécuter
  • Détectez un pourcentage de problèmes plus élevé que les tests automatisés seuls
  • Peu d'outils et d'expertise nécessaires pour réussir

Inconvénients des tests d'accessibilité manuels:

  • Plus complexes et chronophages que les tests automatisés
  • Peut être difficile à répéter à grande échelle
  • Nécessitent une plus grande expertise en matière d'accessibilité pour exécuter des tests et interpréter les résultats

Comparons quels éléments et détails d'accessibilité peuvent actuellement être détectés par un outil automatisé par rapport à celles qui ne seront pas détectées.

Automatisation possible Automatisation impossible
Contraste des couleurs du texte sur les fonds unis Contraste des couleurs du texte sur les dégradés/images
Il existe un texte alternatif pour l'image Le texte alternatif des images est exact et correctement attribué
Des en-têtes, des listes et des points de repère existent Les titres, les listes et les points de repère sont correctement balisés et tous les éléments sont pris en compte.
ARIA est présent Les valeurs ARIA sont utilisées de manière appropriée et appliquées aux bons éléments.
Identifier les éléments sélectionnables au clavier Les éléments pour lesquels la sélection au clavier est manquante, l'ordre de sélection est logique et l'indicateur de sélection est visible.
Détection de titres iFrame iFrame, l'ordre de mise au point est logique et l'indicateur de mise au point est visible.
L'élément vidéo est présent L'élément vidéo dispose d'autres supports appropriés (par exemple, des sous-titres et des transcriptions).


Types de tests manuels

Il existe de nombreux outils et techniques manuels à prendre en compte lorsque vous examinez votre une page Web ou une application pour l'accessibilité numérique. Les trois principaux domaines d'action les tests manuels sont la fonctionnalité du clavier, les avis axés visuellement 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 constituent pas une liste exhaustive de tous les tests manuels. que vous pouvez ou devriez exécuter. Nous vous conseillons de commencer checklist d'accessibilité manuelle auprès d'une source fiable et élaborer votre propre liste de contrôle ciblée pour les tests manuels aux besoins spécifiques de votre équipe et de votre produit numérique.

Vérifications au clavier

On estime qu'environ 25% de tous les problèmes d'accessibilité numérique sont liés à un manque de compatibilité avec le clavier. Comme nous l'avons vu dans le module de sélection au clavier, ce problème concerne tous les types d'utilisateurs, y compris les personnes voyantes qui ne disposent que d'un clavier, les utilisateurs de lecteurs d'écran malvoyants ou aveugles, et ceux qui utilisent un logiciel de reconnaissance vocale utilisant une technologie qui repose également sur l'accès au clavier.

Les tests de clavier permettent de répondre à des questions telles que:

  • La page Web ou la fonctionnalité nécessitent-elles 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 ?
  • Pouvez-vous rester bloqué dans un élément qui ne devrait pas piéger votre concentration ?
  • Pouvez-vous naviguer derrière ou autour d'un élément qui devrait bloquer la sélection ?
  • Lors de la fermeture d'un élément sélectionné, l'indicateur de focus est-il revenu à un emplacement logique ?

Bien que l'impact des fonctionnalités du clavier soit énorme, la procédure de test est assez simple. Il vous suffit de mettre votre souris de côté ou d'installer un petit package JavaScript et de tester votre site Web uniquement en utilisant votre clavier. Les commandes suivantes sont essentielles pour tester le clavier.

Clé Résultat
Tabulation Avance d'un élément actif à un autre
Maj+Tabulation Recule d'un élément actif à un autre
Flèches Parcourir les commandes associées
Barre d'espace Active/Désactive les états et descend la page
Maj+barre d'espace Permet de déplacer la page vers le haut
Entrée Déclenche des commandes spécifiques
Échappement Ignore les objets affichés de façon dynamique.

Vérifications visuelles

Les vérifications visuelles se concentrent sur les éléments visuels de la page et utilisent des outils tels que la loupe ou le zoom sur le navigateur pour examiner l'accessibilité du site Web ou de l'application.

Grâce aux vérifications visuelles, vous pouvez obtenir les renseignements suivants:

  • Existe-t-il des problèmes de contraste des couleurs qu'un outil automatisé ne pouvait pas détecter, comme du texte sur un dégradé ou une image ?
  • Existe-t-il des éléments qui ressemblent à des en-têtes, des listes et d'autres éléments structurels, mais qui ne sont pas codés en tant que tels ?
  • Les liens de navigation et les saisies de formulaire sont-ils cohérents sur l'ensemble du site Web ou de l'application ?
  • Des animations clignotantes, stroboscopiques ou animées dépassent-elles les recommandations ?
  • Les espaces sont-ils correctement insérés 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érification du contenu

Contrairement aux tests visuels qui se concentrent sur la mise en page, le mouvement et les couleurs, les vérifications du contenu se concentrent sur les mots de la page. Vous devez non seulement regarder le texte lui-même, mais aussi examiner le contexte pour vous assurer qu'il a du sens pour les autres.

Les vérifications du contenu permettent de répondre à des questions telles que:

  • Les titres des pages, 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 est-elle utilisée seule 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" ?
  • Des modifications ont-elles été apportées à la langue d'une page ?
  • Utilisez-vous du langage clair, et tous les acronymes sont-ils épelés lors de la première référence ?

Certaines vérifications du contenu peuvent être automatisées en partie. Par exemple, vous pouvez écrire un linter JavaScript qui vérifie la présence de "Cliquez ici" et vous suggère d'effectuer un changement. Cependant, il n'est pas rare que ces solutions personnalisées nécessitent une intervention humaine pour remplacer la copie par un élément contextuel.

Démonstration: test manuel

Jusqu'à présent, nous avons exécuté des tests automatisés sur notre page Web de démonstration. Nous avons détecté et corrigé huit types de problèmes différents. Nous sommes maintenant prêts à effectuer des vérifications manuelles pour voir si nous pouvons découvrir encore plus de problèmes d'accessibilité.

Étape 1

Notre nouvelle démonstration CodePen inclut tous les éléments des mises à jour d'accessibilité automatiques appliquées.

Affichez-le en mode débogage pour continuer les prochains tests. C'est important, car cela supprime le <iframe> qui entoure page Web de démonstration, qui peut interférer avec certains outils de test. En savoir plus sur Mode débogage de CodePen

Étape 2

Commencez votre processus de test manuel en mettant votre souris ou votre pavé tactile de côté et faites défiler le DOM vers le haut ou vers le bas à l'aide de votre clavier uniquement.

Problème 1: indicateur de mise au point visible

Vous devriez constater immédiatement le premier problème de clavier ou, plutôt, vous ne devriez pas le voir, car l'indicateur de mise au point visible a été supprimé. Lorsque vous parcourez le code CSS dans la démo, vous devriez constater que le redoutable "outline: none" a été ajouté au codebase.

  :focus {
    outline: none;
  }
<ph type="x-smartling-placeholder">
</ph> Résolvons le 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 ciblage visible pour les utilisateurs. Vous pouvez aller plus loin et créer un indicateur de mise au point stylisé en fonction de l'esthétique de votre produit numérique.

:focus {
  outline: 3px dotted #008576;
}

Problème 2: ordre de mise au point

Une fois que vous avez modifié l'indicateur de focus et qu'il est visible, veillez à utiliser la touche de tabulation sur la page. Vous remarquerez que le champ de saisie du formulaire utilisée pour s'abonner à la newsletter ne reçoit pas l'attention. Elle a été supprimée. de l'ordre de focus naturel par un index de tabulation négatif.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
<ph type="x-smartling-placeholder">
</ph> Résolvons le problème.

Étant donné que nous aimerions que les utilisateurs utilisent 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 permettre à l'entrée de redevenir sélectionnable au clavier.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>

Étape 3

Une fois les éléments sélectionnés au clavier, passons aux vérifications visuelles et de contenu.

Lors des tests du clavier, en appuyant sur la touche de tabulation vers le haut ou vers le bas, vous avez probablement remarqué que le clavier se concentrait sur trois liens visuellement cachés dans des paragraphes sur les différentes maladies.

Pour que notre page soit accessible, les liens doivent se démarquer du texte qui les entoure. et inclure un changement de style non coloré lors du survol avec la souris et lors du focus du clavier.

<ph type="x-smartling-placeholder">
</ph> Résolvons à présent le problème.

Une solution rapide consiste à souligner les liens à l’intérieur des paragraphes pour les faire ressortir. Cela résoudrait le problème d'accessibilité, mais cela pourrait ne pas correspondre à l'esthétique globale de la conception que vous espérez obtenir.

Si vous choisissez de ne pas souligner, vous devez modifier les couleurs de manière à répondre aux exigences à la fois pour l'arrière-plan et le texte.

En regardant la démonstration à l'aide de l'outil de vérification du contraste des liens, vous constaterez que la couleur du lien répond aux exigences de contraste des couleurs 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.

Vous pouvez modifier la couleur du lien pour qu'elle corresponde aux autres éléments de la page. Toutefois, 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.

<ph type="x-smartling-placeholder">
</ph> Une capture d&#39;écran de WebAIM pour le texte du lien montre que le lien vers le corps du texte échoue au niveau WCAG A. <ph type="x-smartling-placeholder">
</ph> Lorsque le lien et le corps du texte sont identiques, le test échoue.
<ph type="x-smartling-placeholder">
</ph> Une capture d&#39;écran de WebAIM montre que tous les tests réussissent lorsque la couleur du lien est verte. <ph type="x-smartling-placeholder">
</ph> Lorsque le lien et le corps du texte sont différents, le test réussit.

Problème 4: Contraste des couleurs des icônes

Un autre problème de contraste des couleurs manqué est les icônes des réseaux sociaux. Dans le module Couleur et contraste, vous avez appris que les icônes essentielles doivent respecter un contraste de couleurs 3:1 avec l'arrière-plan. Cependant, dans la démo, les icônes des réseaux sociaux ont un rapport de contraste de 1,3:1.

<ph type="x-smartling-placeholder">
</ph> Résolvons à présent le problème.

Pour respecter les exigences de contraste des couleurs 3:1, les icônes des réseaux sociaux sont remplacées par un gris plus foncé.

<ph type="x-smartling-placeholder">
</ph> Capture d&#39;écran de la démonstration avec l&#39;analyseur de couleur montrant une erreur de contraste des couleurs des icônes.

Problème 5: mise en page du contenu

Si vous regardez la mise en page du contenu du paragraphe, vous constatez que le texte est entièrement justifiées. Comme vous l'avez appris au cours Module typographique, cela crée des "rivières de l'espace", ce qui peut rendre le texte difficile aux utilisateurs.

p.bullet {
   text-align: justify;
}
<ph type="x-smartling-placeholder">
</ph> Résolvons le problème.

Pour réinitialiser l'alignement du texte dans la démo, vous pouvez mettre à jour le code afin de text-align: left; ou supprimer entièrement cette ligne du CSS, comme c'est le cas à gauche alignement par défaut pour les navigateurs. Veillez à tester le code, au cas où d'autres les styles hérités suppriment l'alignement du texte par défaut.

p.bullet {
   text-align: left;
}

Étape 4

<ph type="x-smartling-placeholder">
</ph> Capture d&#39;écran du site de démonstration du Medical Mysteries Club. <ph type="x-smartling-placeholder">
</ph> Tous les problèmes manuels ont été résolus dans la démonstration, comme illustré sur cette image.

Une fois que vous avez identifié et corrigé tous les problèmes d'accessibilité décrits dans les étapes précédentes, votre page doit ressembler à notre capture d'écran.

Il est possible que vous remarquiez plus de problèmes d'accessibilité lors des vérifications manuelles que ce que nous avons vu dans ce module. Nous découvrirons bon nombre de ces problèmes dans le prochain module.

Étape suivante

Bravo ! Vous avez terminé les modules de test automatique et manuel. Vous pouvez consulter notre nouveau CodePen, où tous les correctifs d'accessibilité automatiques et manuels sont appliqués.

Passez maintenant au dernier module de test tests des technologies d'assistance.

Testez vos connaissances

Tester vos connaissances sur les tests d'accessibilité manuels

Quels éléments doivent respecter les normes de contraste de couleurs des WCAG ?

Icônes
Les icônes doivent respecter les normes de contraste des couleurs, mais ce n'est pas la seule option.
Headings
Les en-têtes doivent respecter les normes de contraste des couleurs, mais ce n'est pas la seule option.
Corps du texte
Le corps du texte doit respecter les normes de contraste des couleurs, mais ce n'est pas la seule option.
Toutes les réponses ci-dessus
Chaque élément doit respecter les normes de contraste écrites par les WCAG.