Tests manuels d'accessibilité

Principes de base des tests manuels

Les tests d'accessibilité manuels utilisent des tests, des outils et des techniques clavier, visuels et cognitifs pour identifier les problèmes que les outils automatisés ne peuvent pas détecter. Comme les outils automatisés ne couvrent pas tous les critères de réussite identifiés dans les WCAG, il est essentiel que vous exécutiez des tests d'accessibilité automatisés et que vous continuiez à tester !

À mesure que la technologie progresse, de plus en plus de tests pourront être couverts par des outils automatisés seuls. Toutefois, aujourd'hui, des vérifications manuelles et avec 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 :

• Assez simple et rapide à exécuter
• Détecter un pourcentage plus élevé de problèmes 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 à reproduire à grande échelle
• Nécessitent davantage d'expertise en accessibilité pour exécuter des tests et interpréter les résultats

Comparez les éléments et les détails d'accessibilité qui peuvent être détectés par un outil automatisé à ceux qui ne le seront pas.

Types de tests manuels

De nombreux outils et techniques manuels sont à prendre en compte lorsque vous examinez l'accessibilité numérique de votre page Web ou de votre application. Les trois principaux domaines d'intérêt des tests manuels sont la fonctionnalité du clavier, les vérifications axées sur l'aspect visuel et les vérifications générales du contenu.

Nous abordons chacun de ces sujets de manière générale dans ce module, mais les tests suivants ne sont pas censés constituer une liste exhaustive de tous les tests manuels que vous pouvez ou devez exécuter. Nous vous encourageons à commencer par une checklist d'accessibilité manuelle provenant d'une source fiable, puis à développer votre propre checklist de tests manuels ciblée pour les besoins spécifiques de votre produit numérique et de votre équipe.

Vérifications du 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 sur la sélection au clavier, cela affecte tous les types d'utilisateurs, y compris ceux qui n'utilisent que le clavier, ceux qui utilisent un lecteur d'écran en raison d'une déficience visuelle ou de la cécité, et ceux qui utilisent un logiciel de reconnaissance vocale qui repose également sur l'accessibilité au clavier du contenu.

Les tests de clavier répondent à 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 sélection au clavier est-il toujours visible ?
• Vous êtes bloqué dans un élément qui ne devrait pas piéger la sélection ?
• Pouvez-vous naviguer derrière ou autour d'un élément qui devrait piéger la sélection ?
• Lorsque vous fermez un élément sélectionné, l'indicateur de sélection revient-il à 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 tester le clavier.

Vérifications visuelles

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

Les vérifications visuelles peuvent vous indiquer :

• Existe-t-il des problèmes de contraste de couleurs qu'un outil automatisé n'a pas pu détecter, comme du texte sur un dégradé ou une image ?
• Y a-t-il des éléments qui ressemblent à des titres, des listes et d'autres éléments structurels, mais qui ne sont pas codés comme 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 clignotements, des stroboscopes ou des animations qui dépassent les recommandations ?
• Le contenu est-il correctement espacé ? Pour les lettres, les mots, les lignes et les paragraphes ?
• Pouvez-vous voir tout le contenu à l'aide d'une loupe ou du zoom du navigateur ?

Vérifications du contenu

Contrairement aux tests visuels qui se concentrent sur les mises en page, les mouvements et les couleurs, les vérifications de contenu se concentrent sur les mots présents sur la page. Vous devez non seulement examiner le texte lui-même, mais aussi le contexte pour vous assurer qu'il est compréhensible pour les autres.

Les vérifications du contenu répondent à des questions telles que :

• Les titres de page, les en-têtes et les libellés de formulaire sont-ils clairs et descriptifs ?
• Les alternatives textuelles aux images sont-elles concises, précises et utiles ?
• La couleur est-elle le seul moyen de transmettre une signification ou des informations ?
• Les liens sont-ils descriptifs ou utilisez-vous du texte générique tel que "en savoir plus" ou "cliquez ici" ?
• La langue d'une page a-t-elle été modifiée ?
• Le langage clair est-il utilisé et tous les acronymes sont-ils écrits en toutes lettres lors de leur première mention ?

Certaines vérifications de contenu peuvent être partiellement automatisées. Par exemple, vous pouvez écrire un linter JavaScript qui recherche l'expression "Cliquez ici" et vous suggère de la modifier. Toutefois, ces solutions personnalisées nécessitent souvent encore une intervention humaine pour modifier le texte et l'adapter au contexte.

Démo : Test manuel

Jusqu'à présent, nous avons exécuté des tests automatisés sur notre page Web de démonstration, et nous avons identifié 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 d'autres problèmes d'accessibilité.

Étape 1

Notre démonstration CodePen mise à jour contient toutes les modifications d'accessibilité automatiques.

Affichez-le en mode débogage pour passer aux tests suivants. Cette étape est importante, car elle supprime le <iframe> qui entoure la page Web de démonstration, ce qui peut interférer avec certains outils de test. En savoir plus sur le mode débogage de CodePen

Étape 2

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

Problème 1 : Indicateur de focus visible

Vous devriez voir le premier problème de clavier immédiatement (ou plutôt, vous ne devriez pas le voir), car l'indicateur de sélection visible a été supprimé. Lorsque vous analysez le CSS dans la démo, vous devriez trouver le redoutable "outline: none" ajouté à la codebase.

  :focus {
    outline: none;
  }

Remédions à ce problème.

Comme vous l'avez appris dans le module sur la sélection au clavier, vous devez supprimer cette ligne de code pour permettre aux navigateurs Web d'ajouter une sélection visible pour les utilisateurs. Vous pouvez aller plus loin et créer un indicateur de sélection dont le style correspond à 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 sélection 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 ne reçoit pas le focus. Il a été supprimé de l'ordre de mise au point naturel par un tabindex négatif.

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

Remédions à ce problème.

Comme nous souhaitons que les utilisateurs utilisent ce champ pour s'inscrire à notre newsletter, il nous suffit de supprimer le tabindex négatif ou de le définir sur zéro pour permettre à l'entrée de redevenir accessible au clavier.

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

Étape 3

Une fois la sélection au clavier vérifiée, nous passons aux vérifications visuelles et de contenu.

Problème 3 : Contraste des couleurs des liens

En parcourant la page de démonstration avec la touche de tabulation, vous avez probablement remarqué que le clavier se concentrait sur trois liens masqués dans les paragraphes sur les différentes affections médicales.

Pour que notre page soit accessible, les liens doivent se démarquer du texte environnant et inclure un changement de style non lié à la couleur lorsque la souris est placée dessus et que le clavier est utilisé pour les sélectionner.

Remédions à ce problème.

Une solution rapide consiste à souligner les liens dans les paragraphes pour les faire ressortir. Cela résoudrait le problème d'accessibilité, mais ne correspondrait peut-être pas à l'esthétique globale que vous souhaitez obtenir.

Si vous choisissez de ne pas ajouter de soulignement, vous devrez modifier les couleurs de manière à répondre aux exigences concernant l'arrière-plan et le texte.

Si vous examinez la démo à l'aide d'un outil de vérification du contraste des liens, vous constaterez que la couleur du lien respecte l'exigence de contraste de 4,5:1 entre le texte de taille normale et l'arrière-plan. Toutefois, les liens non soulignés doivent également respecter un rapport de contraste des couleurs de 3:1 par rapport au texte environnant.

Une option consiste à modifier la couleur du lien pour qu'elle corresponde à celle des autres éléments de la page. Toutefois, si vous définissez la couleur des liens sur 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 non détecté concerne les icônes de réseaux sociaux. Dans le module Couleur et contraste, vous avez appris que les icônes essentielles doivent présenter un contraste de couleur de 3:1 par rapport à l'arrière-plan. Toutefois, dans la démo, les icônes de réseaux sociaux ont un rapport de contraste de 1,3:1.

Remédions à ce problème.

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

Problème 5 : Mise en page du contenu

Si vous examinez la mise en page du contenu du paragraphe, vous verrez que le texte est entièrement justifié. Comme vous l'avez appris dans le module sur la 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;
}

Remédions à ce problème.

Pour réinitialiser l'alignement du texte dans la démo, vous pouvez remplacer le code par text-align: left; ou supprimer complètement cette ligne du code CSS, car l'alignement par défaut des navigateurs est à gauche. 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 trouviez plus de problèmes d'accessibilité lors de vos vérifications manuelles que ceux abordés dans ce module. Nous découvrirons un grand nombre de ces problèmes dans le prochain module.

Étape suivante

Bravo ! Vous avez terminé les modules sur les tests automatisés et manuels. Vous pouvez consulter notre CodePen mis à jour, qui contient tous les correctifs d'accessibilité automatiques et manuels appliqués.

Maintenant, passez au dernier module de test axé sur les tests de technologie d'assistance.