Comment mener vous-même un premier audit d'accessibilité

En bref : lancez un scanner automatisé (axe, WAVE, Lighthouse), qui détecte environ un quart à un tiers des problèmes WCAG, puis faites ce qu’il ne peut pas faire : naviguez au clavier uniquement, effectuez un contrôle ponctuel avec un lecteur d’écran, vérifiez que le contraste atteint 4,5:1 pour le texte et 3:1 pour le texte large et les éléments d’interface, et lisez les textes alternatifs et les libellés comme le ferait un inconnu. Un vrai premier passage, pas un certificat.

Laissez-moi vous guider comme je le ferais si nous étions assis devant votre écran, ensemble, car un après-midi passé à faire cela correctement vous apprend plus que n’importe quel rapport que je pourrais vous remettre.

Que vérifie réellement un premier audit d’accessibilité ?

Un premier audit comporte deux moitiés, et la plupart des gens ne font que la première. La première moitié est automatisée : un scanner signale ce qu’une machine peut vérifier avec certitude, comme un attribut alt manquant. La seconde moitié est manuelle : une personne vérifie ce qui exige un jugement, comme la question de savoir si ce texte alt décrit réellement l’image, ou si l’ordre de tabulation a un sens pour quelqu’un qui ne peut pas voir la page.

Sautez la seconde moitié, et vous n’avez pas audité votre site. Vous avez lancé un correcteur orthographique et appelé cela une relecture.

Pourquoi les scanners automatisés ne détectent-ils qu’un quart à un tiers de vos problèmes ?

Voici le chiffre qui devrait recalibrer le réconfort que vous tirez d’une coche verte. Deque, l’entreprise à l’origine du moteur open source axe-core qui alimente la plupart des scanners, affirme sans détour que le secteur de l’accessibilité considère depuis longtemps que la couverture automatisée se situe autour de 20 à 30 % (Deque, à revérifier). Un examen distinct portant sur les critères eux-mêmes aboutit à peu près au même constat : seuls environ 30 % des critères de succès du WCAG 2.1 niveau AA, soit environ 15 à 16 d’entre eux, peuvent réellement être testés par une machine (TestParty, à revérifier). Tout le reste nécessite une personne.

Petite mise en garde pour lire le marketing des outils comme un professionnel : une étude plus récente menée par Deque elle-même, portant sur plus de 2 000 audits et près de 300 000 problèmes, a constaté que les tests automatisés détectent 57 % des problèmes lorsqu’on compte en volume plutôt que par critère (Deque, à revérifier). Les deux chiffres sont vrais, ils mesurent simplement des choses différentes. Comptez par critère, et l’automatisation couvre moins d’un tiers du référentiel. Comptez selon la fréquence à laquelle chaque problème apparaît sur une page, et le résultat semble meilleur, car une poignée de problèmes à haute fréquence, le contraste en particulier, gonflent le total. Dans un cas comme dans l’autre, une part importante des problèmes réels a besoin d’une personne pour être repérée.

Rien de tout cela n’est une critique d’axe, de WAVE ou de Lighthouse. Lancez-en un dès aujourd’hui. Axe DevTools et WAVE sont des extensions de navigateur gratuites, Lighthouse est intégré aux DevTools de Chrome, et chacun vous livre en quelques minutes des défauts corrigeables : libellés manquants, ordre des titres incorrect, échecs de contraste, ID dupliqués. Ce sont les dix minutes de progrès en accessibilité les plus rapides que vous obtiendrez de toute la semaine. Ne confondez simplement pas une analyse propre avec un site propre. Aucun des trois ne peut vous dire si votre texte alternatif a du sens, ou si un visiteur naviguant au seul clavier peut aller au bout de votre tunnel d’achat (David Mello, à revérifier). C’est la moitié manuelle, et c’est là que vit le véritable audit.

Que dois-je tester à la main, et dans quel ordre ?

Cinq contrôles, dans l’ordre où je les mène. Chacun prend quinze à trente minutes sur une page type, et ensemble, ils révèlent davantage de défauts réels qu’un scanner à lui seul.

Pouvez-vous accéder à tout et tout actionner avec le seul clavier ?

Rangez la souris. Utilisez Tab pour avancer, Maj+Tab pour reculer, Entrée ou Espace pour activer, et les touches fléchées à l’intérieur des menus et des composants personnalisés. Posez-vous trois questions en chemin. Pouvez-vous atteindre chaque lien, chaque bouton et chaque champ de formulaire. Y a-t-il toujours un indicateur de focus visible montrant exactement où vous vous trouvez. Et pouvez-vous ressortir de tout ce que vous avez ouvert, une fenêtre modale, un menu, un sélecteur de date, sans rester piégé. Un piège du clavier, où le focus entre dans un composant et ne peut plus en sortir, est l’un des défauts les plus invalidants qu’un site puisse avoir : il ne gêne pas un utilisateur du clavier, il l’arrête net.

Que donne votre page à l’oreille, avec un lecteur d’écran ?

Vous n’avez pas besoin de devenir un expert. Vous avez besoin de trente minutes honnêtes avec l’outil que vos utilisateurs sont le plus susceptibles d’utiliser. NVDA est gratuit et open source sous Windows, et VoiceOver est intégré à chaque Mac et chaque iPhone, de sorte que ni l’un ni l’autre ne vous coûte quoi que ce soit à essayer. Cette couverture compte : l’enquête la plus récente de WebAIM, la Screen Reader User Survey, a révélé que NVDA et JAWS arrivent presque à égalité en tête des lecteurs d’écran de bureau utilisés à titre principal, à 38 % et 41 %, NVDA passant en tête dès que l’on compte tous ceux qui l’utilisent, quel que soit leur lecteur principal (WebAIM, à revérifier). Activez-en un, fermez les yeux, et essayez d’accomplir la tâche la plus importante de votre site : soumettre un formulaire, lire un article du début à la fin. Notez chaque moment de confusion. Cette confusion est votre liste de corrections.

Votre texte et vos contrôles respectent-ils les seuils minimums de contraste ?

C’est le seul contrôle qui repose sur un chiffre précis, pas sur un jugement. Le critère Contraste (minimum) du WCAG exige au moins 4,5:1 pour le texte normal par rapport à son arrière-plan, un seuil qui descend à 3:1 pour le texte large, soit environ 18 points, ou 14 points en gras, et plus (W3C). Un critère apparenté, Contraste du contenu non textuel, étend ce même minimum de 3:1 aux parties visuelles des composants d’interface qu’un utilisateur doit identifier et actionner : bordures de champs, boutons à icône, états des interrupteurs (W3C). Vérifiez ce point avec soin, car c’est de loin l’échec le plus courant sur le web. La dernière analyse de WebAIM sur le million de pages d’accueil les plus importantes a trouvé du texte à faible contraste sur 83,9 % d’entre elles, avec une moyenne de 34 occurrences par page (WebAIM, à revérifier). N’importe quelle pipette à couleurs de navigateur ou extension de contraste vous donne le rapport en quelques secondes. Vérifiez le texte courant, les liens, le texte de substitution (placeholder) et les bordures de boutons, pas seulement le titre.

Votre texte alternatif aurait-il un sens lu à voix haute, sans l’image sous les yeux ?

Cachez l’image et lisez uniquement le texte alternatif à voix haute. Transmet-il la même information qu’un visiteur voyant obtient. « Photo d’un ordinateur portable » ne dit rien à un utilisateur de lecteur d’écran. « Tableau de bord montrant un chiffre d’affaires en hausse de 12 % sur un trimestre » fait le travail. Les images décoratives doivent avoir un texte alternatif vide (alt="") afin que les lecteurs d’écran les ignorent silencieusement au lieu d’annoncer un nom de fichier. Cela compte plus que ne le pense la plupart des propriétaires de sites : un texte alternatif manquant ou inutile est apparu sur 53,1 % des pages d’accueil dans cette même analyse de WebAIM, et près de la moitié d’entre elles étaient des images liées, ce qui interrompt entièrement la navigation pour un utilisateur de lecteur d’écran, pas seulement sa compréhension (WebAIM, à revérifier).

Vos formulaires libellent-ils tout, et expliquent-ils les erreurs avec des mots ?

Placez-vous dans chaque champ avec uniquement Tab et un lecteur d’écran actif. Annonce-t-il un vrai libellé, « Adresse e-mail », et non le silence, ni un placeholder qui disparaît dès que vous tapez. Soumettez le formulaire avec une erreur volontaire. L’erreur indique-t-elle ce qui ne va pas et comment le corriger, en texte, pas seulement par une bordure rouge, qui ne communique rien à quelqu’un qui ne peut voir ni le rouge ni la bordure. Ce n’est pas un détail mineur : l’absence de libellés de champ de formulaire est apparue sur 51 % des pages d’accueil (WebAIM, à revérifier), ce qui signifie qu’un site sur deux demande à la moitié de ses visiteurs de deviner.

Qu’a ajouté le WCAG 2.2 dont la plupart des propriétaires de sites n’ont jamais entendu parler ?

Le WCAG 2.2 a ajouté neuf nouveaux critères de succès par rapport au 2.1, et quatre d’entre eux sont ceux que je vois constamment oubliés, parce que la plupart des listes de contrôle existantes ont été rédigées avant la sortie du 2.2 et n’ont jamais été mises à jour (W3C).

Taille de la cible, 2.5.8. Les cibles interactives, boutons, liens, icônes que vous touchez, doivent mesurer au moins 24 par 24 pixels CSS, ou disposer d’assez d’espace autour d’elles pour qu’un cercle de 24 pixels centré sur chacune ne touche pas sa voisine (W3C). Cela existe pour quiconque a une motricité fine limitée, et pour chacun d’entre nous quand nous tenons un téléphone dans un bus en mouvement.

Focus non masqué, 2.4.11. Lorsqu’un élément reçoit le focus clavier, un en-tête collant, une bannière de cookies ou un widget de chat ne doit pas le cacher entièrement. Si vous ne pouvez pas voir où se trouve le focus, vous ne pouvez pas utiliser le clavier en toute confiance, et les en-têtes collants sont partout aujourd’hui.

Saisie redondante, 3.3.7. Si un utilisateur vous a déjà fourni une information plus tôt dans un parcours, ne le forcez pas à la retaper dans la même session, à moins de la préremplir automatiquement ou de la proposer comme option sélectionnable. Les tunnels d’achat en plusieurs étapes et les longs formulaires de demande en sont les principaux responsables.

Authentification accessible, 3.3.8. Se connecter ne devrait pas exiger de résoudre une énigme, de retranscrire une image déformée, ou de se souvenir de quelque chose sans aucune alternative. Les gestionnaires de mots de passe, l’option « envoyez-moi un lien par e-mail », et la biométrie satisfont tous à cette exigence. Un CAPTCHA sans alternative, non.

Aucun de ces quatre critères n’apparaît de façon fiable dans une analyse automatisée. Les quatre sont des points que vous vérifiez vous-même, à la main, en moins de dix minutes par page.

Vous avez trouvé vingt problèmes. Dans quel ordre les corrigez-vous ?

Ne travaillez pas de haut en bas. Travaillez selon le nombre de personnes qu’une correction aide, rapporté au temps qu’elle prend.

Commencez par la poignée de types d’erreurs qui reviennent constamment, car corriger un même schéma une seule fois le résout en général partout où il se répète. Les recherches de WebAIM ont montré que seulement six catégories d’erreurs, le texte à faible contraste, le texte alternatif manquant, les libellés de formulaire manquants, les liens vides, les boutons vides et la langue du document manquante, représentent 96 % de toutes les erreurs détectées sur le million de pages d’accueil les plus importantes (WebAIM, à revérifier). Ce sont rarement six chantiers distincts. C’est généralement un jeton de design, un composant, et une correction de gabarit chacun, qui se répercutent sur tout votre site dès l’instant où vous les déployez.

Une façon simple de classer ce que vous avez trouvé :

1. Bloque complètement une tâche. Un piège du clavier, un champ obligatoire sans libellé, une connexion qu’un utilisateur de lecteur d’écran ne peut pas mener à bien. Corrigez-les en premier, toujours.
2. Touche la plupart des pages à partir d’une seule cause racine. Un jeton de contraste global, un composant de bouton, un gabarit d’en-tête. Un seul changement résout des dizaines d’occurrences.
3. Touche une seule page ou un parcours rare. Une légende d’image isolée, une ancienne page d’atterrissage vers laquelle personne ne pointe de lien. Corrigez-la la prochaine fois que vous retouchez cette page.
4. Finition cosmétique ou de niveau AAA. Une priorité réellement plus basse, qu’il est parfaitement acceptable de placer derrière les trois premières.

Ce qu’un premier audit n’est pas

Je veux être franc avec vous ici, car survendre est la seule chose que je ne ferai jamais sur ce site. Un premier auto-audit n’est pas une certification. Ce n’est pas un VPAT (Voluntary Product Accessibility Template), ce n’est pas une défense juridique, et cela ne remplacera jamais des tests menés avec de vraies personnes en situation de handicap, qui trouvent des choses qu’aucune liste de contrôle ne prédit, parce qu’elles utilisent des technologies d’assistance dans des conditions réelles que vous et moi ne pouvons pas entièrement simuler derrière un bureau. Les propres recommandations du W3C sur l’évaluation de l’accessibilité le disent clairement : aucun outil, à lui seul, ne peut déterminer si un site respecte les normes d’accessibilité, et une évaluation humaine avertie est nécessaire pour trancher (W3C). Un après-midi consacré aux contrôles ci-dessus vous donne un premier passage réel et honnête : les problèmes les plus criants trouvés et corrigés, et une idée plus claire de l’endroit où se situent probablement les lacunes plus profondes. Cela vaut la peine d’être fait dès aujourd’hui. Ce n’est pas la ligne d’arrivée.

Le passage que j’effectue sur chaque page

La routine, pour que vous puissiez vous en inspirer :

• Lancez une analyse automatisée. Corrigez chaque problème signalé : cela ne coûte rien.
• Débranchez la souris. Naviguez au Tab et notez tout ce qui est inaccessible, invisible ou piégé.
• Activez NVDA ou VoiceOver et accomplissez votre tâche la plus importante les yeux fermés.
• Vérifiez le contraste du texte courant, des liens, des placeholders et des bordures de boutons.
• Lisez vos textes alternatifs et vos libellés de formulaire à voix haute, comme si vous découvriez la page pour la première fois.
• Vérifiez à la main les quatre ajouts du WCAG 2.2 : taille de la cible, focus masqué, saisie redondante, authentification accessible.
• Classez ce que vous avez trouvé selon le nombre de personnes que cela bloque, pas selon la page où cela se trouve.
• Corrigez d’abord les schémas qui causent le plus de dégâts, puis descendez la liste.

Faites-le une fois, correctement, et vous ne lirez plus jamais votre propre site de la même façon.