Référentiel
Les règles d'accessibilité que nous vérifions
25 défauts d'accessibilité parmi les plus fréquents sur le web, expliqués sans jargon : ce que c'est, qui en pâtit, ce que dit la loi, comment le tester vous-même et comment le corriger, avec un exemple de code avant et après.
Plainpied s'appuie sur axe-core, le moteur d'audit de référence, aligné sur les WCAG 2.1 niveau AA et le RGAA. La détection automatique couvre une partie des critères ; notre méthode détaille ce qui se teste à la machine et ce qui demande un œil humain. Pour savoir ce que la loi impose à votre activité, voir les obligations par secteur.
Images et cadres
Tout contenu non textuel doit avoir une alternative compréhensible par une personne qui ne voit pas l'écran.
-
Critique
Images sans alternative textuelle
Une image porteuse d'information sans attribut alt est invisible pour qui n'affiche pas l'image : le contenu est purement et simplement perdu.
Voir la fiche → -
Majeur
Cadre (iframe) sans titre
Une iframe sans attribut title n'annonce pas ce qu'elle contient : le lecteur d'écran lit « cadre » sans plus de contexte.
Voir la fiche →
Couleurs et affichage
Le texte doit rester lisible quel que soit le confort visuel, et le zoom ne doit jamais être bloqué.
-
Quand le texte ne tranche pas assez sur son fond, il devient pénible voire impossible à lire pour une partie des visiteurs.
Voir la fiche → -
Une balise viewport avec user-scalable=no ou maximum-scale empêche d'agrandir la page sur mobile.
Voir la fiche →
Formulaires
Chaque champ doit annoncer clairement ce qu'on attend de l'utilisateur, y compris à un lecteur d'écran.
-
Critique
Champs de formulaire sans libellé
Un champ sans étiquette associée laisse l'utilisateur deviner ce qu'on attend de lui, et le lecteur d'écran n'annonce rien d'utile.
Voir la fiche → -
Critique
Listes déroulantes sans libellé
Un <select> sans étiquette ne dit pas ce qu'on choisit : « France, Belgique, Suisse » sans titre ne veut rien dire pour un lecteur d'écran.
Voir la fiche → -
Un <input type="submit"> sans value, ou un bouton de formulaire vide, est annoncé « bouton » sans qu'on sache ce qu'il déclenche.
Voir la fiche →
Liens et boutons
Un élément cliquable sans intitulé explicite est un cul-de-sac pour qui navigue à la voix ou au clavier.
-
Majeur
Liens sans texte accessible
Un lien vide, ou réduit à une icône sans alternative, n'indique pas où il mène. « Cliquez ici » répété n'aide pas davantage.
Voir la fiche → -
Critique
Boutons sans texte accessible
Un bouton réduit à une icône (croix de fermeture, menu burger) sans texte accessible est muet pour le lecteur d'écran.
Voir la fiche →
Titres et structure
Une page bien structurée se parcourt vite, à l'œil comme au lecteur d'écran. La hiérarchie des titres en est la colonne vertébrale.
-
Majeur
Page sans titre
Sans balise <title>, l'onglet, l'historique et les favoris affichent l'URL brute, et le lecteur d'écran n'annonce pas de quoi parle la page.
Voir la fiche → -
Majeur
Page sans attribut de langue
Sans lang sur la balise <html>, le lecteur d'écran ne sait pas dans quelle langue prononcer le texte.
Voir la fiche → -
Modéré
Page sans titre H1
Une page sans <h1> n'annonce pas son sujet principal et brouille sa hiérarchie de titres.
Voir la fiche → -
Sauter un niveau de titre (passer d'un h2 à un h4) casse la carte mentale de la page pour qui navigue de titre en titre.
Voir la fiche → -
Mineur
Titre vide
Une balise de titre sans texte (souvent utilisée pour son espacement) crée un repère vide qui perturbe la navigation.
Voir la fiche →
Repères et listes
Les régions de la page (en-tête, navigation, contenu principal) et les listes aident à se repérer et à sauter d'une zone à l'autre.
-
Du contenu placé en dehors des repères (header, nav, main, footer) ne peut pas être atteint par les raccourcis de navigation par région.
Voir la fiche → -
Sans balise <main>, l'utilisateur de lecteur d'écran ne peut pas sauter directement au contenu principal.
Voir la fiche → -
Un <ul> ou <ol> qui contient autre chose que des <li> casse l'annonce « liste de N éléments » du lecteur d'écran.
Voir la fiche → -
Modéré
Élément de liste hors liste
Un <li> qui n'est pas dans un <ul> ou un <ol> n'a pas de parent valide, et la sémantique de liste est perdue.
Voir la fiche → -
Modéré
Identifiants dupliqués
Deux éléments avec le même id cassent les liens d'ancre, les associations label/champ et les références ARIA.
Voir la fiche →
ARIA et composants riches
Mal employé, l'ARIA dégrade l'accessibilité au lieu de l'améliorer. Ces règles repèrent les usages cassés.
-
Critique
Attributs ARIA requis manquants
Un rôle ARIA sans ses attributs obligatoires est un composant à moitié décrit, que le lecteur d'écran restitue mal.
Voir la fiche → -
Majeur
Attributs ARIA invalides
Un attribut aria-* mal orthographié ou inexistant est purement ignoré : l'intention est perdue sans aucune alerte.
Voir la fiche → -
Critique
Valeurs d'attributs ARIA invalides
Un aria-labelledby qui pointe vers un id inexistant, ou un aria-expanded à « oui » au lieu de « true », ne produit aucun effet utile.
Voir la fiche → -
aria-hidden="true" sur <body> rend toute la page invisible aux lecteurs d'écran : le site entier disparaît pour eux.
Voir la fiche → -
Majeur
Attributs ARIA interdits
Certains éléments ou rôles n'autorisent pas certains attributs ARIA : les y poser produit un comportement imprévisible.
Voir la fiche →
Navigation au clavier
Tout ce qui se fait à la souris doit aussi se faire au clavier, sans piège ni zone inatteignable.
-
Une zone qui défile (bloc de code, tableau, conteneur à overflow) mais qu'on ne peut pas atteindre au clavier piège une partie de son contenu.
Voir la fiche →
Combien de ces défauts sont sur votre site ?
Lancez un audit gratuit : score, défauts détectés et corrections, en dix minutes, sans compte.
Lancer un audit gratuit