Analyse rapide d’accessibilité
La plupart des défauts d’accessibilité sont de petites choses oubliées dans le HTML, comme une image sans description ou un champ sans nom. Cette analyse récupère une page, les trouve et vous dit quels éléments corriger.
Tout ce qui est sur une page a besoin d’un nom
Quand vous regardez une page, la mise en page fait beaucoup de travail sans un mot. Une icône de loupe à côté d’une zone veut dire « cherchez ici ». Un grand texte en gras veut dire « une nouvelle section commence ». Rien de cela n’atteint une personne qui utilise un lecteur d’écran, une plage braille ou la commande vocale. Son logiciel ne voit pas la mise en page. Il lit le HTML et attend de chaque élément deux choses : ce qu’il est et comment il s’appelle.
Une balise <img> répond par son attribut alt, un champ de formulaire par son <label>, une section par son titre. Quand la réponse manque, le logiciel dit « image », « zone de texte » ou « lien » et passe à la suite, ce qui n’aide personne. Les Web Content Accessibility Guidelines (WCAG) transforment cette idée en règles testables et une bonne part d’entre elles peuvent être vérifiées par un programme.
Ce que l’analyse teste et ce que coûte chaque constat
La page part de 100 points. Chaque constat en retire quelques-uns et un problème qui se répète coûte plus, jusqu’à un plafond.
| Constat | Points retirés |
|---|---|
Pas de lang sur <html> | 10 |
Zoom bloqué (user-scalable=no, ou maximum-scale inférieur à 2) | 10 |
<title> vide ou manquant | 6 |
Images sans attribut alt | 4 + 2 par image, 20 au maximum |
| Champs de formulaire sans étiquette | 5 + 3 par champ, 20 au maximum |
| Liens ou boutons sans nom | 4 + 2 chacun, 20 au maximum |
| Aucun titre du tout | 8 |
Pas de <h1> ; niveaux de titre sautés | 4 ; 2 + 1 par saut, 6 au maximum |
| Texte de lien vague (« cliquez ici », « en savoir plus ») | 2 + 1 par lien, 8 au maximum |
| Texte stylé en ligne avec un contraste inférieur à 4,5:1 | 3 + 2 chacun, 10 au maximum |
<iframe> sans title | 2 + 1 chacun, 6 au maximum |
Valeurs id en double | 1 + 1 chacune, 5 au maximum |
| Audio ou vidéo qui démarre seul avec du son | 4 |
Pas de région <main> ; un tabindex supérieur à 0 | 3 chacun |
L’analyse ignore les éléments cachés avec hidden, aria-hidden="true" ou un display:none en ligne et les images marquées role="presentation".
Lire la note
Les points qui restent deviennent une lettre : A à partir de 90, B à partir de 80, C à partir de 65, D à partir de 50, F en dessous. Les constats rouges sont des obstacles, du genre qui empêchent quelqu’un de terminer une tâche. Les constats ambre ralentissent les gens sans les arrêter. Sous chacun, vous verrez jusqu’à huit des éléments concernés, montrés sous forme de balise avec son chemin de fichier, son nom de champ, son id ou sa classe, pour que vous puissiez les chercher dans vos gabarits.
Un A veut dire que l’analyse n’a trouvé aucun des problèmes qu’elle sait détecter. Les tests automatiques repèrent environ un tiers des vrais problèmes d’accessibilité. Savoir si votre texte alternatif est exact, si l’ordre de lecture a du sens, comment un menu sur mesure se comporte au clavier : cela demande un jugement humain.
Les correctifs des constats les plus fréquents
- Image sans texte alternatif
- Dites ce que l’image apprend à un lecteur qui voit :
<img src="team.jpg" alt="Five engineers around a whiteboard">. Pour un ornement décoratif, écrivezalt="". La valeur vide dit aux logiciels d’assistance d’ignorer l’image, ce qui n’est pas la même chose que d’omettre l’attribut. - Champ sans étiquette
<label for="email">Email</label> <input id="email" type="email">. Un texte indicatif (placeholder) ne compte pas, puisqu’il disparaît à la première frappe.- Lien ou bouton avec une icône seulement
<button aria-label="Open menu">…</button>, ou mettez unaltsur l’image de l’icône à l’intérieur.- Niveau de titre sauté
- Choisissez le niveau d’après le plan (
h2pour une section,h3à l’intérieur) et réglez la taille en CSS. - Zoom bloqué
- Réduisez la balise viewport à
<meta name="viewport" content="width=device-width, initial-scale=1">.
Ce que cette analyse ne voit pas
Notre serveur lit le HTML qu’il reçoit et n’exécute pas JavaScript, de sorte que tout ce qu’un framework injecte après le chargement n’est pas examiné. Il ne télécharge pas non plus vos feuilles de style. C’est pourquoi le contraste n’est mesuré que là où la couleur du texte et celle du fond sont toutes deux écrites dans un attribut style. Pour tout le reste, testez vos couleurs dans le calculateur de rapport de contraste. Pour aller plus loin sur une page, écoutez-la dans l’aperçu du lecteur d’écran et suivez son ordre de tabulation.
Questions fréquentes
Une note parfaite veut-elle dire que mon site est conforme aux WCAG ?
Non. Cela veut dire que cette page réussit les contrôles qu’un programme peut faire sur du HTML brut. La conformité aux WCAG 2.2 niveau AA demande aussi des tests manuels au clavier et avec un lecteur d’écran, sur chaque gabarit du site.
Quelle est la différence entre un alt vide et un alt manquant ?
alt="" dit volontairement que l’image est décorative et les lecteurs d’écran la sautent sans un bruit. Sans aucun attribut alt, beaucoup de lecteurs d’écran se rabattent sur la lecture du nom de fichier, quelque chose comme « IMG underscore 4521 dot jpg ».
Pourquoi un texte indicatif n’est-il pas accepté comme étiquette ?
Un texte indicatif disparaît dès que le visiteur tape, si bien que quiconque est interrompu ou utilise un agrandissement perd de vue ce que le champ demandait. Certains lecteurs d’écran ne l’annoncent pas non plus. Un <label> visible reste en place et agrandit la zone de clic.
L’analyse ne signale aucun problème de contraste. Mes couleurs sont-elles bonnes ?
Pas forcément. L’analyse ne lit pas les couleurs définies dans les feuilles de style, seulement celles posées directement dans des attributs style="…". Vérifiez à la main les couleurs de votre texte principal et de vos boutons dans le calculateur de rapport de contraste.
Ma page est construite avec React ou Vue. Le résultat est-il fiable ?
Seulement si le HTML est produit côté serveur. Si le serveur envoie un document presque vide et que le navigateur construit la page avec JavaScript, l’analyse voit le document vide et ne signale presque rien.