Le contenu est-il perceptible ?
Des contrôles visuels sont nécessaires pour les éléments qui ne peuvent pas être testés automatiquement ou à l'aide des technologies d'assistance, ainsi que pour étudier plus en détail les problèmes survenant pendant les tests automatisés et à l'aide des technologies d'assistance.
Même si aucune erreur ne survient lors des vérifications automatisées, vous devrez vous assurer que les descriptions de texte alternatives soient correctement utilisées, vérifier la qualité et l'exactitude des captures d'écran et déterminer si le contenu vidéo nécessite des transcriptions descriptives.
Soyez attentif à la manière dont la couleur est utilisée dans tout le site. Certaines informations peuvent uniquement être communiquées par ce biais, par exemple lorsqu'il s'agit d'indiquer si un élément est sélectionné ou si le texte est interactif. Utilisez l'outil TPG Colour Contrast Analyzer (ou un autre outil de test du contraste) pour tester si le texte est suffisamment contrasté par rapport à l'arrière-plan. Pour le texte ordinaire, le rapport de contraste doit être de 4.5:1 ou plus. Pour le texte de grande taille (18pt+) ou plus gras (14pt+) et pour le contenu non textuel important, tel que les icônes, il peut être un peu inférieur (3:1 ou plus).
Si vous constatez des interactions étranges lors des tests avec un lecteur d'écran, telles que la lecture de contenu non pertinent, la communication inappropriée d'une interaction ou la lecture de contenu dans un ordre illogique, vous devez inspecter le code pour remonter à la source du problème. Une balise importante manque-t-elle ? Le balisage ARIA est-il incorrectement utilisé ?
Essayez de comprendre le problème du mieux possible. Certaines erreurs courantes seront faciles à identifier au fil du temps. Toutefois, ne vous inquiétez pas si vous ne savez pas précisément ce qui cause un problème donné. Dans ce cas, décrivez-le de la manière la plus détaillée possible et incluez-le dans votre rapport avec toute information complémentaire pouvant être utile. Vous pouvez inclure une description du comportement attendu et de la manière dont il diffère de ce que vous observez. Réalisez des captures d'écran des informations pouvant être utiles, telles que l'élément proprement dit, le code sous-jacent et la restitution du lecteur d'écran, et incluez-les également dans votre rapport.
Le contenu est-il utilisable ?
Inspectez les titres de vos pages définis par programmation ; ils apparaîtront dans les onglets de votre navigateur. Les titres doivent être uniques, descriptifs et organisés dans l'ordre inverse de la navigation hiérarchique, du plus spécifique au plus général. Si vous êtes comme moi et que vous avez de nombreux onglets ouverts au même moment, vous apprécierez que cette exigence soit respectée.
Ensuite, intéressons-nous au texte des liens. Les pages regorgent de liens de type En savoir plus ou Cliquez ici ? Il est souvent très facile de régler ce problème avec des recommandations de création de contenu adéquates, car les liens peuvent presque toujours être associés à du texte pertinent dans le contenu environnant, offrant une description claire de la destination du lien.
Que se passe-t-il si vous ne trouvez pas les informations dont vous avez besoin grâce à la navigation seule ? Existe-t-il une deuxième méthode pour trouver du contenu ? Au moins deux méthodes permettant de trouver des informations doivent être disponibles, sauf si le site est une série d'étapes, comme un formulaire d'inscription dans lequel l'utilisateur passe de page en page dans un ordre imposé. La première méthode sera toujours la navigation. La deuxième peut être une recherche sur l'ensemble du site, ou un plan du site.
Prenez note de toute interaction à durée limitée. Si le site comporte un composant de session de connexion ou un formulaire avec une limite de temps, vous devez obtenir une notification avant l'expiration de la session.
Le contenu est-il compréhensible ?
La première chose que vous devrez vérifier, c'est si la langue de la page est définie par programmation. Elle figure alors au tout début de votre code, identifiée par un attribut de langue dans votre balise HTML, par exemple <html lang=”en”>. La plupart des vérificateurs automatisés la choisiront si l'attribut de langue est manquant, mais ils ne pourront pas identifier si la langue de la page est incorrectement définie. Cela peut parfois arriver si un site est disponible dans plusieurs versions linguistiques. Une fois, j'ai dû tester une page sur laquelle le contenu apparaissait en anglais, mais la langue était définie sur l'allemand par erreur. Sachant que le lecteur d'écran utilise les informations d'attribut de langue pour la prononciation, il essayait de lire toutes les informations comme si elles étaient en allemand. Par conséquent, le texte était lu avec un fort accent allemand et les nombres étaient lus dans une langue totalement différente du contenu principal. Si la page propose du contenu dans plusieurs langues, tout contenu dans une langue différente de celle de la page principale doit avoir son propre attribut de langue.
À mesure que vous vous familiarisez avec le site web, vérifiez s'il existe des incohérences dans l'interface. Observez si la navigation change d'une page à l'autre ou si des éléments ont des noms incohérents dans différentes sections du site, ce qui pourrait dérouter certains utilisateurs. Pour la navigation, les liens qui sont répétés d'une page à l'autre doivent apparaître dans le même ordre. Les éléments qui se répètent tout au long du site doivent avoir des noms cohérents. Par exemple, si vous utilisez plusieurs zones de recherche, elles ne doivent pas être nommées « Rechercher » sur une page et « Trouver » sur une autre.
Enfin, consacrez un peu de temps aux éventuels formulaires de saisie que vous rencontrez. Si une saisie non valide peut empêcher l'envoi, par exemple si des saisies sont requises ou si un format spécifique est exigé pour certains champs, tels que les codes postaux et les adresses e-mail, les erreurs doivent être clairement décrites. Si un formulaire se contente de signaler une série de champs de saisie sans fournir d'informations ou de suggestions sur la manière de résoudre les erreurs, ou si les libellés et les instructions pour les formulaires sont absents ou déconcertants, les utilisateurs sont moins susceptibles de pouvoir renseigner correctement les informations.
Le contenu est-il robuste ?
Tout d'abord, effectuez un contrôle de validation sur le balisage. Vous pouvez utiliser un outil tel que Nu HTML Checker ou tout autre outil de validation. L'avantage de ce vérificateur spécifique est que vous pouvez utiliser le bookmarklet d'analyse exclusive des règles WCAG (en anglais). Toutes les erreurs de balisage n'auront pas nécessairement une incidence sur l'accessibilité, et ce bookmarklet filtre uniquement les types d'erreurs ayant trait aux règles WCAG. Ainsi, vous pourrez prioriser les problèmes les plus susceptibles de causer des problèmes pour les technologies d'assistance.
La deuxième exigence pour un contenu robuste est un peu plus complexe, en particulier si vous n'êtes pas encore familiarisé avec ARIA. Vous devrez vérifier que les éléments disposent de rôles, d'états et de propriétés appropriés, en particulier pour les composants personnalisés, car le balisage HTML répond à cette exigence par défaut. Si vous n'êtes pas encore familiarisé avec ARIA, repensez à l'approche que j'ai évoquée lorsque nous avons traité de la perceptibilité. Si certains comportements ou interactions ne sont pas clairs, décrivez-les en détail et expliquez à quel endroit vous observez des incohérences entre le fonctionnement de l'élément et la manière dont il est communiqué aux technologies d'assistance. Une fois familiarisé avec ARIA dans les chapitres suivants, et lorsque vous aurez acquis de l'expérience, vous pourrez identifier précisément les rôles, les états et les propriétés nécessaires pour rendre les interactions accessibles.
À vous de jouer : testez manuellement votre site
À l'aide ce guide de test, parcourez chaque critère faisant appel à des techniques de test manuelles et consignez les problèmes que vous rencontrez dans votre rapport. Pensez à ajouter des captures d'écran et à noter les différences entre l'interaction escomptée et ce que vous avez observé.
En résumé
Le texte alternatif doit être utilisé de manière appropriée. Il doit décrire les images informatives, ignorer les images décoratives et décrire la destination du lien plutôt que l'image proprement dite, lorsque l'image est interactive.
Vérifiez que les vidéos disposent de sous-titres, de transcriptions descriptives ou d'alternatives textuelles lorsque la vidéo comprend des visuels importants.
Les pages doivent avoir des titres définis par programmation, qui soient à la fois uniques et significatifs.
L'objectif des liens doit être clairement identifiable grâce au texte du lien, à la phrase qui contient le texte ou à des libellés accessibles.
Les formulaires doivent fournir des instructions et des messages d'erreur clairs.
Maintenant que vous avez terminé les contrôles manuels, la dernière étape consiste à tester le site à l'aide de certaines technologies d'assistance. Dans le chapitre suivant, nous allons découvrir en quoi l'interaction au clavier est utile pour évaluer la saisie alternative, et nous allons utiliser un lecteur d'écran.
