Accessibilité Web (a11y) en HTML : le guide complet en 2025

Qu’est-ce que l’accessibilité web et pourquoi est-elle essentielle ?

L’accessibilité web (souvent abrégée a11y, pour accessibility avec 11 lettres entre a et y) désigne l’ensemble des pratiques visant à rendre les sites Internet utilisables par tous les utilisateurs, y compris ceux en situation de handicap. Concrètement, cela signifie concevoir et coder les pages de façon à ce que des personnes ayant des déficiences visuelles, auditives, motrices ou cognitives puissent accéder aux contenus et fonctionnalités sans obstacle. La finalité est d’offrir une expérience permettant « à tous les utilisateurs handicapés de percevoir, comprendre, naviguer et interagir avec le Web »​ sans rencontrer de barrières.

Un site accessible est essentiel pour les personnes en situation de handicap, et il bénéficie aussi à d’autres publics : par exemple aux personnes âgées dont les capacités diminuent, ou à celles faisant face à un handicap temporaire ou contextuel​. Une interface bien conçue profite ainsi à quelqu’un qui aurait un bras immobilisé temporairement, qui navigue sur un mobile en plein soleil ou qui dispose d’une connexion limitée. L’accessibilité s’inscrit dans une démarche d’égalité : c’est un impératif éthique (et souvent légal) visant à garantir à tous un accès équitable aux informations et services en ligne.

Pour citer Tim Berners-Lee, inventeur du Web :

« La puissance du Web est dans son universalité. L’accès par tout le monde, quel que soit le handicap, est un aspect essentiel. »

En somme, rendre le Web accessible à tous n’est pas optionnel, c’est un prérequis fondamental pour un Internet inclusif et de qualité. Un site respectant ces principes touche un public plus large, améliore l’expérience utilisateur générale et évite d’exclure des clients ou usagers potentiels.

Introduction aux normes WCAG

Pour guider les développeurs et designers vers un Web plus accessible, le W3C (World Wide Web Consortium) a défini des standards appelés WCAG (Web Content Accessibility Guidelines ou « Règles pour l’accessibilité des contenus Web » en français). Les WCAG constituent un ensemble de recommandations internationales visant à rendre le contenu web plus accessible. Elles sont organisées autour de quatre principes fondamentaux :

• Perceptible : le contenu doit être présenté de manière à pouvoir être perçu par tous les sens (par exemple, fournir des alternatives textuelles aux images pour les non-voyants, sous-titres pour les vidéos destinés aux malentendants, etc.).
• Utilisable : l’interface et la navigation doivent être utilisables par tous (par exemple, tout élément interactif doit pouvoir être utilisé au clavier, les animations ne doivent pas empêcher la manipulation, etc.).
• Compréhensible : l’information et le fonctionnement de l’interface doivent être compréhensibles (par exemple, le comportement des éléments est prévisible, les formulaires fournissent des aides en cas d’erreur de saisie, etc.).
• Robuste : le contenu doit être robuste et compatible avec les différentes technologies d’assistance (lecteurs d’écran, loupes d’écran, commandes vocales, etc.) et différents navigateurs. Autrement dit, un site web doit rester accessible même avec des outils ou environnements variés.

Ces principes forment l’acronyme POUR (Perceptible, Utilisable, Compréhensible, Robuste). Ils se déclinent en directives concrètes et en critères de succès testables. Chaque critère est associé à un niveau de conformité : A (minimum), AA ou AAA (niveau le plus strict). Par exemple, rendre les images accessibles via un texte alternatif est un critère de niveau A, tandis que fournir des sous-titres pour les vidéos pré-enregistrées est exigé au niveau AA. De nombreux référentiels et lois à travers le monde (y compris le RGAA en France) se basent sur les WCAG, généralement au niveau AA.

Historiquement, la première version majeure WCAG 2.0 est parue en 2008, suivie de WCAG 2.1 en 2018 (qui a apporté des critères pour les mobiles et certains handicaps cognitifs). Plus récemment, WCAG 2.2 a été publiée en 2023 en ajoutant quelques critères supplémentaires. À plus long terme, une refonte plus globale (WCAG 3.0) est en cours d’élaboration. Quoi qu’il en soit, WCAG 2.x constitue aujourd’hui le socle des bonnes pratiques d’accessibilité web et sert de référence pour évaluer si un site est accessible.

Bonnes pratiques HTML pour une meilleure accessibilité

Passons en revue les principales bonnes pratiques en HTML qui améliorent l’accessibilité. Même sans devenir immédiatement expert des WCAG, appliquer ces principes de base dans votre code HTML5 fait une grande différence.

Utilisation de l’attribut alt pour les images

Une règle fondamentale est de toujours fournir un texte alternatif approprié pour vos images, via l’attribut HTML alt. Ce texte alternatif (appelé description alternative ou texte de remplacement) sera lu par les lecteurs d’écran à la place de l’image, ou affiché si l’image ne charge pas. Il décrit brièvement le contenu ou la fonction de l’image. Chaque image informative ou fonctionnelle doit posséder un attribut alt pertinent​. Par exemple :

<img src="eiffel.jpg" alt="Photo de la tour Eiffel illuminée de nuit">
<!-- Texte alternatif décrivant l'information véhiculée par l'image -->

Dans cet exemple, le texte dans alt permet à un utilisateur aveugle de comprendre ce que montre l’image (la tour Eiffel illuminée la nuit).

En revanche, pour les images purement décoratives ou sans pertinence informative (par exemple, de simples icônes visuelles ou motifs d’arrière-plan), on utilisera un attribut alt vide alt="". Un alt vide indique aux technologies d’assistance de ignorer l’image. Ainsi, le lecteur d’écran ne la lira pas, évitant du bruit inutile. On peut également, dans certains cas, utiliser role="presentation" ou aria-hidden="true" sur une image décorative, mais la bonne pratique la plus simple reste souvent de fournir alt=""​w3.org. Exemple :

<img src="motif-deco.png" alt="">
<!-- Image décorative : alt vide pour qu'elle soit ignorée par les lecteurs d'écran -->

Ici, le fichier “motif-deco.png” n’ayant pas d’altération de contenu, l’attribut alt vide signale qu’il est dispensable à la compréhension. Ne laissez jamais une image sans attribut alt : omettre complètement alt reviendrait à laisser le lecteur d’écran deviner (souvent en lisant le nom de fichier, ce qui est peu utile). En résumé, texte alternatif descriptif pour les images utiles, texte alternatif vide pour les images décoratives.

Structure sémantique avec les balises HTML5 (<header>, <nav>, <main>, etc.)

Utiliser une structure sémantique HTML appropriée est un pilier de l’accessibilité. Plutôt que d’imbriquer des <div> sans signification, il est recommandé d’utiliser les balises sémantiques HTML5 qui indiquent la nature du contenu. Par exemple, HTML5 introduit des éléments tels que <header>, <nav>, <main>, <aside>, <article>, <section>, <footer>… Ces balises apportent du sens à la page en définissant des zones (en-tête, navigation, contenu principal, zone complémentaire, article indépendant, section, pied de page). Les lecteurs d’écran et autres outils peuvent en tirer parti pour aider l’utilisateur à se repérer dans la page (certains lecteurs d’écran permettent de naviguer de région en région, de titre en titre, etc.). Comme le résume le W3C : utiliser le bon balisage HTML « pour fournir du sens et de la structure » facilite grandement la compréhension du contenu​.

Voici une structure HTML5 type d’une page :

<!DOCTYPE html>
<html lang="fr">
<head>
  <meta charset="utf-8">
  <title>Exemple de page</title>
</head>
<body>

  <header>
    <h1>Nom du Site</h1>
    <!-- En-tête du site, par ex. logo et titre principal -->
  </header>

  <nav aria-label="Navigation principale">
    <ul>
      <li><a href="/">Accueil</a></li>
      <li><a href="/services.html">Services</a></li>
      <li><a href="/contact.html">Contact</a></li>
    </ul>
    <!-- Menu de navigation du site -->
  </nav>

  <!-- Lien d'évitement permettant de passer directement au contenu principal -->
  <a href="#contenu" class="skip-link">Aller au contenu principal</a>

  <main id="contenu">
    <!-- Contenu principal de la page -->
    <article>
      <h2>Titre d’article</h2>
      <p>Texte de l’article...</p>
    </article>
  </main>

  <aside>
    <h2>Complément d’information</h2>
    <p>Contenu annexe (sidebar) pouvant contenir des liens, publicités, etc.</p>
  </aside>

  <footer>
    <p>&copy; 2025 Mon Site - Tous droits réservés</p>
  </footer>

</body>
</html>

Dans cet extrait, on voit l’utilisation des balises sémantiques appropriées : <header> pour l’en-tête, <nav> pour la barre de navigation, <main> (avec un id="contenu" pour pouvoir y accéder via un lien d’évitement) pour la zone principale, un <article> avec un titre <h2> pour un article de contenu, <aside> pour du contenu complémentaire, et <footer> pour le pied de page. Cette structuration sémantique offre plusieurs avantages :

• Compréhension et navigation : Un utilisateur aveugle pourra utiliser les raccourcis de son lecteur d’écran pour sauter directement de région en région (par ex., aller directement au <main> ou à la navigation). S’il utilise la touche de tabulation, le lien d’évitement « Aller au contenu principal » en haut de page lui permettra de passer le menu pour atteindre rapidement le contenu central.
• Interopérabilité : Les outils d’assistance et même les moteurs de recherche comprennent mieux l’organisation de votre page. Par exemple, <nav> est automatiquement identifié comme une zone de navigation (rôle ARIA implicite « navigation »), <main> comme le contenu principal, etc. Vous n’avez donc généralement pas besoin d’ajouter d’attributs ARIA redondants pour ces rôles (ils peuvent être utiles uniquement si vous avez des zones supplémentaires à distinguer, comme plusieurs menus de navigation que l’on peut différencier avec aria-label).
• Maintenance facilitée : Pour les développeurs, structurer clairement en HTML sémantique permet de mieux se repérer dans le code et de collaborer plus efficacement, tout en réduisant la dépendance à des solutions JavaScript ou ARIA complexes pour indiquer la structure.

En résumé, utilisez les balises HTML selon leur sémantique prévue : des titres <h1> à <h6> ordonnés hiérarchiquement pour structurer vos sections de contenu, des listes <ul>/<ol> pour les ensembles d’éléments, <header>/<footer> pour les en-têtes et bas de page, <section> ou <article> pour délimiter des groupes logiques de contenu, etc. Une structure sémantique solide est la base même d’un HTML accessible.

Formulaires accessibles : <label>, <fieldset> et <legend>

Les formulaires demandent une attention particulière en matière d’accessibilité, car ils impliquent de l’interaction. Pour qu’un utilisateur de lecteur d’écran puisse remplir un formulaire facilement, chaque champ de formulaire doit être associé à une étiquette descriptive. En HTML, cela se fait avec la balise <label> :

• Utilisez un attribut for sur <label> qui pointe vers l’identifiant (id) du champ de formulaire correspondant​. Ainsi, le label est explicitement lié au champ. Quand le focus ira sur le champ (ou si l’utilisateur clique sur le texte du label), le lecteur d’écran annoncera le texte du label, ce qui permet de comprendre quoi saisir.
• Assurez-vous que le texte du label est clair et concis, indiquant quelle information est attendue. Par exemple, “Entrez votre nom :” plutôt que “Nom :” seul, si cela apporte de la clarté.

Dans sa documentation, le W3C souligne que « la plupart du temps, les étiquettes sont nécessaires pour permettre à tous les lecteurs de comprendre la saisie requise »​. Autrement dit, ne faites exception à l’absence de label visible que dans de rares cas très spécifiques (et en fournissant alors une alternative ARIA, comme aria-label – voir section ARIA).

Pour les formulaires complexes comportant plusieurs groupes de champs, on utilisera en plus les balises <fieldset> et <legend>. Le <fieldset> permet de regrouper des champs connexes (par exemple, un ensemble de boutons radio ou de cases à cocher liées entre eux, ou bien toutes les informations d’adresse d’un utilisateur). La balise <legend> placée à l’intérieur du fieldset sert de titre de groupe de champs et sera annoncée par les lecteurs d’écran pour préciser le contexte groupé.

Exemple de formulaire accessible combinant ces éléments :

<form action="/inscription" method="post">

  <fieldset>
    <legend>Choisissez votre abonnement :</legend>

    <input type="radio" id="abo-basic" name="abonnement" value="basic">
    <label for="abo-basic">Offre de base</label><br>

    <input type="radio" id="abo-premium" name="abonnement" value="premium">
    <label for="abo-premium">Offre premium</label><br>
  </fieldset>

  <p>
    <label for="email">Votre courriel :</label><br>
    <input type="email" id="email" name="email" required>
  </p>

  <button type="submit">Valider</button>
</form>

Dans cet exemple :

• Les deux boutons radio “Offre de base” et “Offre premium” sont regroupés dans un <fieldset> avec une légende “Choisissez votre abonnement :”. Ainsi, un utilisateur de lecteur d’écran saura qu’il s’agit d’un choix entre plusieurs options d’abonnement. La <legend> sera lue comme introduction commune aux deux options, puis chaque <label> de radio sera lu avec son état (sélectionné ou non).
• Chaque <input> a un id unique et chaque <label> associé utilise l’attribut for pointant vers cet id. Par exemple, le label “Offre de base” est lié à <input id="abo-basic">. Cela garantit que lorsque le focus est sur ce radio, le texte “Offre de base” est annoncé.
• Le champ texte pour le courriel a aussi son label “Votre courriel :” associé. On a regroupé label et input dans un paragraphe pour l’exemple, et ajouté un saut de ligne <br> pour qu’ils apparaissent l’un en dessous de l’autre visuellement. (Alternativement, on aurait pu envelopper input et label dans une <label> englobante ou utiliser du CSS pour la disposition.)
• Le bouton de soumission “Valider” possède un libellé clair. (Évitez les boutons sans texte ou avec des labels non explicites comme “OK” isolé : nous y reviendrons.)

Avec ce balisage, le formulaire est correctement annoté. Un utilisateur pouvant difficilement utiliser la souris pourra naviguer de champ en champ avec la touche Tab et entendra à chaque focus le label du champ en cours. Cela rend l’expérience de remplissage fluide.

Bonnes pratiques supplémentaires pour les formulaires : indiquez les champs obligatoires (par du texte ou l’attribut required en HTML5, qui est également vocalisé par certains lecteurs d’écran), fournissez des messages d’erreur clairs et associez-les aux champs (via aria-describedby ou en plaçant le message dans le label), et utilisez des contrôles de formulaire natifs appropriés (<select> pour des listes déroulantes, types HTML5 pour les champs spéciaux comme email, date, etc. qui activent des comportements/accessibilités natives). Plus vous vous appuyez sur les éléments HTML standard, plus vous bénéficiez de leur support d’accessibilité par défaut.

Attributs ARIA de base (aria-label, aria-hidden, etc.)

WAI-ARIA (Web Accessibility Initiative pour Accessible Rich Internet Applications) est un ensemble d’attributs destinés à compléter HTML pour améliorer l’accessibilité des contenus plus complexes (souvent des interfaces riches en JavaScript). ARIA permet, entre autres, d’ajouter des rôles sémantiques et des propriétés accessibles à des éléments qui en manqueraient en HTML brut. Cependant ARIA ne doit pas remplacer le HTML sémantique natif, mais venir en renfort si nécessaire. Autrement dit, utilisez d’abord la balise HTML adéquate si elle existe (par ex. utiliser <button> donnera automatiquement un rôle de bouton accessible, plutôt qu’un <div role="button"> moins bien supporté). N’employez les attributs ARIA que dans les cas où le HTML seul ne suffit pas à rendre le composant accessible.

Parmi les attributs ARIA les plus courants et utiles en HTML de base, on trouve :

• aria-label : il fournit un libellé accessible à un élément qui n’en a pas via du texte visible. Par exemple, un bouton qui n’affiche qu’une icône graphique (sans texte) peut recevoir un aria-label="Fermer la fenêtre" pour que les technologies d’assistance comprennent la fonction du bouton. De même, une <nav> supplémentaire pourrait avoir aria-label="Navigation secondaire" pour distinguer différents menus de navigation. L’attribut aria-label remplace le contenu textuel aux yeux du lecteur d’écran : il est donc à utiliser lorsqu’il n’y a pas de texte visible adéquat. Exemple : <!-- Bouton d'icône sans texte visible, labellisé via aria-label --> <button type="button" aria-label="Rechercher"> <img src="icon-search.png" alt="" aria-hidden="true"> </button> Dans cet exemple, le bouton de recherche est représenté visuellement par une icône (image de loupe). On lui ajoute aria-label="Rechercher" pour qu’un utilisateur non-voyant entende « Rechercher, bouton ». L’image à l’intérieur a alt="" et aria-hidden="true" car elle est purement décorative du point de vue accessible (c’est le libellé fourni via aria-label qui fait foi). Note: On aurait pu aussi utiliser un texte visible caché via CSS, mais aria-label offre une solution directe.
• aria-hidden="true" : marque un élément du DOM comme devant être ignoré par les technologies d’assistance. C’est utile pour cacher des éléments redondants ou non pertinents dans l’arborescence d’accessibilité. Par exemple, une icône décorative ou un pictogramme purement visuel peut porter aria-hidden="true" pour ne pas distraire la lecture. Autre cas, si vous dupliquez du contenu pour des besoins visuels (une même info affichée deux fois à des endroits différents), vous pouvez marquer l’une des deux occurrences comme aria-hidden pour éviter des répétitions inutiles. Attention : ne pas en abuser ; tout contenu important pour l’utilisateur ne doit évidemment pas être masqué aux aides techniques. <span class="icone-etoile" aria-hidden="true">★</span> Note : 4/5 Ici, l’étoile est un élément purement visuel (elle illustre “Note : 4/5”). On la cache aux lecteurs d’écran car l’information “Note : 4/5” en toutes lettres est déjà fournie après. Le lecteur d’écran dira “Note : 4 sur 5” et ignorera le symbole étoile. Sans aria-hidden, il aurait pu lire “étoile noire, Note : 4 sur 5”, ce qui aurait alourdi inutilement l’écoute.

Ces deux attributs (aria-label et aria-hidden) sont parmi les plus simples et utiles. Il en existe bien d’autres dans ARIA : par exemple role (pour assigner un rôle sémantique comme role="alert" pour une alerte, role="navigation" pour une nav supplémentaire…), aria-expanded (pour indiquer si un contenu dépliable est ouvert ou fermé), aria-describedby (pour référencer une description additionnelle d’un élément), etc. Apprendre ARIA dépasse le cadre de cette introduction, mais retenez qu’ARIA peut améliorer l’accessibilité si bien utilisé. En revanche, mal employé, ARIA peut créer de la confusion. Commencez donc par maîtriser ces attributs de base et n’introduisez des rôles ARIA spécifiques que lorsque le HTML ne fournit pas déjà la solution.

Enfin, n’oubliez pas de tester : si vous ajoutez un aria-label ou masquer quelque chose avec aria-hidden, vérifiez avec un lecteur d’écran que le résultat est celui escompté. ARIA est un outil puissant mais qui nécessite des tests pour s’assurer de son effet.

Gestion du focus et navigation au clavier

Un site web accessible doit pouvoir être utilisé entièrement au clavier, sans dispositif point & click. En effet, de nombreux utilisateurs ne peuvent pas ou ne veulent pas utiliser de souris (personnes non-voyantes, personnes à mobilité réduite, mais aussi simplement un utilisateur sur un ordinateur portable sans souris externe, etc.). La navigation au clavier se fait principalement via la touche Tab (pour se déplacer d’un élément focalisable au suivant) et Shift+Tab (pour revenir en arrière), la touche Entrée ou Espace pour activer un lien ou bouton, et parfois les flèches dans certains composants.

Pour assurer une bonne accessibilité clavier de votre page HTML, respectez ces bonnes pratiques :

• Utilisez les éléments HTML interactifs standards pour les interactions. Un lien (<a href="...">) ou un bouton (<button>) sont par défaut accessibles au clavier et focalisables. En revanche, si vous créez un élément cliquable en JavaScript sur un <div> ou <span> sans lui donner de rôle/attributs appropriés, il ne sera pas focusable nativement. Il est toujours préférable d’utiliser un <button> pour un bouton plutôt qu’un <div> customisé, car le bouton gère automatiquement le focus et l’activation clavier (Espace/Entrée) et annonce son rôle aux lecteurs d’écran.
• Assurez la visibilité du focus. Par défaut, les navigateurs affichent un contour (outline) autour de l’élément focalisé. Ne désactivez pas ce contour via CSS (ex: outline: none;) sans fournir une alternative équivalente, car cela reviendrait à cacher le repère visuel aux utilisateurs clavier. Si pour des raisons de design vous souhaitez un style personnalisé de focus, utilisez :focus (ou mieux :focus-visible) en CSS pour styliser l’élément sélectionné, mais en conservant un indicateur bien visible (soulignement, surbrillance, bordure épaisse, etc.). Le but est que lorsqu’on navigue à la Tabulation, on voit toujours où se situe le focus actuel sur la page.
• Respectez l’ordre de tabulation naturel. Par défaut, l’ordre dans lequel la touche Tab parcourt les éléments correspond à l’ordre du DOM (document HTML). Cet ordre devrait suivre une logique de lecture (généralement de haut en bas, et de gauche à droite pour une page web en langue occidentale). Évitez de modifier arbitrairement cet ordre car « c’est presque toujours une mauvaise idée »​ – cela peut dérouter l’utilisateur. En particulier, n’utilisez pas des valeurs positives de tabindex (attribut qui définit un ordre de tabulation personnalisé) sauf cas très exceptionnel. Un tabindex="1" ou plus force un élément à être focalisable plus tôt, ce qui brise souvent la cohérence de navigation. Si vraiment vous avez une raison de personnaliser l’ordre, préférez restructurer votre HTML différemment. Les seules valeurs de tabindex généralement utiles sont tabindex="0" (pour rendre un élément non-nativement focalisable, comme un <div>, insérable dans l’ordre naturel) et tabindex="-1" (pour rendre un élément focalisable uniquement via script ou ancre, mais pas via Tabulation normale).
• Prévoir des « liens d’évitement » (skip links). Ce sont des liens placés en haut de page (souvent cachés visuellement, mais qui deviennent visibles au focus) permettant d’aller directement à une section clé, typiquement le contenu principal. Dans l’exemple HTML5 plus haut, nous avons un lien <a href="#contenu">Aller au contenu principal</a> juste avant le <main>. Un tel lien évite à l’utilisateur clavier d’avoir à tabuler à travers tout le menu à chaque nouvelle page avant d’atteindre le contenu central. C’est un petit ajout très simple qui améliore notablement le confort de navigation au clavier.
• Gérer le focus dans les interactions dynamiques. Si votre site est purement HTML statique, vous n’avez pas à vous soucier de déplacer le focus manuellement. En revanche, dans le cas d’interfaces plus dynamiques (boîtes de dialogue modales, popups, onglets en JavaScript, etc.), pensez à déplacer le focus sur les éléments pertinents. Par exemple, lorsqu’une fenêtre modale s’ouvre, le focus devrait être déplacé automatiquement sur cette fenêtre (et rendu cyclique à l’intérieur) pour que l’utilisateur clavier ne “sorte” pas involontairement de la boîte de dialogue en tabulant. De même, si un clic ou une action déclenche un changement de contexte important, il peut être judicieux de déplacer le focus sur le nouvel élément apparu (par exemple, sur un message d’erreur affiché dynamiquement, via focus() en JavaScript ou via aria-live si on souhaite juste annoncer sans déplacer le focus).
• Tester la navigation clavier : Mettez-vous régulièrement dans la peau d’un utilisateur n’utilisant que le clavier. Essayez de naviguer sur vos pages sans la souris : pouvez-vous tout atteindre ? L’ordre est-il logique ? Savez-vous toujours où vous êtes (focus visible) ? Pouvez-vous activer tous les contrôles (menus, carrousels, etc.) avec Entrée/Espace ou via des alternatives ? Cette vérification manuelle est indispensable, car même si des outils automatiques signaleront certains problèmes, rien ne vaut un test réel pour repérer, par exemple, un élément important non focalisable.

En respectant ces règles, vous permettrez à un très large éventail d’utilisateurs d’interagir avec votre site. Gardez à l’esprit que l’accessibilité clavier va souvent de pair avec une bonne accessibilité générale : c’est le fondement pour les utilisateurs de lecteurs d’écran également (puisque ceux-ci naviguent au clavier).

Introduction aux outils de test d’accessibilité

Avoir des bonnes pratiques est essentiel, mais il est tout aussi important de vérifier concrètement que votre site est accessible. Pour cela, il existe différents outils de test d’accessibilité, allant des évaluations automatisées aux tests manuels assistés par des lecteurs d’écran. Voici quelques outils et méthodes phares :

Exemple de tableau de bord WAVE montrant le résumé d’accessibilité d’une page (aucune erreur et aucune erreur de contraste ici, mais 2 alertes, 11 éléments marqués comme fonctionnalités, 28 éléments structurels et 13 éléments ARIA détectés). WAVE (Web Accessibility Evaluation Tool) est un outil en ligne et une extension de navigateur (Chrome, Firefox, etc.) développé par WebAIM, conçu pour évaluer rapidement l’accessibilité d’une page web​. Une fois l’extension installée ou via le site web, WAVE analyse votre page et insère des icônes et annotations visuelles sur celle-ci pour signaler les erreurs, alertes et éléments structurants détectés. Par exemple, une image sans alt sera marquée d’une icône d’erreur sur la page, un lien suspecté peu explicite déclenchera une alerte, etc. Le panneau latéral de WAVE fournit un récapitulatif du nombre d’erreurs, d’alertes, d’éléments de structure (titres, listes…), d’éléments ARIA, etc. En cliquant sur une icône dans la page annotée, on obtient une description du problème et le lien vers la référence WCAG correspondante. WAVE est très utile pour un premier audit rapide et visuel de l’accessibilité de vos pages. Il ne remplace pas un audit exhaustif humain, mais permet de repérer facilement les problèmes les plus courants.

Lighthouse est un autre outil incontournable. Il s’agit d’un outil d’audit automatique intégré directement dans le navigateur Chrome (onglets Audits ou Lighthouse des DevTools). Lighthouse peut analyser une page et fournir un rapport avec des scores sur plusieurs aspects, dont un score d’Accessibilité sur 100. Il va par exemple vérifier la présence de textes alternatifs, le contraste des couleurs, la structure des titres, etc., et signaler les points à améliorer. Selon la documentation Google, Lighthouse vérifie ainsi les performances, l’accessibilité et le SEO de vos pages, entre autres choses, et propose des suggestions pour améliorer ces aspects​. Pour l’utiliser, ouvrez les outils de développement (F12) dans Chrome, allez dans l’onglet Lighthouse, sélectionnez Accessibility (ainsi que d’autres audits éventuellement) et lancez l’audit. Après quelques secondes, un rapport détaillé s’affiche, indiquant les problèmes trouvés (par exemple “Image element missing [alt] attribute” si des images n’ont pas d’alt) et des conseils pour les résoudre. Lighthouse est pratique pour avoir un aperçu global chiffré de l’accessibilité d’une page et peut être intégré dans un processus d’intégration continue. Gardez toutefois à l’esprit qu’il s’agit d’une analyse automatisée limitée : un bon score Lighthouse ne garantit pas une accessibilité parfaite, mais c’est un bon indicateur.

Lecteurs d’écran (screen readers) : rien ne vaut de tester son site avec les outils qu’utilisent réellement les personnes aveugles ou très malvoyantes. Les principaux lecteurs d’écran sont NVDA (Windows, gratuit), JAWS (Windows, payant) et VoiceOver (intégré sur macOS/iOS). Sur Android, on utilise TalkBack, et sur Linux, Orca. Pour un développeur, se familiariser avec au moins un lecteur d’écran est extrêmement instructif. Vous pouvez par exemple installer NVDA sur Windows (ou utiliser VoiceOver si vous avez un Mac) et essayer de naviguer sur votre site sans regarder l’écran, uniquement en écoutant et en utilisant le clavier. Les lecteurs d’écran offrent de nombreuses fonctionnalités de navigation (par titres, par liens, par régions ARIA-landmark, etc.) qu’il faut apprendre progressivement. Commencez par des opérations simples : ouvrez votre page, essayez de vous déplacer avec Tab ou les flèches, écoutez ce qui est annoncé. Testez le remplissage d’un formulaire : le lecteur d’écran lit-il bien chaque label avant le champ ? Testez la navigation par headings (souvent via la touche H ou un rotor de navigation) : la structure de vos titres est-elle cohérente ? Ce type de test manuel permet de détecter des problèmes qu’aucun outil automatique ne verra (par exemple, un texte de lien ambigu qui passe à travers les mailles des audits automatiques mais qui est déroutant à l’usage). Astuce : vous pouvez combiner les tests, par exemple utiliser d’abord WAVE ou Lighthouse pour corriger les erreurs évidentes, puis utiliser un lecteur d’écran pour valider l’expérience utilisateur réelle.

Il existe bien d’autres outils et extensions (par ex. l’extension axe de Deque, l’Accessibility Insights de Microsoft, ou des barres d’outils spécifiques). Chacun a ses avantages. L’important est de comprendre qu’aucun outil ne peut garantir à lui seul une accessibilité totale : ils sont là pour vous assister, mais vos propres tests et votre bon sens restent cruciaux. N’hésitez pas non plus à faire tester votre site par des personnes en situation de handicap si vous en avez l’occasion, ou à consulter des experts/auditeurs spécialisés pour un retour plus approfondi.

Conseils de rédaction pour un HTML accessible

Enfin, au-delà du code, la manière de rédiger le contenu HTML influence grandement l’accessibilité. Voici quelques conseils de rédaction à garder à l’esprit :

• Utilisez des textes de lien explicites et significatifs. Les liens hypertextes doivent pouvoir être compris hors contexte. Évitez les libellés vagues du type « cliquez ici » ou « lire la suite » tout seuls. Un utilisateur de lecteur d’écran peut en effet naviguer de lien en lien ; s’il entend uniquement « cliquez ici », il ne saura pas où mène le lien. Préférez des libellés décrivant la cible ou l’action, par exemple : <a href="rapport.pdf">Télécharger le rapport annuel 2024 (PDF)</a> au lieu de « Cliquez ici pour le rapport ». S’il faut absolument utiliser un texte court, contextualisez-le via du texte invisible (par exemple, un <span class="sr-only">...</span> contenant des précisions, qui sera lu par le lecteur d’écran mais caché en CSS). Mauvais exemple : « … <a href= »guide.html »>cliquez ici</a> pour en savoir plus. » ce lien ne fait pas sens hors contexte. Bon exemple : « … <a href= »guide.html »>En savoir plus sur l’accessibilité HTML</a>. » On comprend la destination rien qu’au libellé du lien.
• Structurez vos titres de façon hiérarchique. Les titres (<h1> … <h6>) organisent la page comme le plan d’un document. Respectez l’ordre des niveaux : un seul <h1> par page (titre principal), puis des sous-sections en <h2>, éventuellement des sous-sous-sections en <h3>, etc., sans sauter arbitrairement de niveau ni utiliser un titre parce que visuellement il est plus petit ou grand. La hiérarchie des titres doit refléter la structure logique du contenu. Cela aide tous les utilisateurs à parcourir la page (lecture en diagonale facilitée) et permet aux lecteurs d’écran de dresser la liste des titres pour navigation. Par exemple, un lecteur d’écran peut lister tous les <h2> de la page pour en avoir un aperçu. Si vos titres sont dans le désordre (ex. un <h4> isolé sans qu’il y ait eu de <h3>), cela crée un flou dans cette structure. Pensez-y comme les chapitres d’un livre : l’ordre doit être cohérent. De plus, évitez d’utiliser des balises de titre juste pour styler du texte en gros ou gras : utilisez-les seulement pour de vrais titres de sections. Pour le style, utilisez le CSS, pas le mauvais niveau de titre.
• Déclarez la langue par défaut du document et des portions traduites. N’oubliez pas d’ajouter l’attribut lang sur la balise <html> pour indiquer la langue principale de votre page (par exemple lang="fr" pour une page en français). Cela permet aux lecteurs d’écran de choisir la prononciation appropriée (une voix française pour du texte français, par exemple)​. Si vous insérez un mot ou un passage dans une autre langue, utilisez également lang="en" (ou autre code) sur l’élément en question. Par exemple : « Ce tutoriel explique la notion de <span lang= »en »>accessibility</span> (accessibilité). » Ainsi, le terme anglais sera lu avec la bonne prononciation. Fournir la langue est non seulement utile pour l’accessibilité, mais aussi requis par les standards (WCAG 2.1 Critère 3.1.1).

En appliquant ces conseils, vous rendez votre contenu plus compréhensible et navigable pour tous. En règle générale, soyez clair, cohérent et prévenant dans la rédaction de vos pages. Une bonne pratique est de relire vos contenus en vous demandant : « Si je ne voyais pas la mise en page ou les images, est-ce que je comprendrais bien ce qu’il faut faire ? Est-ce que chaque lien a un sens ? Est-ce que les sections de la page sont clairement indiquées ? ».

Conclusion

L’accessibilité web est un vaste sujet, mais ces bases HTML constituent un socle déjà très solide pour améliorer l’inclusion de vos sites. En résumé, il s’agit de : fournir des équivalents textuels aux contenus non-textuels, structurer ses pages de manière sémantique et logique, annoter correctement les formulaires, compléter au besoin avec les attributs ARIA appropriés, et toujours veiller à la navigabilité au clavier et au focus visible. Le tout, en écrivant des contenus clairs et descriptifs.

Gardez à l’esprit qu’intégrer l’accessibilité dès la conception est beaucoup plus facile que de la corriger a posteriori. Faites-en une habitude naturelle lors de votre développement HTML. Les bénéfices vont bien au-delà du respect de règles arbitraires : vous offrez une meilleure expérience utilisateur à tout le monde (souvent, un site plus accessible est aussi plus ergonomique et mieux référencé), vous élargissez votre audience potentielle, et vous vous conformez aux exigences légales croissantes en la matière.

Ce guide ne traite qu’une partie des bonnes pratiques (par exemple, l’accessibilité des contenus multimédias, le contraste des couleurs ou la gestion des contenus dynamiques en JavaScript sont d’autres pans importants). N’hésitez pas à poursuivre votre apprentissage avec les ressources officielles (telles que les tutoriels du W3C WAI, la documentation MDN, ou des formations spécialisées). En appliquant déjà ces principes de base en HTML, vous faites un grand pas vers un web plus inclusif, où chaque utilisateur, quelles que soient ses capacités ou son contexte, peut accéder à l’information sans frustration. C’est là toute la philosophie de l’accessibilité : un web conçu pour tous.