Non-conformités fréquentes
Les problèmes d'accessibilité les plus souvent rencontrés, et comment les corriger.
- Alternatives textuelles manquantes : la non-conformité la plus citée
Les images sans alternative textuelle sont invisibles pour les personnes utilisant un lecteur d'écran, et c'est le problème le plus souvent invoqué dans les contentieux d'accessibilité. Voici exactement comment le corriger.
- Étiquettes de formulaire manquantes : pourquoi le texte indicatif ne suffit pas
Un champ de formulaire sans étiquette associée par programme est un jeu de devinettes pour les personnes utilisant un lecteur d'écran, même si l'affichage paraît correct. Voici la correction, et pourquoi le texte indicatif ne compte pas.
- Contraste de couleurs insuffisant : la règle du 4,5:1 expliquée
Le texte doit présenter un rapport de contraste minimal avec son arrière-plan pour être lisible par les personnes malvoyantes. Voici le calcul exact, les erreurs fréquentes et comment les corriger.
- Composants inaccessibles au clavier : « ça marche à la souris » ne suffit pas
Tout composant interactif qui ne répond qu'à la souris exclut totalement les personnes naviguant au clavier - dont la plupart des personnes utilisant un lecteur d'écran et beaucoup de personnes ayant un handicap moteur. Comment le tester et le corriger.
- Lien d'évitement absent : pourquoi chaque page en a besoin
Sans moyen d'éviter la navigation répétée, les personnes au clavier ou au lecteur d'écran doivent parcourir le même menu sur chaque page avant d'atteindre le contenu. Voici la correction.
- Liens et boutons vides : quand même « cliquez ici » n'est pas là
Un lien ou un bouton sans texte accessible est annoncé simplement comme « lien » ou « bouton » par un lecteur d'écran - totalement inutilisable sans le contexte visuel. Pourquoi cela arrive, et comment le corriger.
- Langue de la page absente : la correction en un attribut
Sans attribut lang sur l'élément html, les lecteurs d'écran devinent les règles de prononciation et se trompent souvent. Une correction d'un seul mot, à l'effet considérable sur la façon dont une page est restituée.
- Titres de page absents ou génériques
Une page sans <title>, ou portant le même titre que toutes les autres, ne permet ni aux personnes utilisant un lecteur d'écran ni à celles ayant de nombreux onglets ouverts de distinguer les pages. Voici ce qui fait un bon titre.
- Hiérarchie de titres incorrecte : pourquoi sauter un niveau casse la navigation
Les personnes utilisant un lecteur d'écran naviguent souvent de titre en titre. Passer directement d'un H1 à un H3, ou choisir un niveau de titre pour sa taille visuelle, casse ce mode de navigation.
- Identifiants en double : une petite erreur de balisage aux grandes conséquences
Un attribut id doit être unique dans une page. Quand il ne l'est pas, les associations d'étiquettes, les références ARIA et les liens internes peuvent silencieusement pointer vers le mauvais élément.
- Balisage de présentation obsolète : <center>, <font> et l'attribut align
Des balises comme <center> et <font>, ainsi que l'attribut align, ont été abandonnées en HTML5 parce qu'elles mêlent la présentation à la structure. Voici par quoi remplacer chacune d'elles.
- Titres d'iframe manquants : nommer le contenu embarqué
Un iframe sans attribut title est annoncé par un lecteur d'écran comme une zone sans nom ni explication. À quoi ressemble un bon titre d'iframe, et pourquoi c'est important.
- Attributs ARIA invalides : quand vouloir aider aggrave les choses
Un attribut ARIA mal orthographié ou une valeur invalide n'échoue pas silencieusement : il peut activement fausser la façon dont les technologies d'assistance comprennent un élément. Comment le détecter et le corriger.
- Zoom désactivé : pourquoi maximum-scale=1 ne doit jamais être publié
Une balise meta viewport qui désactive le zoom exclut toute personne ayant besoin d'agrandir le texte pour le lire - un obstacle sans aucun usage légitime en conception adaptative moderne.
- En-têtes de tableau manquants : pourquoi un tableau de données a besoin de th, pas de gras
Un tableau de données dont les en-têtes ne sont que du texte en gras ou agrandi - et non de vrais éléments <th> - ne permet pas de savoir à quelle colonne ou à quelle ligne appartient une cellule.
- Problèmes de repères et de régions : donner aux lecteurs d'écran une carte de la page
Les repères ARIA permettent aux personnes utilisant un lecteur d'écran de passer directement de l'en-tête à la navigation, au contenu principal et au pied de page. Des repères absents ou dupliqués cassent ce raccourci.
- Bouton d'envoi de formulaire manquant
Un formulaire sans véritable commande d'envoi oblige à deviner comment le valider, ou bloque totalement les personnes au clavier et au lecteur d'écran si l'envoi ne fonctionne qu'à la souris.
- Champs de formulaire non groupés : pourquoi des boutons radio liés ont besoin de fieldset
Un groupe de boutons radio ou de cases à cocher liés, sans fieldset ni legend, ne permet pas de savoir que les options vont ensemble, ni quelle question le groupe pose.