ACCESSIBILITÉ POUR LES DÉVELOPPEURS & TESTEURS QA
Aperçu
Ces documents couvrent toutes les bases essentielles du design et doivent également être consultés au début d’un projet par l’équipe. Ils couvrent toutes les principales bonnes pratiques d’accessibilité des sites web qui ne sont pas liées à la conception d’un composant spécifique. Comme pour bon nombre de documents sur les composants, ils contiennent des tests que le chef de projet peut utiliser comme critères d’acceptation pour l’assurance qualité et des techniques que les développeurs peuvent utiliser pour respecter ces critères.
Ces guides sont conçus pour prendre en charge n’importe quel système de conception, y compris le Material Design, et peuvent également être utilisés pour soutenir une conception accessible sur des plateformes tierces telles que Wordpress, SAP et Salesforce, et, en tant que tels, peuvent être utilisés dans chaque sprint sur n’importe quel projet.
Plus de formations et de conseils sur l’accessibilité sont disponibles sur les chaînes Youtube suivantes :
1. Création de composants accessibles
Lors du développement de nouveaux designs de composants, il peut y avoir des problèmes d’accessibilité qui ne sont pas couverts par les directives d’accessibilité car ils sont spécifiques à une conception d’interaction particulière.
Dans ces cas, des recherches supplémentaires sont nécessaires pour identifier les meilleures pratiques disponibles ailleurs sur le web, c’est pourquoi la page suivante vous fournira une liste de composants qui nécessitent à la fois des recherches supplémentaires et les techniques et méthodologies que vous pouvez utiliser pour garantir que votre composant réponde aux attentes des utilisateurs.
Lorsque cela est approprié, les documents d’orientation contiennent des implémentations de référence qui démontrent les comportements de code requis et fournissent des tests QA recommandés.
Tests
Pour permettre aux équipes d’intégrer des critères de test dans leur plan de travail, le script de test d’accessibilité suivant aidera à la fois les chefs de projet et les développeurs à atteindre les critères de succès en matière d’accessibilité. Des tests automatisés sont également disponibles via UTS Test Magic, Cypress, Sa11y pour Salesforce et doivent être utilisés en combinaison avec le script de test manuel suivant : Script de test développeur Colt.
Pour tester l’accessibilité aux lecteurs d’écran, utilisez Windows Narrator pour vérifier l’accessibilité de votre composant ou application. Le guide Utiliser Windows Narrator pour tester l’accessibilité Web présente les contrôles, l’approche et les nombres attendus.
Les pages Web peuvent être partiellement testées à l’aide d’extensions de navigateur. Il en existe plusieurs, commerciales et non commerciales, qui fonctionnent dans Microsoft Edge et Google Chrome. L’un d’eux, fiable, gratuit et qui produit des feuilles de calcul pouvant servir à suivre les bogues, est l’Equal Access Tracker d’IBM :
Différents outils de test automatisés peuvent donner des résultats différents, certains sont commerciaux ou semi-commerciaux et n’exportent pas tous des rapports. Veuillez vous assurer que tous les membres d’une équipe produit utilisent le même outil.
Utilisés en combinaison avec les tests manuels des lignes directrices et les tests avec Windows Narrator, la plupart des problèmes d’utilisation et d’accessibilité seront faciles à repérer et à corriger.
Cette vue d’ensemble par Sparkbox couvre toutes les fonctionnalités clés de l’outil de test IBM.
Guides de composants
Les guides de bonnes pratiques suivants proviennent de divers systèmes de conception tiers, blogs ou ressources documentaires fiables, et bien que les designs puissent ne pas être exactement identiques à ceux mis en œuvre par Colt, les méthodologies et techniques restent un moyen valable de comprendre les problèmes potentiels et leurs solutions.
Navigation
Contenu interactif
Champs méta
Saisie de données
2. Accessibilité de la plateforme
Si vous créez des pages web, des applications ou des composants sur une plateforme ou un framework tiers tels que Salesforce, SAP ou Wordpress, chacune de ces plateformes fournit des recommandations spécifiques. Celles-ci doivent être utilisées en complément des guides d’accessibilité Colt.
Wordpress
Salesforce
SAP
3. Perception des couleurs
Chaque couleur est perçue légèrement et parfois de manière significative différemment selon les personnes, et beaucoup de personnes ne peuvent pas du tout différencier certaines teintes. Veiller à ce que les designs des pages web de Colt ne dépendent pas d’une perception précise des couleurs permet de ne pas exclure des personnes parce que certaines fonctionnalités reposent sur la couleur dans le design.
Une utilisation réfléchie des couleurs de la marque Colt, toutefois, peut augmenter l’accessibilité pour certains utilisateurs et améliorer l’utilisabilité pour de nombreux utilisateurs. Ainsi, plutôt que d’éviter l’utilisation de la couleur comme signification sur une page web, assurez-vous que lorsque la couleur est utilisée comme indice visuel, des indices visuels alternatifs non basés sur la couleur sont également fournis. Cela est souvent appelé en conception et en ingénierie «redondance.'
La déficience de la vision rouge-vert est la forme la plus courante des soi-disant troubles de la vision des couleurs. Elle touche environ 1 homme sur 12 et 1 femme sur 200. La déficience de la perception bleu-jaune est beaucoup moins courante, et le daltonisme monochromatique est encore plus rare. Il existe également d’autres conditions telles que Synesthésie, Glaucome, Syndrome d’Irlens et certaines personnes atteintes de TSA qui peuvent rencontrer des difficultés pour traiter les couleurs.
Comment tester cela
Pour chaque page web, effectuez les vérifications suivantes. Indiquez une réponse, « oui » ou « non », à chaque question. Le résultat de réussite est indiqué en MAJUSCULE après chaque question, par ex. [Y/N] où Y est requis pour réussir. Pour chaque résultat échoué, documentez-le comme l’un des éléments suivants :
Comme un défaut
Un défaut, mais avec une explication de pourquoi il devrait être autorisé en tant qu’exception
Un défaut, mais avec une explication de pourquoi il n’est pas applicable
Tests qui devraient être effectués manuellement
Voici quelques exemples de questions clés que vous devriez poser :
En considérant chacun des liens sur la page, sont-ils tous visuellement identifiables sans utiliser la couleur ? [Y/N]
Lors de l’interaction avec chacune des fonctionnalités de la page (comme la validation ou les indicateurs de progression), est-il possible de savoir dans quel état chacune se trouve, même si la couleur est désactivée ? [Y/N]
En ce qui concerne les graphiques et diagrammes, les catégories ou ensembles de données affichés sur le graphique sont-ils repérés par un traitement visuel autre que la couleur ? [Y/N]
Méthodes et stratégies de test supplémentaires
Si vous n’êtes pas daltonien vous-même, vous pouvez tester une page web à l’aide d’un simulateur de daltonisme. L’application Sim Daltonism peut être installée sur votre téléphone mobile et ouvrira un visualiseur qui appliquera un filtre de daltonisme à tout ce qui se trouve devant la caméra.
4. Interactions de formulaire
Les formulaires peuvent être difficiles pour les utilisateurs ayant des déficiences visuelles et/ou cognitives. S’assurer que les formulaires sont bien conçus et accessibles permet de garantir que les utilisateurs comprennent et utilisent ces formulaires comme prévu.
Lorsque les formulaires Web appliquent des conventions et de bonnes pratiques d’utilisabilité, les utilisateurs peuvent remplir les formulaires plus rapidement et avec moins d’erreurs dès la première tentative. Les formulaires peuvent être des portes d’accès au contenu et aux services de Colt via la connexion, des opportunités d’emploi, l’étape finale pour devenir client ou même le seul moyen de soulever un problème ou une réclamation. Si les formulaires sont mal conçus ou mal implémentés, ils excluent complètement les utilisateurs en situation de handicap.
Comment tester cela
Pour chaque page web, effectuez les vérifications suivantes. Indiquez une réponse, « oui » ou « non », à chaque question. Le résultat de réussite est indiqué en MAJUSCULE après chaque question, par ex. [Y/N] où Y est requis pour réussir. Pour chaque résultat échoué, documentez-le comme l’un des éléments suivants :
Comme un défaut
Un défaut, mais avec une explication de pourquoi il devrait être autorisé en tant qu’exception
Un défaut, mais avec une explication de pourquoi il n’est pas applicable
Tests qui pourraient être automatisés
Voici un exemple de test qui ne nécessite pas de balayage manuel :
Chaque élément de saisie a-t-il un élément label HTML sémantiquement valide qui lui est associé ? [Y/N]
Tests qui devraient être effectués manuellement
Voici quelques exemples de questions clés que vous devriez poser :
Le formulaire entier peut-il être rempli, y compris la correction d’éventuelles erreurs, et soumis en utilisant uniquement le clavier ? [Y/N]
L’ordre de tabulation à travers le formulaire (tel qu’indiqué par un indicateur de focus visible) est-il logique et prévisible pour un utilisateur voyant utilisant le clavier ? [Y/N]
Les champs obligatoires sont-ils visiblement marqués comme tels, et utilisent-ils un attribut HTML input required sur l’élément input ? [Y/N]
Les messages d’erreur sont-ils rédigés et affichés de manière à indiquer clairement quels champs ont rejeté la saisie, pourquoi la saisie n’a pas été acceptée et quoi faire pour la corriger ? [Y/N]
Réinitialisations, délais et validation
Boutons de réinitialisation
Évitez d’utiliser un bouton Réinitialiser sur les formulaires. Ils sont rarement utilisés, et il peut être exaspérant de voir un formulaire entièrement rempli effacé par un seul clic accidentel. Notez que sans bouton de réinitialisation, les groupes de boutons radio peuvent poser problème dans certains cas. L’une de leurs caractéristiques est qu’on ne peut pas « désélectionner » le groupe une fois qu’une option a été sélectionnée dans ce groupe ; on ne peut que déplacer la sélection sur un autre bouton radio du même groupe. Pour cette raison, il est recommandé d’inclure une option de type « aucune des réponses ci-dessus » lorsque cela est approprié.
Durée
Les formulaires qui expirent trop tôt peuvent être frustrants, surtout si le processus a été long, comme la saisie d’une spécification pour un devis ou la candidature à un emploi. S’il n’y a pas de besoin spécifique d’avoir un délai d’expiration sur un formulaire, assurez-vous que les données sont conservées pendant au moins 20 heures. S’il doit y en avoir un, assurez-vous qu’il soit au moins 5 fois plus long que le temps nécessaire à un utilisateur voyant moyen et que les durées sont indiquées dans les instructions.
Validation
Lors de la validation d’un formulaire, assurez-vous que la valeur initiale saisie par l’utilisateur qui a provoqué l’erreur n’est pas effacée. En conservant la valeur initiale de l’utilisateur, celui-ci peut plus facilement identifier son erreur puis la corriger en la modifiant. L’utilisation des attributs WAI-ARIA peut aider à rendre les erreurs de validation plus faciles à suivre pour les utilisateurs d’aides techniques. Utilisez l’ attribut aria-invalid pour marquer chaque champ de saisie invalide comme ayant une erreur, et l’ attribut aria-describedby pour associer le message d’erreur spécifique à ce champ de saisie.
Messages d’erreur
Lorsqu’aucun message d’erreur n’est affiché, cela doit être considéré comme un défaut grave. Lorsqu’une soumission de formulaire est rejetée et qu’il n’y a aucun retour expliquant ce qui doit être corrigé pour continuer, le formulaire devient inutilisable.
Les messages d’erreur doivent être concis et précis pour expliquer pourquoi la soumission du formulaire a été rejetée, et ils doivent éviter d’inclure de longues chaînes de jargon technique. Tout code d’erreur doit être expliqué de manière non technique.
Vérifiez que tous les messages d’erreur pouvant s’afficher répondent aux exigences suivantes :
Spécifique : Dire simplement « il y a eu une erreur » ou « le formulaire est invalide » n’est pas utile. Le message doit indiquer clairement quel champ de saisie, ou quels champs s’il y en a plusieurs, était invalide et pourquoi il a été rejeté. Le nom du champ de saisie dans l’erreur doit correspondre exactement à l’étiquette du champ de saisie où l’erreur s’est produite.
Amical : Même si l’utilisateur a commis une erreur, l’expérience doit être agréable et utile. Évitez les phrases qui semblent agressives, comme « erreur utilisateur : saisie illégale », même si elles sont techniquement correctes car elles ne créent pas une bonne expérience utilisateur.
Actionnable : Communiquer qu’il y a un problème et quel est le problème n’est qu’une partie de la réponse. L’utilisateur doit également savoir quelles étapes il peut entreprendre pour résoudre le problème. Vérifiez qu’il y a des informations sur ce qu’il doit faire ensuite pour avancer et, si nécessaire, fournissez un lien vers la FAQ et le service d’assistance.
Texte d’espace réservé
Ce sont des mots qui apparaissent à l’intérieur d’un champ de saisie de formulaire et qui sont destinés à être un indice agréable à avoir. Ils ne remplacent pas des étiquettes appropriées et ne doivent pas dupliquer une étiquette, mais fournir des instructions ou des indices supplémentaires.
Les espaces réservés qui remplacent les étiquettes sont difficiles à utiliser pour les utilisateurs au clavier car dès que l’utilisateur tabule dans le champ de texte, les instructions disparaissent. Le contraste du texte d’espace réservé est délibérément faible, ce qui est une autre raison pour laquelle ils ne remplacent pas les étiquettes, et le texte d’espace réservé ne peut pas se réajuster, donc sur des écrans étroits l’utilisateur peut ne pas pouvoir en voir l’intégralité.
5. Accès au clavier
Bien qu’il existe de nombreux types de claviers différents (ou dispositifs de commutation équivalents) que les gens peuvent utiliser pour naviguer sur les pages web, du point de vue de l’implémentation, nous devons considérer les groupes suivants :
Tous les autres utilisateurs de clavier, c’est-à-dire les utilisateurs qui peuvent au moins partiellement voir l’écran, qui peuvent ou non utiliser un lecteur d’écran pour compléter leur expérience, mais qui dépendent des indices visuels affichés à l’écran pour naviguer.
Les utilisateurs qui n’ont pas accès à un dispositif de pointage tel qu’un trackpad ou une souris ou qui ont des conditions physiques telles que TMS, la paralysie cérébrale ou des différences des membres et pour lesquels le clavier est une méthode préférable.
La Lignes directrices pour l'accessibilité du contenu Web (WCAG) exige que les fournisseurs de pages web «s’assurent que, autant que possible, le contenu puisse être utilisé via un clavier ou une interface clavier.» Sans prise en charge du clavier, ces utilisateurs seront exclus de l’accès à votre page web. Une enquête WebAIM auprès des utilisateurs de lecteurs d’écran a révélé qu’une proportion importante d’utilisateurs a indiqué que «un manque d’accessibilité au clavier» était un problème pour eux. L’accès peut inclure l’utilisation de formulaires, de menus de navigation, de widgets interactifs, de pop-ups, d’alertes et de tout autre type de composant sur une page.
Éléments de contrôle focalisables
Lien : La touche Entrée doit activer/suivre le lien
Bouton : La touche Entrée ou Espace doit activer/appuyer sur le bouton
Cases à cocher/Boutons radio : Les touches Flèche doivent déplacer l’élément surligné, la touche Espace doit cocher ou décocher l’élément surligné
Sélecteur (déroulant) : Les touches Flèche doivent déplacer l’élément surligné, la touche Entrée doit sélectionner l’élément surligné
Dialogue : La touche Échap doit fermer le dialogue
Maintenir la visibilité du focus
Les navigateurs Web sont déjà accessibles pour indiquer quel élément d’une page a le focus en ajoutant un contour visible. En utilisant le CSS pour styliser ce focus, l’indicateur peut être personnalisé ou même désactivé. Un indicateur de focus manquant ou difficile à voir doit être considéré comme un défaut.
Remarque n°1 : Utiliser uniquement un changement de couleur pour indiquer le focus serait inaccessible aux utilisateurs qui ne perçoivent pas la couleur.
Remarque n°2 : Ne désactivez pas les fonctionnalités nécessaires à la navigation au clavier, par ex. :focus {outline:none;}
Visible au focus
Le contenu visuellement masqué à l’écran, mais qui peut recevoir le focus via la navigation au clavier, doit être conçu de sorte que le contenu devienne visible une fois qu’il a le focus. Un exemple en est un lien « Aller au contenu principal », destiné à permettre aux utilisateurs de franchir rapidement tout le contenu de navigation en haut de chaque page et d’accéder au contenu principal.
Validation
Lors de la validation d’un formulaire, assurez-vous que la valeur initiale saisie par l’utilisateur qui a provoqué l’erreur n’est pas effacée. En conservant la valeur initiale de l’utilisateur, celui-ci peut plus facilement identifier son erreur puis la corriger en la modifiant. L’utilisation des attributs WAI-ARIA peut aider à rendre les erreurs de validation plus faciles à suivre pour les utilisateurs d’aides techniques. Utilisez l’ attribut aria-invalid pour marquer chaque champ de saisie invalide comme ayant une erreur, et l’ attribut aria-describedby pour associer le message d’erreur spécifique à ce champ de saisie.
Raccourcis clavier
S’il existe de nombreux raccourcis clavier bien connus définis dans les applications de bureau, ce n’est pas le cas pour la myriade de pages web différentes qui existent. Bien qu’il soit possible d’utiliser l’attribut accesskey pour définir des touches de raccourci personnalisées, cela n’augmentera probablement pas l’accessibilité si les utilisateurs ne peuvent pas les prévoir ou en être informés de manière évidente. Et définir de tels raccourcis pourrait même aggraver la situation s’ils entrent en conflit avec des raccourcis standard intégrés définis dans le navigateur ou l’aide technique. Voir les raccourcis courants sur la BBC GEL Megapedia.
Éviter les pièges au clavier
Un «piège au clavier» existe chaque fois qu’une fonctionnalité d’une page web empêche l’utilisateur de s’éloigner d’un élément focalisé. Cela ne devrait bien sûr pas se produire, mais un JavaScript mal implémenté peut parfois altérer le fonctionnement normal du focus clavier et le rendre cassé de cette manière si l’auteur de la page web n’y prend pas garde.
Comment tester cela
Pour chaque page web, effectuez les vérifications suivantes. Indiquez une réponse, « oui » ou « non », à chaque question. Le résultat de réussite est indiqué en MAJUSCULE après chaque question, par ex. [Y/N] où Y est requis pour réussir. Pour chaque résultat échoué, documentez-le comme l’un des éléments suivants :
Comme un défaut
Un défaut, mais avec une explication de pourquoi il devrait être autorisé en tant qu’exception
Un défaut, mais avec une explication de pourquoi il n’est pas applicable
Tests qui devraient être (au moins partiellement) effectués manuellement
Voici quelques exemples de questions clés que vous devriez poser :
Est-il possible d’utiliser la touche Tab pour avancer, et la combinaison de touches Shift+Tab pour déplacer le focus de sorte que chaque lien et contrôle puisse être accédé et utilisé sans souris ni écran tactile ? [Y/N]
Lorsque vous déplacez le focus, il doit être clairement visible quel élément de la page Web a actuellement le focus, par exemple par un contour cohérent et visiblement contrasté. [Y/N]
Lorsque vous déplacez le focus, chaque élément qui reçoit le focus suit-il un ordre logique et prévisible, allant de haut en bas et de gauche à droite (pour les pages publiées en anglais et autres langues de gauche à droite) ? [Y/N]
Pour les composants interactifs, y compris les éléments de formulaire, est-il possible de naviguer et d’utiliser chaque élément, y compris de définir les options possibles, en utilisant les touches flèche, la touche Entrée, la touche Espace, etc. ? [Y/N]
Pour les composants complexes qui déplacent automatiquement le focus lorsque de nouveaux contenus s’ouvrent ou apparaissent, le focus revient-il à l’élément d’origine une fois que ce contenu se ferme ? [Y/N]
Pour le contenu qui est visuellement masqué au chargement de la page web, ce contenu devient-il visible lorsque le focus clavier entre dans l’élément ? [Y/N]
6. Étiquettes pour éléments interactifs
Les contrôles de formulaire et autres éléments interactifs doivent être correctement étiquetés. Le fait de ne pas le faire rendra difficile pour les utilisateurs d’aides techniques de comprendre l’objet du contrôle. Les éléments interactifs manquants ou mal étiquetés peuvent entraîner des problèmes ou de la confusion pour vos utilisateurs.
La Les Lignes directrices pour l'accessibilité du contenu Web indiquent que tous les éléments interactifs doivent avoir à la fois une étiquette et un nom accessible. L’étiquette est présentée visuellement et le nom accessible est utilisé par les aides techniques, comme les lecteurs d’écran. Souvent les deux sont identiques ; par exemple, si un lien englobe le texte "Accueil", tel que Accueil le texte "Accueil" est l’étiquette et le nom accessible.
De même, un bouton contenant le texte "Envoyer" a à la fois une étiquette visuelle et un nom accessible de "Envoyer".
Comment tester cela
Pour chaque page web, effectuez les vérifications suivantes. Indiquez une réponse, « oui » ou « non », à chaque question. Le résultat de réussite est indiqué en MAJUSCULE après chaque question, par ex. [Y/N] où Y est requis pour réussir. Pour chaque résultat échoué, documentez-le comme l’un des éléments suivants :
Comme un défaut
Un défaut, mais avec une explication de pourquoi il devrait être autorisé en tant qu’exception
Un défaut, mais avec une explication de pourquoi il n’est pas applicable
Tests qui devraient être effectués manuellement
Voici quelques exemples de questions clés que vous devriez poser :
Y a-t-il une étiquette textuelle visible qui identifie quel type d’information est attendu en saisie ? [Y/N]
L’étiquette est-elle proche du contrôle qu’elle décrit, de sorte qu’il soit évident à quel contrôle elle se réfère ? [Y/N]
L’étiquette est-elle toujours visible lorsque le contrôle a le focus ? [Y/N]
Si le contrôle est un groupe d’options sélectionnables, comme un menu déroulant ou une liste de boutons radio ou de cases à cocher, y a-t-il une étiquette textuelle visible décrivant la collection d’options ? [Y/N]
Lorsque les contrôles sont rencontrés par un lecteur d’écran, l’étiquette est-elle lue à haute voix comme prévu ? [Y/N]
Exemples et informations supplémentaires
Les trois aspects des étiquettes et des noms accessibles qui doivent être correctement implémentés sont basés sur l’utilisateur et la manière dont il interagit avec la page web. Avoir une étiquette visuelle est évidemment nécessaire pour permettre aux utilisateurs voyants qui naviguent à l’aide d’un curseur ou d’une souris de savoir à quoi servent les éléments interactifs : cliquer sur le bouton « fermer l’onglet », ou tabuler jusqu’au lien « page d’assistance » en sont des exemples.
En fournissant ces étiquettes de manière accessible vous servirez également les utilisateurs d’appareils de lecture d’écran, qui utiliseront ce texte pour prononcer le nom accessible à l’utilisateur. Dans certains cas, toutefois, il est possible d’appliquer une étiquette visible différente du nom accessible. Cela crée des problèmes potentiels pour les utilisateurs qui utilisent le contrôle vocal et la reconnaissance vocale pour naviguer, par exemple en disant « cliquer Envoyer ». Ces utilisateurs verront l’étiquette et l’utiliseront pour diriger leur aide technique, qui s’appuiera ensuite sur le nom accessible. Pour cette raison, il est recommandé de conserver l’étiquette visible identique au nom accessible.
Ne pas se fier au texte d’espace réservé
Texte d’espace réservé est parfois utilisé par les auteurs de pages comme s’il était une alternative à une étiquette. C’est parfois une tentative d’économiser de l’espace sur un formulaire puisque le texte d’espace réservé apparaît à l’intérieur du champ de saisie plutôt qu’à côté. Mais c’est précisément pourquoi il est inadapté comme étiquette. En plus d’avoir par défaut un faible contraste, il disparaît dès que l’utilisateur commence à entrer du texte dans le champ. À ce stade, il n’y a plus d’étiquette visible. Les utilisateurs ayant des troubles de la mémoire à court terme ou même ceux qui sont distraits et se sont détournés peuvent ne plus savoir à quoi correspond le champ.
Ne pas ajouter d’attribut title
Un attribut title est parfois ajouté aux éléments d’entrée de formulaire. Bien qu’il soit vrai que la plupart des lecteurs d’écran liront l’attribut title, cela n’apporte aucun avantage : l’utilisation de l’ élément label sémantique fonctionnerait également et présente l’avantage que l’étiquette peut être cliquée pour focaliser l’entrée. Avoir à la fois une étiquette et un attribut title signifie bien sûr que ces deux chaînes de texte seront lues, ce qui entraînera une duplication.
Masquer des parties d’étiquettes aux lecteurs d’écran
Dans certains cas, des parties spécifiques du texte utilisé dans une étiquette ont une signification conventionnelle, mais uniquement lorsqu’elles sont vues. Par exemple, l’astérisque est souvent utilisé pour indiquer visuellement à l’utilisateur qu’un élément de formulaire est requis. Alors que certains lecteurs d’écran peuvent énoncer l’astérisque, de nombreux lecteurs d’écran ne le feront pas. Il est acceptable de masquer l’astérisque aux lecteurs d’écran si l’information est rendue claire d’une manière alternative.
Masquer des parties d’étiquettes aux non-lecteurs d’écran
Une étiquette est souvent du texte brut mais peut être un élément avec un texte alternatif, comme une image, à condition que l’image soit une icône bien comprise. Lorsqu’une étiquette est visible uniquement sous forme d’icône, un texte alternatif doit être fourni pour les utilisateurs qui ne peuvent pas voir l’icône. Idéalement, le contrôle rendrait ce texte visible pour tout le monde avec l’icône, mais les contraintes de conception peuvent ne pas le permettre. Dans ce cas, fournir un texte comme étiquette accessible uniquement au lecteur d’écran est acceptable, à condition que l’icône soit bien connue et comprise des utilisateurs voyants sans le texte (par exemple une icône « loupe » comme étiquette d’un formulaire de recherche).
L’exemple ci-dessous utilise l’une des techniques de la section Texte alternatif pour les images Ces alternatives textuelles seront naturellement cachées aux utilisateurs regardant l’image.
7. Repères (landmarks)
En ajoutant des repères HTML à vos pages web, vous permettez aux aides techniques d’identifier les régions auxquelles un utilisateur pourrait vouloir accéder rapidement, par exemple en utilisant au minimum les balises header, nav, main, section et footer. Guide W3C sur les landmarks WAI-ARIA.
Une enquête WebAIM auprès des utilisateurs de lecteurs d’écran a révélé que plus de la moitié des répondants utiliseraient au moins parfois les repères HTML pour naviguer au sein d’une page web. Bien que d’autres fonctionnalités, telles que Les titres (Headings) et Liens, puissent être utilisées plus fréquemment selon l’enquête, ajouter des repères HTML à l’ensemble des panneaux de signalisation virtuels ne peut qu’aider, en particulier les utilisateurs qui ne peuvent pas parcourir visuellement un document pour décider où commencer.
La navigation par repères HTML est une technique qui peut être utilisée aussi bien par les utilisateurs voyants que non voyants, même sans l’aide d’un lecteur d’écran.
Pour les utilisateurs qui n’ont pas accès aux fonctionnalités de navigation par landmark intégrées à leur navigateur ou à leur aide technique, vous pouvez fournir ce que l’on appelle des «liens de saut» comme fonctionnalité de la page web elle-même. Les liens de saut doivent être le premier contenu dans le corps de la page web et doivent pointer vers le contenu identifié en utilisant le landmark main.
Cela aide les utilisateurs qui autrement devraient parcourir de nombreux liens de navigation et du contenu d’en-tête au clavier, par exemple, avant d’accéder au contenu qu’ils souhaitent consulter. Il est acceptable de masquer ces liens de saut pour éviter d’encombrer la page pour les utilisateurs qui naviguent à l’aide d’un pointeur (souris ou tactile par exemple) en appliquant du CSS qui rend le lien visuellement caché jusqu’à ce qu’il reçoive le focus clavier.
Comment tester cela
Pour chaque page web, effectuez les vérifications suivantes. Indiquez une réponse, « oui » ou « non », à chaque question. Le résultat de réussite est indiqué en MAJUSCULE après chaque question, par ex. [Y/N] où Y est requis pour réussir. Pour chaque résultat échoué, documentez-le comme l’un des éléments suivants :
Comme un défaut
Un défaut, mais avec une explication de pourquoi il devrait être autorisé en tant qu’exception
Un défaut, mais avec une explication de pourquoi il n’est pas applicable
Tests qui pourraient être automatisés :
Voici quelques exemples de questions clés que vous devriez poser :
La page web comporte-t-elle exactement une région identifiée avec le landmark main ? [Y/N]
Tout le contenu de la page web est-il contenu dans une région landmark ? [Y/N]
Tests qui devraient être (au moins partiellement) effectués manuellement :
Voici quelques exemples de questions clés que vous devriez poser :
Les zones de la page principalement destinées à afficher des liens de navigation sont-elles identifiées en utilisant le landmark nav ? [Y/N]
Le contenu d’en-tête de la page est-il identifié en utilisant le landmark header ? [Y/N]
Le contenu de pied de page de la page est-il identifié en utilisant le landmark footer ? [Y/N]
En ce qui concerne les autres landmarks, s’ils sont utilisés, chacun communique-t-il correctement le type de contenu qu’il contient : section, article, aside ? [Y/N]
Si un lien de saut existe, ce lien est-il en haut ou près du haut de la page et peut-il être utilisé lors de la navigation au clavier pour sauter au contenu principal ? [Y/N]
8. Liens
Lorsque vous rédigez le texte d’un lien, utilisez un texte concis mais complet décrivant la ressource liée. Cela est particulièrement important pour les personnes qui utilisent un lecteur d’écran pour parcourir l’ensemble de la page et lire une liste uniquement des liens, où chaque lien n’aura aucun contexte et devra être compris isolément.
Par exemple, une série de résumés d’articles, chacun contenant le lien avec le texte « En savoir plus » sera présenté comme une liste de nombreux extraits « En savoir plus » à l’utilisateur du lecteur d’écran, sans indication de ce à quoi renvoie chaque lien.
Utilisateur de lecteur d’écran : « En savoir plus » quoi ?
Ajouter du contexte au texte du lien supprimera les barrières pour les utilisateurs de lecteurs d’écran et aidera probablement les utilisateurs voyants à garder une trace de ce vers quoi ils naviguent. Dans des cas exceptionnels, où il serait redondant ou distrayant pour les utilisateurs voyants de lire les détails complets dans le contenu du lien, cela peut être géré en ajoutant le contexte comme texte visuellement caché disponible uniquement pour les utilisateurs de lecteurs d’écran.
Bien que le texte du lien apparaisse visuellement comme seulement « En savoir plus » dans le contexte de l’article intitulé « Nos valeurs », il apparaîtra comme « En savoir plus sur nos valeurs... » lorsqu’un utilisateur de lecteur d’écran ouvrira la liste de tous les liens de la page. Dans la mesure du possible, vous devriez garder le contenu destiné aux utilisateurs de lecteurs d’écran visuellement identique au contenu destiné aux autres utilisateurs. Tous les utilisateurs de lecteurs d’écran ne sont pas aveugles, et les utilisateurs de lecteurs d’écran qui peuvent voir le texte peuvent être confus d’entendre et de voir des contenus différents.
Icônes dans les liens
Bien qu’avoir un texte descriptif visible soit la manière la plus accessible d’étiqueter un lien, il existe des cas où une icône bien comprise serait plus naturelle. Dans ces cas, un texte alternatif doit être fourni pour les utilisateurs de lecteurs d’écran qui ne peuvent pas voir l’icône.
Un simple élément img HTML affichera l’icône. Les lecteurs d’écran annonceront qu’une « image » est présente et liront tout texte dans l’attribut alt.
Voir le guide pour Textes alternatifs pour les images fonctionnelles.
Liens externes
Lorsqu’on crée un lien vers des sites externes, il est conseillé, pour des raisons de sécurité et de responsabilité, d’informer l’utilisateur qu’il s’apprête à visiter un contenu dont vous n’êtes pas responsable. Cela peut poser problème si l’utilisateur est connecté à votre site ou a une autre session qui serait interrompue ou perdue une fois qu’il quitte votre site.
Nouveaux onglets
Ouvrir des liens dans de nouveaux onglets ou fenêtres peut rendre l’expérience de certains utilisateurs plus confuse et moins accessible, il convient donc d’y recourir rarement. Une exception peut concerner les liens vers des sites externes. Si le lien lance une modale ou une page dans un nouvel onglet ou une nouvelle fenêtre, assurez-vous que cela soit expliqué dans le texte du lien.
Comment tester cela
Pour chaque page web, effectuez les vérifications suivantes. Indiquez une réponse, « oui » ou « non », à chaque question. Le résultat de réussite est indiqué en MAJUSCULE après chaque question, par ex. [Y/N] où Y est requis pour réussir. Pour chaque résultat échoué, documentez-le comme l’un des éléments suivants :
Comme un défaut
Un défaut, mais avec une explication de pourquoi il devrait être autorisé en tant qu’exception
Un défaut, mais avec une explication de pourquoi il n’est pas applicable
Tests qui doivent être effectués manuellement :
Voici quelques exemples de questions clés que vous devriez poser :
Chaque lien contient-il un texte visible ou une icône conventionnelle bien comprise ? [Y/N]
Pour les liens contenant uniquement une icône, un texte équivalent est-il attribué au graphique ? [Y/N]
Tous les liens sont-ils de manière cohérente et visuellement distincts du texte environnant afin que l’utilisateur puisse les identifier d’une manière ne dépendant pas uniquement de la couleur ? [Y/N]
Lors de la navigation sur la page à l’aide du clavier, il est visuellement apparent lorsqu’un lien a le focus clavier. [Y/N]
Lorsque les liens sont présentés sous forme de liste, séparés de leur contexte environnant, ont-ils tous un texte unique ou un texte alternatif concis mais décrivant distinctement la ressource liée ? [Y/N]
Le texte de tous ou de certains des liens de la page est-il entièrement compréhensible lorsqu’il est lu isolément ? Par exemple, ne pas utiliser « cliquez ici » ou « plus d’informations » [Y/N]
9. Métadonnées
Les métadonnées sont littéralement des « données sur les données » et sont vitales pour qu’une page web soit accessible. La norme HTML définit plusieurs manières pour les auteurs de pages web de fournir ces métadonnées, y compris une série de « balises meta » à juste titre nommées, et diverses autres balises et attributs qui déclarent des éléments tels que la langue, l’encodage des caractères, le titre et l’échelle de la fenêtre d’affichage préférée, qui concernent tous le document de la page web.
Bien que les métadonnées d’une page puissent être fournies à l’aide de différentes balises et attributs, ce qu’elles ont toutes en commun est qu’elles suivent des normes industrielles bien établies et sont donc lisibles par machine.
Accessibilité et SEO
Les avantages de métadonnées précises et bien rédigées s’appliquent à deux types de lisibilité par machine : les robots des moteurs de recherche et les aides techniques. Par exemple, avoir un élément title HTML significatif et bien rédigé pour une page web permettra à Google d’afficher ce titre comme titre cliquable sur sa page de résultats de recherche, pour que le titre soit inclus lors du partage de la page sur les réseaux sociaux, et pour que le titre soit utilisé comme nom du favori dans le navigateur d’un utilisateur.
De plus, ce même titre sera utilisé par les lecteurs d’écran pour annoncer le nom de la page web lorsqu’elle se charge, afin que les utilisateurs qui ne peuvent pas voir l’écran puissent entendre une description précise et concise du sujet de la page.
Validation
Validation du HTML est toujours un bon point de départ pour vérifier les métadonnées sous-jacentes. L’extension Navigateur Web Developer facilite cette vérification, utilisez l’élément de menu : Outils → Valider le HTML. L’évaluation des balises meta est également simplifiée en utilisant cet outil. Activez l’option de menu : Information → Voir la balise Meta Information pour la page web testée.
Finalement, en raison de la nature des métadonnées optimisées pour les machines, vous pourriez avoir besoin d’utiliser l’option afficher la source des outils de développement de votre navigateur pour accéder directement au HTML de la page testée. Recherchez les métadonnées définies sur la balise html ou dans la section head du document.
Déclarer la langue d’une page web
La l’attribut lang peut être ajouté à de nombreux éléments HTML pour indiquer dans quelle langue le texte de cet élément est rédigé. Au minimum, la balise HTML la plus externe doit avoir une langue déclarée. Si des parties de la page sont rédigées dans une langue différente (par exemple lorsqu’une phrase étrangère est citée intentionnellement), cet élément doit avoir une valeur d’attribut lang correcte selon la langue utilisée. Si la langue utilisée ne suit pas l’ordre par défaut de gauche à droite pour la lecture du texte, assurez-vous que l’attribut dir soit également inclus pour spécifier « rtl » par exemple, lors de la citation d’un texte avec un affichage de droite à gauche.
Ne pas définir la langue risque de nuire au référencement de votre page web, de rendre plus difficile la rendu des traductions automatiques de votre contenu par des outils et d’empêcher les lecteurs d’écran d’utiliser avec précision le moteur de prononciation le plus approprié lors de la lecture de votre contenu textuel.
Rendre les titres suffisamment spécifiques pour être distincts
Le titre d’une page web doit être suffisamment spécifique pour permettre de distinguer cette page de n’importe quelle autre page du site. En suivant cette règle, chaque page devrait avoir un titre unique ; sinon, cela implique que le titre choisi n’était pas assez descriptif ou que vous avez plusieurs pages web avec le même contenu.
Ne pas désactiver le « pincement et étirement » pour zoomer
Les appareils à écran tactile prennent souvent en charge des gestes appelés pincement et étirement pour permettre à l’utilisateur de zoomer ou dézoomer sur des zones visibles d’une page web. Il est techniquement possible de définir des métadonnées qui désactiveraient cela (en définissant par exemple maximum-scale=1). Si tel est le cas, cela doit être considéré comme un défaut.
Comment tester cela
Pour chaque page web, effectuez les vérifications suivantes. Indiquez une réponse, « oui » ou « non », à chaque question. Le résultat de réussite est indiqué en MAJUSCULE après chaque question, par ex. [Y/N] où Y est requis pour réussir. Pour chaque résultat échoué, documentez-le comme l’un des éléments suivants :
Comme un défaut
Un défaut, mais avec une explication de pourquoi il devrait être autorisé en tant qu’exception
Un défaut, mais avec une explication de pourquoi il n’est pas applicable
Tests qui pourraient être automatisés :
Voici quelques exemples de questions clés que vous devriez poser :
Le résultat de la page web n’entraîne-t-il aucune erreur de validation HTML lorsqu’elle est vérifiée par un outil de validation HTML W3C? [Y/N]
La page web a-t-elle au moins un attribut de langue global défini qui suit les codes de langue standard pour HTML ? [Y/N]
Tests qui devraient être (au moins partiellement) effectués manuellement :
Voici quelques exemples de questions clés que vous devriez poser :
La page web possède-t-elle un élément title qui décrit avec précision et concision le sujet de la page entière ? [Y/N]
Si la page web est consultée sur un écran tactile qui prend en charge le pincement et l’étirement pour zoomer, est-il possible d’utiliser ces gestes pour zoomer sur la page ? [Y/N]
10. Amélioration progressive et conception responsive
L’amélioration progressive garantit que les utilisateurs peuvent utiliser le plus large éventail possible d’appareils et de logiciels, tout en conservant l’objectif principal de la page web utilisable et compréhensible. Des fonctionnalités supplémentaires peuvent être ajoutées à cette expérience de base au bénéfice des appareils et navigateurs plus performants.
Accessibilité robuste
Appliquer les pratiques d’amélioration progressive rendra votre page web plus résiliente et plus inclusive ; tous les utilisateurs n’auront pas la connexion la plus rapide, l’ordinateur le plus puissant ou les logiciels les plus récents installés, et parfois une fonctionnalité peut être désactivée volontairement par un utilisateur. Vous devez supposer qu’il a une bonne raison pour cette décision, mais tous les utilisateurs n’ont pas le choix.
1. Assurer que le texte soit redimensionnable
Le texte est considéré comme utilisable et lisible lorsqu’il n’est pas rogné et ne chevauche pas d’autres textes ou éléments voisins. Il doit se réajuster au besoin et conserver ses qualités typographiques, en permettant par exemple une hauteur de ligne et des espacements de lettres et de lignes suffisants. Assurez-vous d’utiliser des unités relatives (ems ou rems) pour spécifier les tailles des éléments de la page comme le texte et la mise en page. Cela permettra à la page de s’adapter et de se mettre à l’échelle en fonction de la taille de l’écran ou de son orientation (portrait ou paysage).
2. Assurer que la page soit zoomable
Le zoom de la page augmente la taille apparente de l’ensemble de la page, tandis que le redimensionnement du texte augmente uniquement la taille du texte. Assurez-vous que tout le contenu soit visible et utilisable lorsque la page est zoomée au moins à 200 % de son niveau par défaut.
3. Ajuster les cibles tactiles pour qu’elles soient plus grandes sur les petits écrans
Sur les appareils mobiles à écran tactile, l’utilisateur doit composer à la fois avec un écran physique plus petit et l’utilisation d’un doigt pour toucher des cibles telles que des liens ou des boutons. En tenant compte de cela, la taille physique minimale de la cible tactile doit être d’au moins 7 x 7 mm, ou plus grande si possible. Cela nécessitera sans doute d’augmenter la taille des éléments interactifs sur les petits écrans.
4. Ne pas compter sur un repli noscript
Certaines pages utilisent une balise HTML noscript pour définir un contenu alternatif pour les navigateurs où JavaScript a été désactivé. Des recherches menées par Gov.uk ont montré qu’une portion importante d’utilisateurs incapables d’exécuter JavaScript n’avaient pas JavaScript désactivé. En d’autres termes, JavaScript était activé mais ne s’exécutait pas pour une autre raison. Cela importe car un navigateur n’affichera le contenu noscript que dans le cas spécifique où JavaScript est désactivé. Lorsque JavaScript ne s’exécute pas pour une autre raison, l’utilisateur ne verra pas le contenu nécessitant JavaScript, ni aucun contenu alternatif noscript.
Comment tester cela
Pour chaque page web, effectuez les vérifications suivantes. Indiquez une réponse, « oui » ou « non », à chaque question. Le résultat de réussite est indiqué en MAJUSCULE après chaque question, par ex. [Y/N] où Y est requis pour réussir. Pour chaque résultat échoué, documentez-le comme l’un des éléments suivants :
Comme un défaut
Un défaut, mais avec une explication de pourquoi il devrait être autorisé en tant qu’exception
Un défaut, mais avec une explication de pourquoi il n’est pas applicable
Tests qui pourraient être automatisés :
Voici quelques exemples de questions clés que vous devriez poser :
Toutes les tailles spécifiées dans le design (CSS) de la page sont-elles déclarées uniquement en unités relatives (ems ou rems), évitant l’utilisation d’unités fixes en pixels comme px ? [Y/N]
Tests qui devraient être (au moins partiellement) effectués manuellement :
Voici quelques exemples de questions clés que vous devriez poser :
Lorsque la taille du texte est modifiée à 200 % de sa taille par défaut dans les paramètres du navigateur, tout le texte de la page est-il toujours visible et lisible ? [Y/N]
Lorsque le zoom de la page est augmenté à 200 % dans le navigateur, tout le texte de la page augmente-t-il proportionnellement ? [Y/N]
Dans DevTools, avec le simulateur CPU et réseau du navigateur réglé sur leurs paramètres les plus dégradés, l’objectif principal de la page est-il toujours atteint ? [Y/N]
Dans DevTools, lorsque le simulateur Mode appareil du navigateur est réglé sur l’écran d’appareil le plus petit disponible, l’objectif principal de la page est-il toujours atteint ? [Y/N]
Pratiques de test supplémentaires
Vous pouvez utiliser des outils comme le navigateur Chrome DevToolset appliquer les Mode appareil paramètres pour approximer la page testée sur une gamme d’appareils : des mobiles aux tablettes et aux ordinateurs de bureau. Vous pouvez même simuler des entrées d’appareil pour le tactile, la géolocalisation et l’orientation de l’appareil.
Notez que l’onglet Réseau vous permet de simuler la limitation CPU et réseau.
11. Structure sémantique
Dans toute page web, les titres sont utilisés pour communiquer l’organisation globale et la structure du contenu. Les titres doivent agir comme un plan de haut niveau du contenu de la page, avec un classement logique de chaque sujet et sous-sujet dans un ordre hiérarchique.
Une enquête WebAIM auprès des utilisateurs de lecteurs d’écran a révélé que 67,5 % des répondants sont les plus susceptibles de essayer les titres en premier pour trouver des informations sur une page longue. Et 85,7 % ont déclaré que le fait d’avoir des niveaux de titres appropriés était utile lors de la navigation par titres sur une page web.
Ne pas fournir des titres utilisables et bien organisés empêche les utilisateurs de lecteurs d’écran de comprendre la structure de votre contenu et de pouvoir naviguer efficacement dans votre page. Bien que les titres soient utiles pour tout le monde, les utilisateurs d’aides techniques sont davantage exclus lorsque les titres sont absents ou mal implémentés.
Les titres (Headings)
Le titre h1 doit décrire le sujet de la page web dans son ensemble et serait donc similaire ou identique dans son contenu à l’élément title de la page.
Il est typique que le tout premier titre soit un h1 mais ce n’est pas un défaut qu’un h2 apparaisse en premier, par exemple. Le classement logique et l’ordre des titres sont plus importants que celui qui apparaît en premier, par exemple en veillant à ce qu’aucun h2 ne soit suivi directement d’un h4 (en sautant le h3 attendu). Pour illustrer, si la portion de navigation de la page apparaissait avant le titre affiché de la page, vous pourriez donner au titre de navigation un rang h2 mais ensuite utiliser un h1 plus bas pour indiquer le sujet principal de l’ensemble de la page.
Les lecteurs d’écran ne peuvent pas reconnaître comme vrais titres les éléments qui ne sont que stylés visuellement comme des titres. Utilisez un outil capable de vérifier la source HTML pour trouver les titres réels (ce que font exactement les lecteurs d’écran) et n’utilisez un div que pour ce pour quoi il a été conçu ; ne l’utilisez jamais comme remplacement d’autres balises plus appropriées. Pour une expérience plus authentique de navigation par titres, utilisez le lecteur d’écran Narrator intégré à votre machine Windows pour tester la page.
Cela rendra l'importance du H1 inaccessible aux utilisateurs de lecteurs d'écran.
Comment tester cela
Pour chaque page web, effectuez les vérifications suivantes. Indiquez une réponse, « oui » ou « non », à chaque question. Le résultat de réussite est indiqué en MAJUSCULE après chaque question, par ex. [Y/N] où Y est requis pour réussir. Pour chaque résultat échoué, documentez-le comme l’un des éléments suivants :
Comme un défaut
Un défaut, mais avec une explication de pourquoi il devrait être autorisé en tant qu’exception
Un défaut, mais avec une explication de pourquoi il n’est pas applicable
Tests qui pourraient être automatisés :
Voici quelques exemples de questions clés que vous devriez poser :
Les balises d'en-tête HTML comme h1 et h2 apparaissent-elles dans le HTML de la page ? [O/N]
Les en-têtes sont-ils dans un ordre hiérarchique sans sauter de niveaux d'en-tête (par exemple de h2 à h4) ? [O/N]
Tests qui devraient être (au moins partiellement) effectués manuellement :
Voici quelques exemples de questions clés que vous devriez poser :
Les en-têtes sont-ils affichés dans un style cohérent et reconnaissable qui les rend faciles à identifier par rapport à d'autres contenus non-en-tête ? [O/N]
Le texte de chaque en-tête décrit-il correctement et succinctement le sujet qu'il introduit ? [O/N]
Le h1 principal de la page décrit-il correctement et succinctement le sujet global de la page ? [O/N]
Tous les exemples de texte qui sont visuellement stylisés pour ressembler à des en-têtes sont-ils implémentés avec une balise d'en-tête HTML ? [O/N]
12. Textes de remplacement
Lorsque l'utilisateur n'a pas d'images disponibles dans son navigateur web ou lorsque l'utilisateur ne peut pas voir les images en raison d'un handicap, des textes de remplacement DOIVENT être fournis et agir comme une source d'information et d'utilité comparable afin que l'utilisateur puisse toujours accéder à la page web, la comprendre et l'utiliser pour son objectif principal.
Ce document couvre les techniques et les tests nécessaires pour garantir que les images fonctionnelles telles que les icônes, boutons, contrôles, logos et éléments de marque sont accessibles aux utilisateurs de lecteurs d'écran.
Il couvre également les techniques d'identification des images de contenu ; cependant, les tests ne prouveront pas de manière concluante que toutes les images de contenu sont accessibles. Ne comptez jamais sur un outil automatisé d'IA générant des textes alternatifs. Les images fonctionnelles nécessitent un texte alternatif qui décrit ce qu'elles font ou ce qu'elles représentent plutôt que leur apparence. Une description visuelle d'un bouton ou d'une icône est de peu ou d'aucune utilité pour un utilisateur.
Images purement décoratives
Ces images n'ajoutent aucune signification au contenu de la page web et doivent donc être silencieusement ignorées par les lecteurs d'écran. Par définition, les images décoratives pourraient être supprimées sans affecter la compréhensibilité et l'utilisabilité de la page.
De même, les images d'arrière-plan (définies en CSS) sont automatiquement ignorées par les lecteurs d'écran, elles doivent donc être utilisées uniquement à des fins purement décoratives.
Il existe un cas limite fréquemment abusé où l'élément affichant l'image d'arrière-plan est rédigé pour contenir du texte destiné à être une alternative à l'image, plutôt que défini dans un attribut alt HTML.
Remarquez que le texte alternatif se trouve dans le corps de la page web mais est stylé (via une classe visually-hidden définie par le développeur) pour n'être accessible qu'aux utilisateurs d'un lecteur d'écran. Bien que cela soit techniquement accessible aux utilisateurs de lecteurs d'écran, c'est une approche pire que d'utiliser un élément img avec un attribut alt parce que le texte visuellement masqué ne sera jamais révélé lorsque les images sont désactivées ou si, pour quelque raison que ce soit, elles ne se chargent pas, alors que le texte de l'attribut alt le sera.
Images de contenu
Ces images sont intrinsèques au contenu ou à l'utilité de la page. Utilisez l'attribut alt HTML pour fournir une alternative textuelle pour l'image.
Faites attention à ne pas fournir de contenu redondant ; si le texte utilisé comme alternative à l'image se trouve déjà à proximité dans le texte principal, alors le texte alternatif doit être considéré comme redondant et l'image devrait donc être traitée comme purement décorative. Sinon, l'expérience du lecteur d'écran sera d'entendre le même texte lu à haute voix deux fois.
Lors de l'évaluation de la qualité du texte alternatif, considérez le sens éditorial et le but de l'image dans le contexte de la page environnante. Le texte alternatif doit transmettre de manière concise ce que l'image signifie, pas seulement ce qu'elle montre.
Ne supposez pas que d'autres fonctionnalités HTML destinées à fournir du texte alternatif, comme les attributs longdesc, title ou figcaption, fonctionneront pour les lecteurs d'écran. Il n'est pas prévisible qu'un lecteur d'écran particulier (selon sa configuration) ignore ces attributs ou les lise partiellement ou en totalité.
Si la quantité d'information textuelle requise est importante ou complexe, il est acceptable d'utiliser un attribut ARIA pour marquer un autre élément HTML adjacent comme texte alternatif.
Images dans les contrôles
Lorsque des images servent d'étiquette pour un contrôle – pensez à l'image d'un logo de réseau social qui est le seul contenu d'un lien vers le flux social de l'entreprise – le contrôle doit être accessible aux utilisateurs qui ne peuvent pas voir l'image. Utilisez un texte alternatif qui explique l'action du contrôle. Un lien devrait décrire la destination, par exemple « Page d'accueil », « À propos de nous », etc. Une image dans un bouton devrait utiliser un texte alternatif qui décrit la fonction du bouton, comme « Rechercher », « Se connecter » ou « Envoyer », par exemple.
Graphiques au format SVG
Dans certains cas, l'image affichée peut ne pas être définie à l'aide d'une balise img traditionnelle, mais il doit toujours être possible pour les lecteurs d'écran d'accéder à certains textes alternatifs. L'exemple ci-dessous montre une technique documentée par Léonie Watson qui utilise une combinaison des attributs role et aria-labelledby se référant à un title et un desc pour aider les utilisateurs des technologies d'assistance à accéder au texte décrivant le graphique.
Comment tester cela
Pour chaque page web, effectuez les vérifications suivantes. Indiquez une réponse, « oui » ou « non », à chaque question. Le résultat de réussite est indiqué en MAJUSCULE après chaque question, par ex. [Y/N] où Y est requis pour réussir. Pour chaque résultat échoué, documentez-le comme l’un des éléments suivants :
Comme un défaut
Un défaut, mais avec une explication de pourquoi il devrait être autorisé en tant qu’exception
Un défaut, mais avec une explication de pourquoi il n’est pas applicable
Tests qui pourraient être automatisés :
Voici un exemple de question clé que vous devriez poser :
Chaque image a-t-elle un texte alternatif associé (même si ce texte est une valeur vide) ? [O/N]
Tests qui devraient être (au moins partiellement) effectués manuellement :
Voici quelques exemples de questions clés que vous devriez poser :
Le texte alternatif est-il concis, grammaticalement correct et exempt de fautes d'orthographe ? [O/N]
Si la finalité de l'image est purement décorative, le texte alternatif est-il une valeur vide, comme alt="" ? [O/N]
Le texte alternatif décrit-il l'image d'une manière qui communique un sens comparable aux utilisateurs qui ne peuvent pas voir l'image ? [O/N]
Si l'image apparaît comme la seule étiquette d'un contrôle, d'un lien ou d'un bouton par exemple, est-il possible de comprendre ce que fait le contrôle uniquement à partir du texte alternatif ? [O/N]
Le texte alternatif est-il original / utile et ne répète-t-il pas simplement le texte adjacent du corps de la page ? [O/N]
La langue utilisée pour le texte alternatif correspond-elle à la langue déclarée pour le reste du document ? [O/N]
Si l'image est un logo de marque et n'est pas fonctionnelle, indique-t-elle simplement le nom de la marque ? [O/N]
Si l'image est, par exemple, une icône Diageo, utilise-t-elle le texte associé à cette icône comme indiqué dans le système de conception ? [O/N]
Tests qui pourraient être automatisés :
Voici un exemple de question clé que vous devriez poser :
Le vérificateur automatique de contraste indique-t-il qu'il n'y a pas d'erreurs de contraste ? [O/N]
Tests qui devraient être (au moins partiellement) effectués manuellement :
Voici quelques exemples de questions clés que vous devriez poser :
Avec l'émulation de vision floue activée, est-il possible de lire facilement le texte qui se superpose aux images ou aux dégradés ? [O/N] Remarque : demandez l'avis d'au moins 2 autres personnes impliquées dans ce projet
Émuler la vision floue
Un contraste suffisant est particulièrement important lorsque les utilisateurs peuvent voir votre site avec une vision floue, en cas d'éblouissement intense ou lorsqu'ils sont distraits. Activer l'émulation de vision floue est une excellente façon de tester que le texte est suffisamment lisible.
Sur le navigateur Chrome, cette émulation est disponible en suivant les étapes ci-dessous :
Tapez les touches : commande + maj + p puis entrez (tapez) le texte « render » pour voir toutes les options de rendu disponibles
Faites défiler jusqu'au menu déroulant « Emulate vision deficiencies »
Puis sélectionnez l'option « Blurred vision »
Pour vérifier le contraste et la lisibilité pour les utilisateurs qui peuvent avoir des déficiences de perception des couleurs, choisissez l'option « Achromatopsia » (suppression de toutes les couleurs).
Informations supplémentaires
Désactiver les images (option également disponible via l'extension de navigateur Web Developer) est un moyen efficace de s'assurer que le texte conçu pour apparaître superposé à une image restera lisible si cette image venait à ne pas s'afficher. Définir une couleur d'arrière-plan de secours sur de tels éléments ayant des images de fond est important pour gérer ces cas.
14. Utilisation de Windows Narrator
Narrator est un lecteur d'écran intégré à tous les systèmes d'exploitation Windows. Ce guide est conçu pour aider les développeurs et testeurs qui découvrent Narrator à apprendre les commandes de base pour tester leurs pages web.
Narrator fonctionne actuellement mieux avec le navigateur MS Edge, mais il prend également en charge Chrome et Firefox.
Commencer
Pour démarrer ou arrêter Narrator, appuyez sur la touche Windows + Ctrl + Entrée. Cela ouvrira une fenêtre avec des options pour en savoir plus sur Narrator et configurer vos paramètres. Si vous découvrez Narrator, regardez cette vidéo pour un tutoriel d'introduction rapide.
Choses utiles à retenir :
Appuyez sur la touche Windows + Ctrl + N pour accéder aux paramètres. Ici vous pouvez modifier la voix, le volume relatif et la vitesse.
Les touches Caps Lock et Insert peuvent être utilisées comme touche « modificateur » de Narrator utilisée dans de nombreuses commandes — nous l'appellerons la touche Narrator.
Ctrl + Accueil : vous amènera en haut de la page
Ctrl + R : actualisera la page (utile si vous êtes perdu ou si Narrator ne se comporte pas comme prévu)
Pour une liste complète des raccourcis de Narrator https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
Écouter le contenu web
Il existe plusieurs façons d'utiliser Narrator pour accéder au contenu web. Voici les touches les plus utiles :
Ctrl + ↑/↓ : Lire la ligne précédente/suivante
↑/↓ : Lire le paragraphe ou l'élément précédent/suivant
Narrator + Tab : Relire l'élément courant
Narrator + +/- : Augmenter/diminuer la vitesse de parole
Ctrl : Arrêter la lecture
Vous voudrez peut-être vous entraîner à lire différentes pages avant de commencer les tests.
Tester la navigation sur la page
La plupart des utilisateurs voyants survolent et prennent une photo visuelle d'une page web pour se faire une idée de l'emplacement des éléments, mais si vous ne pouvez pas faire cela, ce que la page contient en termes d'en-têtes, d'images, d'éléments de formulaire, de messages, etc. est inconnu. Si une page web est bien structurée et a suivi les Guides d'accessibilité Colt, un utilisateur devrait pouvoir naviguer sur la page en utilisant les en-têtes, les repères, les liens ou les listes, etc.
Plusieurs raccourcis à une touche permettent de naviguer rapidement par éléments courants de la page. Vérifiez qu'ils fonctionnent et que vous pouvez accéder à chaque type d'élément avec succès.
Ceux-ci incluent :
H : En-têtes
1 - 6 : En-tête 1, en-tête 2, etc.
D : Repères
Tab : Liens et contrôles de formulaire
F : Contrôles de formulaire
B : Boutons
K : Liens
L : Listes
I : Éléments d'une liste
T : Tableaux
Maj + n'importe quelle touche de navigation inverse l'action.
Ouvrez la boîte de dialogue Rechercher et essayez de rechercher différents éléments
Narrator + Ctrl + F : Ouvrir la boîte de dialogue Rechercher
Narrator + F3 : Parcourir les résultats de recherche de Narrator (ajoutez Maj pour revenir en arrière)
Conseils d'accessibilité pour la navigation
Tester les formulaires
Lorsqu'un contrôle de formulaire reçoit le focus clavier, Narrator lit l'étiquette (si elle existe), puis annonce le type de contrôle de formulaire. Si un groupe de contrôles de formulaire — typiquement des groupes de cases à cocher ou de boutons radio — est contenu dans un fieldset avec une legend, Narrator présente les éléments du fieldset comme un groupe et lit la legend lorsque vous naviguez pour la première fois dans ce groupe.
Utilisez les commandes clavier suivantes du navigateur pour interagir avec les contrôles de formulaire et tester s'ils peuvent être atteints au clavier, et si leurs étiquettes sont à la fois uniques et descriptives.
Tab et Maj + Tab : Naviguer entre les contrôles de formulaire
Espace pour sélectionner et désélectionner les cases à cocher
↑/↓ : Sélectionner dans un groupe de boutons radio
Espace, puis ↑/↓ ou la première lettre d'une option : Développer puis sélectionner une option dans une liste déroulante combo
Entrée : Soumettre un formulaire
Conseils d'accessibilité pour les formulaires
Tester les images
Les images peuvent être fonctionnelles, de contenu ou décoratives. Les Stream Graphics sont principalement esthétiques et seraient donc classées comme décoratives. Cela signifie qu'elles devraient être muettes pour les lecteurs d'écran. Si un texte alternatif n'est pas défini, Narrator dira généralement « image » ou « graphique non étiqueté » (la plupart des autres lecteurs d'écran ignorent ces libellés). Le texte alternatif d'une image fonctionnelle ou de contenu sera lu par Narrator et devrait décrire l'objectif de l'utilisation de l'image.
Exemples :
Logos Colt devraient simplement indiquer le nom de la marque, « Colt Technology Services »
Logos co-marqués devraient indiquer les deux noms de marque, « Colt Technology Services en partenariat avec Cisco »
Icônes Colt ou Visuels ESG, devraient simplement indiquer la finalité de ce que l'image représente.
Les images qui sont des liens, si le logo Colt est également un lien vers la page d'accueil, devraient inclure à la fois le nom de la marque et la destination, « page d'accueil Colt ».
Conseils d'accessibilité pour les images
Tester les tableaux de données
Pour naviguer vers le tableau suivant d'une page, appuyez sur la touche T. Pour naviguer à l'intérieur d'un tableau de données, maintenez Ctrl + Alt enfoncés et utilisez ↑/↓/←/→ pour vous déplacer de cellule en cellule. Si un tableau a des en-têtes de lignes et de colonnes appropriés, ils seront lus automatiquement lors de la navigation.
Assurez-vous que les lignes et les colonnes ont des étiquettes significatives.
Pour une liste complète des raccourcis de Narrator : https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
15. Téléchargements
Pour faciliter les tests des développeurs concernant les problèmes d'accessibilité potentiels, nous avons créé une Liste de contrôle d'accessibilité manuelle pour structurer vos tests.
Mis à jour
Ce contenu vous a-t-il été utile ?