Accessibilité WCAG d’un site indépendant : contrastes, navigation au clavier, lecteurs d’écran — la liste des correctifs
1. Pourquoi un site B2B indépendant doit aussi être accessible
Beaucoup pensent que l’accessibilité est un projet caritatif pour les personnes en situation de handicap, sans rapport avec un site B2B qui vend du matériel et génère des demandes de devis. Ce jugement n’est vrai qu’à moitié. Trois moteurs réels : dans les questionnaires fournisseurs des grands comptes européens et américains, « votre site est-il conforme WCAG » est déjà une question systématique ; certains États américains et l’Union européenne imposent des exigences d’accessibilité pour les marchés publics ; plus concret encore, un HTML sémantique est tout aussi bien compris par les moteurs de recherche et les robots d’IA.
Le jugement contre-intuitif est ici :Rendre un site accessible n’est pas un coût supplémentaire : c’est le même code qui sert votre SEO, vos données structurées et votre citation par les IA. Remplacer les faux boutons en div par de vrais button, ajouter des alt aux images, remettre de l’ordre dans la hiérarchie des tailles de police : indispensables pour les lecteurs d’écran, ces gestes aident aussi Google et les grands modèles à comprendre la structure de la page. Pour délimiter le périmètre, voir Accessibilité du site (WCAG) ce qui est obligatoire et ce qui peut attendre.
| Catégorie de correctif | Exigence WCAG 2.2 AA | Erreur courante | Coût de correction |
|---|---|---|---|
| Contraste du texte | Texte courant ≥ 4,5:1, grand texte ≥ 3:1 | Gris clair sur fond blanc, environ 2,5:1 | Une demi-journée |
| Focus clavier | Tous les éléments interactifs atteignables au Tab, focus visible | outline:none supprime l’anneau de focus | Un jour |
| Balise alt des images | Alt descriptif pour les infographies, alt vide pour le décoratif | Alt systématiquement « image » ou vide | Deux jours |
| Hiérarchie des titres | h1 → h2 → h3 sans saut de niveau | Passage direct de h2 à h4 | Une demi-journée |
| Étiquettes de formulaire | Chaque champ a un label visible | Seul le placeholder sert d’étiquette | Un jour |
2. Première étape : régler le contraste à 4,5:1
Le contraste est le critère le plus facile à mesurer et à vérifier soi-même. La règle est simple : 3:1 pour les grands textes (18 pt, soit environ 24 px, ou 14 pt en gras, soit environ 18,66 px) ; 4,5:1 pour tout le reste — corps de texte, petits caractères, libellés de boutons. Le piège le plus fréquent sur les sites e-commerce, c’est le petit texte gris sur fond clair : pour faire “haut de gamme”, le designer passe le corps de texte en #888 sur du #f5f5f5, et le contraste réel tombe à peine à 2 et quelques pour un.
Pas besoin d’acheter un outil pour vérifier : installez l’extension axe ou WAVE dans votre navigateur, un scan en un clic signale tous les éléments dont le contraste est insuffisant. Pour corriger, ne refaites pas tout le design : contentez-vous de foncer les quelques couleurs concernées. Passer le corps de texte de #888 à #555 suffit généralement à atteindre 4,5:1, pour un coût quasi nul. C’est la même logique que l’optimisation des performances, où l’on commence par les gains faciles, voir Core Web Vitals et sa méthode de tri par rendement.
| Type d’élément | Exigence de contraste AA | Méthode de diagnostic | Corrections courantes |
|---|---|---|---|
| Petit texte courant | ≥ 4.5:1 | Signalé automatiquement par axe/WAVE | Foncer la couleur du texte d’un cran |
| Grands titres | ≥ 3:1 | Idem | Généralement conforme |
| Texte des boutons | ≥ 4.5:1 | À tester avec la couleur de fond | Foncer le texte ou le fond du bouton |
| Bordures/icônes d’interface | ≥ 3:1 | Contraste avec le fond adjacent | Foncer la couleur de bordure |
| Texte à l’état désactivé | Exempté | Vérifier qu’il est bien désactivé | Pas de correction obligatoire |
Troisième point : rangez la souris et parcourez tout le site au clavier
Une seule méthode pour valider la navigation au clavier : débranchez la souris et parcourez de bout en bout, avec Tab, Shift+Tab, Entrée et Échap uniquement, ces quatre pages — accueil, liste de produits, fiche produit, formulaire de contact. Vous repérerez aussitôt trois types de problèmes : l’anneau de focus supprimé par un outline: none en CSS, si bien qu’on ne voit plus où l’on se trouve ; les menus déroulants écrits en JS pur, inaccessibles au clavier ; les fenêtres modales qui emprisonnent le focus sans le libérer — ce qu’on appelle un piège au clavier.
Cas 1 : un “faux bouton” écrit avec un div. Pour aller plus vite, le designer a mis un div avec un événement de clic : l’utilisateur au clavier ne peut ni l’atteindre avec Tab ni le déclencher avec Entrée. La solution n’est pas d’ajouter du JS, mais de le remplacer par un button natif, qui gère le clavier par nature et possède son propre nom accessible.Cas 2 : l’anneau de focus invisible. Beaucoup de styles globaux contiennent *:focus { outline: none }, ce qui supprime le contour de focus par défaut du navigateur. La bonne pratique est de conserver un style de focus bien visible, par exemple un contour bleu de 2 px, plutôt que de le supprimer purement et simplement. Pour savoir comment articuler sémantique et données structurées, voir Données structurées Schema.
| Point de contrôle clavier | Critère de conformité | Signe d’échec | Méthode de correction |
|---|---|---|---|
| Ordre de tabulation | Correspond à l’ordre de lecture visuel | Saute dans tous les sens, boutons inatteignables | Réordonner le DOM ou ajuster tabindex |
| Focus visible | L’élément actif a un contour net | outline supprimé, invisible | Ajouter un style :focus-visible |
| Menu déroulant | Déroulant ouvrable aux flèches | Utilisable seulement à la souris | Passer à un select natif ou ajouter la gestion clavier |
| Fenêtre modale | Le focus entre dans la modale, Échap la ferme | Le focus reste piégé à l’intérieur | Implémenter le piège à focus et sa libération |
| Lien d’évitement | Lien “aller au contenu principal” sur les pages longues | Chaque fois, des dizaines de tabulations dans la navigation | Ajouter un lien « Aller au contenu » |
4. Troisième point : rendre le contenu lisible par les lecteurs d’écran
Les utilisateurs de lecteurs d’écran entendent la « structure sémantique » du HTML, pas le design que vous voyez. Trois éléments déterminent la qualité de cette structure : le texte alternatif, la hiérarchie des titres et les libellés ARIA. Le texte alternatif ne sert pas à « donner un nom de fichier à une image », mais à résumer en une phrase l’information qu’elle transmet. Pour une image décorative de séparation, écrivez alt=”” pour que le lecteur d’écran l’ignore complètement, au lieu de lire le mot « bouton ».
La hiérarchie des titres est un autre point critique. Pour afficher un titre en grand, beaucoup de pages utilisent directement des balises h4, voire p, avec du CSS. Résultat : le lecteur d’écran passe de h2 à h4 sans transition, et l’utilisateur ne comprend plus la structure du document. La règle est mécanique : un seul h1 par page, des h2 de même niveau en dessous, des h3 pour les sous-sections, sans sauter de niveau. Les boutons icônes (loupe, menu hamburger) n’ont pas de texte : ils doivent avoir un aria-label, sinon le lecteur d’écran ne lit que « bouton » et l’utilisateur ignore ce que fait le clic. Pour savoir quelles formulations sont adaptées aux acheteurs étrangers, voir guide de ton pour les textes du site.
| Point de contrôle | Bonne pratique | Erreur fréquente | Vérification par outil |
|---|---|---|---|
| alt d’une infographie | Décrire la conclusion clé de l’image | alt=”photo produit”, aucune information | Ce que le lecteur d’écran entend réellement |
| alt d’une image décorative | alt=”” laissé vide | Lit un nom de fichier sans signification | Vérifier s’il est ignoré |
| Hiérarchie des titres | h1 > h2 > h3, niveau par niveau | Passer directement de h2 à h4 | axe signale le saut de niveau |
| Bouton icône | Ajouter aria-label=”Rechercher” | Ne lit que « bouton » | NVDA/VoiceOver |
| Tableaux | Balises th dans l’en-tête du tableau | Tout construit avec des td | Vérifier si l’en-tête est lu pour chaque ligne |
5. Validation : après le scan automatique, compléter à la main
Dernier malentendu courant : « si l’extension axe affiche du vert, c’est conforme ». Les outils automatiques ne couvrent qu’environ 30 à 40 % des problèmes d’accessibilité. Ils détectent les erreurs mécaniques comme les contrastes, les alt manquants ou les sauts de niveau de titre, mais ils ne peuvent pas tester les pièges au clavier, l’ordre de tabulation ou l’expérience réelle avec un lecteur d’écran. Une validation complète exige trois étapes : un scan automatique avec axe, un parcours manuel au clavier des quatre pages clés, et une écoute de la page d’accueil avec NVDA (Windows) ou VoiceOver (Mac).
Côté priorités, commencez par ce qui « ne touche pas au design et se règle uniquement dans le code » : contrastes, hiérarchie des titres, alt, anneau de focus. Ces points ne nécessitent pas l’intervention d’un designer et un développeur peut les corriger en deux jours. Les éléments qui demandent de réécrire l’interaction (menus déroulants personnalisés, gestion du focus dans les fenêtres modales) viennent dans un second temps : plus lourds, mais moins nombreux. Visez WCAG 2.2 AA, sans chercher le AAA : le AAA exige un contraste de 7:1 pour le texte courant, ce qui oblige souvent à sacrifier l’esthétique, pour un rapport coût-bénéfice défavorable.
| Méthode de validation | Problèmes détectables | Taux de couverture | Fréquence |
|---|---|---|---|
| Scan automatique axe/WAVE | Contrastes, alt manquants, sauts de niveau de titre | Environ 30 à 40 % | Avant chaque mise en ligne |
| Parcours manuel au clavier | Ordre de tabulation, pièges au clavier | Non détectable automatiquement | Une fois par mois |
| Écoute avec NVDA/VoiceOver | Expérience de lecture, nommage aria | Non détectable automatiquement | Une fois par trimestre |
| Retours d’utilisateurs réels | Points de blocage en usage réel | Le plus précis, mais le plus lent | Collecte continue |
FAQ — Questions fréquentes
WCAG 2.1, 2.2, AA, AAA : lequel choisir ?
Notre site est petit : combien de jours demande une mise en accessibilité ?
Si l’extension axe affiche tout en vert, suis-je conforme ?
Quelle longueur et quel contenu pour l’alt d’une image ?
Nous utilisons un thème prêt à l’emploi : faut-il vraiment retravailler l’accessibilité nous-mêmes ?
L’accessibilité entre-t-elle en conflit avec le SEO, vais-je devoir sacrifier le design ?
Pour conclure
L’accessibilité est trop souvent traitée comme un projet de façade, fait pour cocher une case de conformité : on lance un plugin, on prend deux captures d’écran et on les glisse dans le livrable. La bonne approche consiste à la découper en une liste P0 réalisable en trois jours : d’abord remettre de l’ordre dans les contrastes et la hiérarchie des titres, puis vérifier que le focus clavier circule partout, enfin compléter les alt et les aria. Une fois ces actions menées, votre site est utilisable au lecteur d’écran, et plus lisible pour les moteurs de recherche comme pour les robots d’IA.
Trois étapes pour passer à l’action : premièrement, installez axe et scannez tout le site, puis listez dans un tableau les contrastes, les alt manquants et les sauts de niveau de titre ; deuxièmement, débranchez la souris et parcourez au Tab la page d’accueil, les pages produit et les formulaires, en notant tous les endroits où le focus se bloque ; troisièmement, lancez un scan automatique avant chaque publication mensuelle et écoutez intégralement la page d’accueil au lecteur d’écran chaque trimestre. Sur un site multilingue, veillez aussi à la complétude des traductions des alt et des titres, voir le traitement des graphiques sur un site multilingue.
Une phrase à retenir : l’accessibilité n’est pas un correctif destiné à des publics spécifiques, c’est écrire une page en langage humain. Ce que le lecteur d’écran comprend, les moteurs de recherche le lisent, et les IA peuvent alors vous citer.