Un lecteur d’écran ne devine rien. Il parcourt le DOM, interroge chaque nœud, et restitue ce que le balisage lui fournit. Quand le code HTML est mal structuré, l’utilisateur reçoit une bouillie sonore sans hiérarchie ni repères. L’accessibilité web ne se joue pas dans un audit tardif : elle se décide ligne par ligne, dès l’écriture du markup.
Nom accessible en HTML : ce que les technologies d’assistance lisent vraiment
Chaque élément interactif exposé à l’arbre d’accessibilité possède un nom accessible. Ce nom est calculé selon un algorithme précis défini par la spécification HTML Accessibility API Mappings (HTML-AAM) du W3C. L’ordre de priorité suit une cascade : aria-labelledby prime sur aria-label, qui prime sur le contenu de <label>, qui prime sur l’attribut title.
A découvrir également : Création de site internet à perpignan : vos besoins, notre expertise
Nous observons régulièrement des formulaires où un champ porte à la fois un placeholder, un aria-label et un title, chacun avec un texte différent. Le lecteur d’écran ne restitue qu’un seul de ces noms. Les autres sont ignorés, et le placeholder disparaît à la saisie. Résultat : l’utilisateur perd le contexte du champ dès qu’il commence à taper.
La règle technique est simple : un élément interactif, un seul nom explicite. Pour un input, un élément <label for="..."> associé par son attribut for reste la méthode la plus robuste. L’attribut aria-label se réserve aux cas où aucun label visible n’est possible (bouton icône, par exemple).
Lire également : Webmail ac Grenoble bloqué : les messages d'erreur les plus fréquents
Le piège des aria-hidden mal placés
Poser aria-hidden= »true » sur un conteneur retire l’ensemble de ses descendants de l’arbre d’accessibilité. Nous recommandons de ne jamais appliquer cet attribut sur un élément parent sans avoir vérifié qu’aucun enfant focusable (lien, bouton, input) ne s’y trouve. Un bouton invisible pour un lecteur d’écran mais atteignable au clavier crée un point de focus fantôme que l’utilisateur ne peut ni identifier ni quitter proprement.
Critères WCAG 2.2 et contraintes directes sur le balisage HTML
Les WCAG 2.2, publiées par le W3C en octobre 2023, ajoutent des critères de succès qui modifient concrètement la façon de coder certains composants.
- Le critère 2.4.11 Focus Not Obscured (Minimum) exige que l’indicateur de focus clavier ne soit pas entièrement masqué par un autre élément (header sticky, modale, bandeau cookie). En HTML, cela impose de gérer le z-index et le scroll-margin sur les éléments focusables situés sous des barres fixes.
- Le critère 2.5.8 Target Size (Minimum) fixe une zone cliquable d’au moins 24 pixels CSS pour les cibles interactives. Un lien inline dans un paragraphe dense peut ne pas atteindre ce seuil sans un padding explicite ou un espacement suffisant entre les cibles adjacentes.
- Le critère 3.3.7 Redundant Entry interdit de redemander une information déjà saisie dans le même processus, sauf si l’utilisateur doit la confirmer. Le balisage des tunnels de formulaire (checkout, inscription) doit prévoir un mécanisme de préremplissage ou de rappel des données.
Ces trois critères concernent directement le code HTML et CSS, pas uniquement le design. Les ignorer revient à produire un site techniquement non conforme aux nouvelles exigences du référentiel.
European Accessibility Act : accessibilité HTML obligatoire pour le e-commerce
Depuis la directive 2019/882, l’European Accessibility Act (EAA) s’applique à partir du 28 juin 2025 aux services de commerce électronique, plateformes de services en ligne et liseuses numériques dans l’ensemble de l’Union européenne. L’accessibilité n’est plus un critère de qualité optionnel : elle devient une obligation produit sous peine de sanctions.
L’impact sur le HTML est direct. Un tunnel de checkout doit exposer chaque étape via des landmarks ARIA ou des éléments sémantiques (<main>, <nav>, <form>). Les messages d’erreur doivent être associés programmatiquement aux champs concernés via aria-describedby. Les boutons de paiement nécessitent un nom accessible explicite, pas un simple « Continuer » sans contexte.
Pour les équipes techniques, cela signifie que chaque composant du parcours utilisateur (panier, formulaire d’adresse, sélection de livraison, confirmation) doit être auditable individuellement. Un défaut d’accessibilité sur un seul écran du tunnel peut entraîner un contentieux transfrontalier.
Attribut alt des images : au-delà du texte alternatif générique
L’attribut alt sur une balise <img> n’est pas une description libre. Son contenu doit transmettre la fonction de l’image dans son contexte, pas son apparence.
Une image décorative (séparateur, fond, illustration purement esthétique) reçoit un alt vide : alt= » ». Le lecteur d’écran l’ignore. Une image informative (graphique, schéma, capture d’écran d’interface) reçoit un alt qui décrit l’information transmise. Une image-lien reçoit un alt qui décrit la destination du lien, pas le visuel.
Erreur fréquente sur les images SVG inline
Un SVG intégré directement dans le HTML n’est pas une balise img. Il n’a pas d’attribut alt. Pour le rendre accessible, nous ajoutons un élément <title> à l’intérieur du SVG et nous lions ce titre au SVG via aria-labelledby. Sans cela, le lecteur d’écran restitue soit rien, soit le contenu brut des paths, ce qui est inutilisable.
Structure sémantique HTML et navigation par landmarks
Les éléments sémantiques HTML5 (<header>, <nav>, <main>, <aside>, <footer>) créent automatiquement des landmarks ARIA. Un utilisateur de lecteur d’écran peut sauter directement d’un landmark à l’autre, exactement comme un utilisateur voyant scanne visuellement les blocs d’une page.
Utiliser des div là où un élément sémantique existe revient à supprimer ces raccourcis de navigation. Un <div class="header"> n’expose aucun rôle à l’arbre d’accessibilité. Un <header> expose le rôle banner sans aucun attribut supplémentaire.
- Chaque page doit contenir un seul élément
<main>. Deux<main>dans le même document cassent la navigation par landmarks. - Un
<nav>utilisé pour la navigation principale et un second pour un menu secondaire doivent être différenciés par un aria-label distinct (« Navigation principale », « Navigation du pied de page »). - Les sections sans heading ne transmettent pas de sémantique utile. Un
<section>sans titre associé n’est pas restitué comme un landmark par la plupart des lecteurs d’écran.
La hiérarchie des titres (h1 à h6) complète cette structure. Un saut de niveau de titre rompt la navigation séquentielle : passer d’un h2 à un h4 sans h3 intermédiaire désoriente l’utilisateur qui parcourt la page par titres.
L’accessibilité du code HTML repose sur des choix techniques précis, pas sur des déclarations d’intention. Chaque attribut, chaque élément sémantique, chaque nom accessible mal défini crée une barrière que seul un audit du DOM permet de détecter. Avec l’entrée en vigueur de l’EAA et les nouveaux critères WCAG 2.2, ces choix ne relèvent plus de la bonne pratique : ils conditionnent la conformité légale du produit.
