Les attributs ARIA en HTML : rendre le web accessible à tous

Quand on crée un site web, on pense souvent au design, aux couleurs, à la performance ou encore au référencement. Pourtant, il existe un aspect fondamental du web que beaucoup découvrent tardivement : l’accessibilité. Et c’est là que les attributs ARIA entre en jeu.

• Comprendre comment rendre vos interfaces compréhensibles et utilisables par tous les utilisateurs, y compris ceux qui naviguent au clavier ou avec un lecteur d’écran, sans complexifier votre HTML
• Savoir quand utiliser un attribut ARIA et quand s’en passer, pour éviter les erreurs courantes et améliorer la qualité globale de vos composants interactifs
• Concevoir des menus, formulaires et interactions dynamiques plus clairs, plus fiables et plus professionnels, en pensant l’accessibilité dès la création du site

un attribut ARIA en HTML n’est pas une technologie compliquée réservée aux experts. C’est un ensemble d’attributs qui permettent de rendre un site compréhensible pour tous les utilisateurs, y compris ceux qui utilisent des lecteurs d’écran ou naviguent sans souris. Autrement dit, un attribut ARIA permet au HTML de mieux parler.

L’objectif de ce guide est simple : vous expliquer les attributs ARIA depuis zéro avec des exemples concrets et du code compréhensible. Même si vous débutez en développement Frontend, vous serez capable à la fin de comprendre quand et comment utiliser un attribut ARIA intelligemment.

Comprendre l’accessibilité web avant ARIA

Avant de parler d’attribut ARIA en HTML, il est essentiel de comprendre pourquoi l’accessibilité web existe. Le web n’est pas utilisé uniquement par des personnes qui voient parfaitement, qui entendent tout et qui utilisent une souris. Certaines personnes naviguent au clavier, d’autres utilisent un lecteur d’écran, d’autres encore ont des troubles cognitifs ou moteurs.

Un lecteur d’écran ne “voit” pas une page web. Il lit le code HTML et annonce les éléments à l’utilisateur. Si le HTML est mal structuré ou trop générique, le lecteur d’écran se retrouve perdu. Et l’utilisateur avec.

Prenons un exemple très simple. Si vous utilisez une balise <div> pour tout, le lecteur d’écran ne sait pas distinguer un bouton d’un simple bloc. Visuellement, tout fonctionne. Mais pour une personne non voyante, c’est un vrai mur.

C’est exactement à ce moment-là que les attributs ARIA en HTML devient utile.

Qu’est-ce que ARIA exactement ?

ARIA signifie Accessible Rich Internet Applications. Derrière ce nom un peu intimidant se cache une idée très simple : ajouter des informations supplémentaires au HTML pour expliquer le rôle et le comportement des éléments à ceux qui en ont besoin.

ARIA n’ajoute rien visuellement à votre site. Il agit uniquement au niveau sémantique. Il sert de traducteur entre votre interface et les technologies d’assistance, comme les lecteurs d’écran.

Concrètement, ARIA fonctionne grâce à des attributs HTML spécifiques, comme role, aria-label ou aria-hidden. Ces attributs décrivent ce qu’est un élément, ce qu’il fait et dans quel état il se trouve.

Il est important de comprendre une règle essentielle dès maintenant : ARIA ne remplace jamais un bon HTML. Il vient compléter le HTML quand celui-ci ne suffit pas.

Pourquoi ARIA est souvent mal utilisé

Beaucoup de développeurs découvrent ARIA et veulent l’utiliser partout. C’est une erreur très fréquente. ARIA n’est pas une solution magique. Mal utilisé, il peut même rendre un site moins accessible.

Par exemple, ajouter role="button" sur un vrai <button> est inutile. Le HTML natif est déjà parfaitement compris par les lecteurs d’écran. Dans ce cas, ARIA n’apporte rien.

La règle d’or est la suivante : si le HTML natif suffit, n’utilisez pas ARIA. On parle souvent de “No ARIA is better than bad ARIA”. Et ce n’est pas une exagération.

L’attribut ARIA en HTML devient vraiment utile quand vous créez des composants personnalisés, comme des menus, des modales ou des onglets faits en JavaScript.

Les rôles d’un attribut ARIA : expliquer ce qu’est un élément

Le premier concept clé d’ARIA est le rôle. Le rôle permet d’indiquer la nature d’un élément à une technologie d’assistance.

Prenons un exemple concret. Vous créez un bouton avec une <div> pour des raisons de design ou de JavaScript.

<div class="btn">Valider</div>

Visuellement, cela ressemble à un bouton. Mais pour un lecteur d’écran, ce n’est qu’un simple conteneur sans signification. Il ne sera pas annoncé comme cliquable.

Pour corriger cela, vous pouvez ajouter un rôle ARIA.

<div class="btn" role="button">Valider</div>

Grâce à role="button", le lecteur d’écran comprend que cet élément agit comme un bouton.

Cependant, attention. Même avec ce rôle, le clavier ne fonctionnera pas automatiquement. L’attribut ARIA explique le rôle, mais il ne gère pas le comportement. Vous devez toujours gérer les événements clavier en JavaScript.

Les états et propriétés ARIA

ARIA ne sert pas seulement à décrire ce qu’est un élément. Il permet aussi de décrire son état. Par exemple, un bouton peut être activé, désactivé, ouvert ou fermé.

Imaginons un menu déroulant.

<button aria-expanded="false">
  Menu
</button>

L’attribut aria-expanded indique si le menu est ouvert ou non. Quand l’utilisateur clique sur le bouton et que le menu s’ouvre, la valeur doit être mise à jour.

<button aria-expanded="true">
  Menu
</button>

Cette information est essentielle pour un lecteur d’écran. Sans elle, l’utilisateur ne sait pas si une action a eu un effet.

ARIA en HTML repose beaucoup sur cette logique : expliquer ce qui change à l’écran, même quand ce changement n’est pas visible pour tous.

Lors d’un projet, un développeur avait créé une magnifique modale en JavaScript. Tout fonctionnait parfaitement à la souris. Mais un utilisateur malvoyant a signalé un problème : une fois la modale ouverte, il était impossible de savoir qu’elle existait.

Le problème ne venait pas du design, ni du JavaScript, mais de l’absence d’ARIA. En ajoutant un rôle dialog et des attributs comme aria-modal, la modale est devenue immédiatement compréhensible pour le lecteur d’écran.

Ce genre de situation arrive plus souvent qu’on ne le pense. Et c’est souvent à ce moment-là qu’on comprend la vraie valeur des attribut ARIA.

ARIA ne corrige pas un mauvais HTML

Il est crucial de le répéter. ARIA ne répare pas une structure HTML bancale. Si vous utilisez des <div> à la place de balises sémantiques comme <nav>, <main> ou <button>, vous compliquez inutilement l’accessibilité.

Le HTML moderne est déjà très riche. Les balises sémantiques sont comprises nativement par les technologies d’assistance. ARIA doit être utilisé uniquement quand le HTML atteint ses limites.

Les attributs ARIA à connaître absolument

Maintenant que vous comprenez à quoi sert un attribut ARIA et dans quels cas il devient utile, il est temps d’entrer dans le concret. ARIA repose sur des attributs que l’on ajoute directement dans le HTML. Certains sont incontournables, car ils répondent à des problèmes très fréquents en accessibilité.

L’objectif ici n’est pas de tout apprendre par cœur, mais de comprendre la logique derrière chaque attribut. Une fois cette logique comprise, ARIA devient beaucoup plus simple à utiliser.

aria-label : donner un nom clair à un élément

L’attribut aria-label est probablement le plus connu. Il sert à donner un nom lisible par les lecteurs d’écran à un élément qui n’en a pas ou dont le texte n’est pas explicite.

Prenons un cas très courant. Vous avez un bouton avec une icône, sans texte visible.

<button>
  <img src="loupe.svg" alt="">
</button>

Visuellement, vous comprenez qu’il s’agit d’un bouton de recherche. Mais pour un lecteur d’écran, ce bouton n’a aucun nom. Il sera annoncé comme “bouton, sans libellé”. Autant dire que l’utilisateur ne saura pas quoi faire.

C’est exactement ici que aria-label devient utile.

<button aria-label="Rechercher">
  <img src="loupe.svg" alt="">
</button>

Grâce à aria-label, le lecteur d’écran annoncera “Bouton Rechercher”. Le bouton devient immédiatement compréhensible, sans changer l’apparence visuelle.

Il est important de rester simple et naturel dans le texte. Inutile de décrire toute l’action en détail. Un mot clair vaut mieux qu’une phrase compliquée.

aria-labelledby : utiliser un texte existant

Parfois, vous n’avez pas besoin d’inventer un libellé. Le texte existe déjà ailleurs dans la page. Dans ce cas, aria-labelledby est préférable à aria-label.

Imaginons un formulaire avec un titre.

<h2 id="titre-formulaire">Inscription à la newsletter</h2>

<form>
  <input type="email">
</form>

Le champ email n’a pas de label explicite. Vous pourriez ajouter un aria-label, mais ce serait du contenu dupliqué. Une meilleure approche consiste à relier l’élément à un texte existant.

<input type="email" aria-labelledby="titre-formulaire">

Le lecteur d’écran utilisera le contenu du <h2> pour nommer le champ. Cela évite les répétitions et garantit une cohérence entre le visuel et l’accessibilité.

Dans une logique de qualité, aria-labelledby est souvent préférable à aria-label quand un texte pertinent est déjà présent.

aria-hidden : cacher sans supprimer

Il arrive fréquemment qu’un élément soit utile visuellement, mais inutile, voire perturbant, pour un lecteur d’écran. C’est souvent le cas des icônes décoratives, des éléments dupliqués ou des animations.

Prenons une icône purement décorative.

<span class="icon-star">★</span>

Un lecteur d’écran peut lire “étoile”, ce qui n’apporte aucune information utile. Pour éviter cela, on utilise aria-hidden.

<span class="icon-star" aria-hidden="true">★</span>

Avec aria-hidden="true", l’élément est totalement ignoré par les technologies d’assistance. Il reste visible à l’écran, mais disparaît du flux de lecture.

Attention toutefois. Ne jamais utiliser aria-hidden sur un élément interactif ou informatif. Si un bouton est caché à un lecteur d’écran, l’utilisateur ne pourra jamais y accéder.

aria-live : annoncer les changements dynamiques

Les sites modernes utilisent beaucoup JavaScript. Le contenu change sans recharger la page. Pour un utilisateur voyant, ces changements sont évidents. Pour un lecteur d’écran, ils passent souvent inaperçus.

C’est là qu’intervient aria-live.

Imaginons un message de confirmation qui apparaît après l’envoi d’un formulaire.

<div id="message"></div>

En JavaScript, vous injectez du texte dans cette div.

document.getElementById("message").textContent = "Message envoyé avec succès";

Visuellement, tout va bien. Mais le lecteur d’écran ne lit rien automatiquement. L’utilisateur ne sait pas que quelque chose s’est passé.

La solution consiste à ajouter aria-live.

<div id="message" aria-live="polite"></div>

Avec cette information, le lecteur d’écran annonce le nouveau contenu dès qu’il apparaît. Le terme polite indique que l’annonce peut attendre la fin de la lecture en cours.

Il existe aussi la valeur assertive, plus intrusive, utilisée uniquement pour des messages critiques comme des erreurs bloquantes.

ARIA permet ici de recréer une expérience équitable entre tous les utilisateurs.

aria-describedby : ajouter une explication utile

Parfois, un élément a besoin d’une précision supplémentaire. Par exemple, un champ de formulaire peut nécessiter une consigne.

<input type="password">
<p id="info-mdp">Le mot de passe doit contenir 8 caractères minimum.</p>

Visuellement, la consigne est claire. Mais le lecteur d’écran ne fera pas automatiquement le lien entre les deux.

On utilise alors aria-describedby.

<input type="password" aria-describedby="info-mdp">
<p id="info-mdp">Le mot de passe doit contenir 8 caractères minimum.</p>

Ainsi, le lecteur d’écran lira l’explication après avoir annoncé le champ. L’utilisateur comprend immédiatement ce qui est attendu.

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

Cet attribut est extrêmement utile pour les formulaires accessibles et bien guidés.

Le piège classique : trop d’ARIA tue l’ARIA

À ce stade, vous pourriez être tenté d’ajouter des attributs ARIA partout. C’est compréhensible, mais dangereux.

Si un champ possède déjà un <label> correctement relié avec l’attribut for, ARIA devient inutile. Le HTML natif fait déjà le travail.

Par exemple :

<label for="email">Adresse email</label>
<input id="email" type="email">

Ici, tout est parfait. Ajouter aria-label ou aria-labelledby serait redondant et parfois contre-productif.

Un attribut ARIA doit toujours être vu comme une aide ponctuelle, jamais comme un réflexe automatique.

Comprendre la logique avant de mémoriser

Il n’est pas nécessaire de connaître tous les attributs ARIA par cœur. Ce qui compte, c’est de comprendre leur intention.

Posez-vous toujours la même question :

“Est-ce qu’un lecteur d’écran peut comprendre cet élément aussi bien qu’un utilisateur voyant ?”

Si la réponse est non, alors ARIA a probablement un rôle à jouer.

ARIA dans les composants interactifs du quotidien

Jusqu’ici, vous avez découvert les bases d’ARIA et ses attributs les plus importants. Mais ARIA devient vraiment indispensable quand on commence à créer des composants interactifs personnalisés. Menus, onglets, accordéons ou modales sont souvent beaux visuellement, mais catastrophiques en accessibilité s’ils ne sont pas pensés correctement.

Nous allons voir comment un attribut ARIA permet de rendre ces composants compréhensibles et utilisables pour tous.

Rendre un menu de navigation accessible

Un menu est l’un des éléments les plus importants d’un site. Pourtant, lorsqu’il est construit uniquement avec des <div> et du JavaScript, il devient vite invisible pour les lecteurs d’écran.

Un menu accessible commence toujours par une bonne structure HTML. Quand c’est possible, la balise <nav> doit être utilisée. Elle est reconnue nativement.

<nav>
  <a href="/">Accueil</a>
  <a href="/services">Services</a>
  <a href="/contact">Contact</a>
</nav>

Dans ce cas précis, ARIA n’est pas nécessaire. Le HTML fait déjà le travail. En revanche, les choses se compliquent lorsqu’un menu est masqué, affiché dynamiquement ou animé.

Prenons l’exemple d’un menu burger.

<button aria-expanded="false" aria-controls="menu">
  Menu
</button>

<nav id="menu" hidden>
  <a href="/">Accueil</a>
  <a href="/services">Services</a>
  <a href="/contact">Contact</a>
</nav>

Ici, aria-expanded indique si le menu est ouvert ou fermé. L’attribut aria-controls précise quel élément est concerné par le bouton.

Quand le menu s’ouvre, il est crucial de mettre à jour l’état.

<button aria-expanded="true" aria-controls="menu">
  Menu
</button>

Cette simple information permet au lecteur d’écran d’annoncer clairement que le menu est désormais visible. L’utilisateur ne navigue plus à l’aveugle.

Les onglets : un vrai casse-tête sans ARIA

Les systèmes d’onglets sont très populaires. Pourtant, sans ARIA, ils sont quasiment inutilisables pour les technologies d’assistance.

Un onglet n’est pas un simple lien. Il s’agit d’un élément qui contrôle l’affichage d’un contenu. C’est exactement ce que ARIA permet d’exprimer.

Voici une structure de base.

<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="contenu-1" id="tab-1">
    HTML
  </button>
  <button role="tab" aria-selected="false" aria-controls="contenu-2" id="tab-2">
    CSS
  </button>
</div>

<div id="contenu-1" role="tabpanel" aria-labelledby="tab-1">
  Contenu HTML
</div>

<div id="contenu-2" role="tabpanel" aria-labelledby="tab-2" hidden>
  Contenu CSS
</div>

Chaque rôle a un sens précis. 

• tablist regroupe les onglets. 
• tab définit un bouton d’onglet. 
• tabpanel correspond à la zone de contenu associée.

L’attribut aria-selected indique quel onglet est actif. Lors d’un clic, cette valeur doit être mise à jour dynamiquement, tout comme l’affichage des panneaux.

Sans ARIA HTML, un lecteur d’écran ne comprendrait jamais cette relation complexe entre boutons et contenus.

Les accordéons : expliquer ce qui s’ouvre et se ferme

Un accordéon est un autre composant très courant. Visuellement, tout est évident. Mais pour un lecteur d’écran, l’ouverture d’un panneau peut passer complètement inaperçue.

Voici une version accessible.

<button aria-expanded="false" aria-controls="section-1">
  Voir les détails
</button>

<div id="section-1" hidden>
  Contenu détaillé
</div>

Quand l’utilisateur clique sur le bouton, vous devez à la fois afficher le contenu et mettre à jour l’état ARIA.

<button aria-expanded="true" aria-controls="section-1">
  Voir les détails
</button>

Grâce à aria-expanded, le lecteur d’écran annonce immédiatement que la section est ouverte. L’utilisateur comprend le changement sans avoir besoin de le voir.

Les modales : un cas critique pour l’accessibilité

Les fenêtres modales sont probablement l’un des composants les plus problématiques en accessibilité. Elles interrompent le flux normal de navigation et doivent être gérées avec soin.

Une modale accessible doit indiquer clairement qu’elle s’ouvre et qu’elle bloque le reste de la page.

<div role="dialog" aria-modal="true" aria-labelledby="titre-modale">
  <h2 id="titre-modale">Confirmation</h2>
  <p>Êtes-vous sûr de vouloir continuer ?</p>
  <button>Confirmer</button>
  <button>Annuler</button>
</div>

Le rôle dialog indique qu’il s’agit d’une fenêtre modale. aria-modal="true" signale que l’interaction est limitée à cette zone. aria-labelledby permet de donner un titre clair à la modale.

Mais attention. ARIA HTML ne gère pas le focus. Vous devez impérativement déplacer le focus à l’ouverture de la modale et le restituer à la fermeture. Sans cela, même avec ARIA, l’expérience reste bancale.

ARIA et le clavier : une responsabilité partagée

Un point essentiel mérite d’être souligné. ARIA décrit l’interface, mais il ne rend pas un élément accessible au clavier par magie.

Si vous créez un bouton avec une <div>, vous devez gérer les événements clavier manuellement. Entrée, espace, flèches directionnelles doivent être pris en compte.

ARIA HTML fonctionne toujours en duo avec JavaScript. L’un explique, l’autre agit.

Tester son accessibilité, même en tant que débutant

Vous n’avez pas besoin d’être expert pour tester l’accessibilité de votre site. Un test simple consiste à naviguer uniquement au clavier. Si vous ne pouvez pas utiliser votre site sans souris, un utilisateur non plus.

Vous pouvez aussi activer un lecteur d’écran, même brièvement. L’objectif n’est pas de tout maîtriser, mais de prendre conscience de ce que vit un autre utilisateur.

ARIA devient alors moins abstrait et beaucoup plus concret.

Bonnes pratiques essentielles avec ARIA HTML

Maintenant que vous avez une vision claire d’ARIA HTML et de son utilité concrète, il est temps de poser les bases d’une utilisation saine et durable. ARIA est puissant, mais comme tout outil puissant, il peut faire plus de mal que de bien s’il est mal utilisé.

La première bonne pratique, et sans doute la plus importante, consiste à toujours privilégier le HTML natif. Les balises sémantiques comme <button>, <nav>, <header>, <main> ou <footer> sont déjà pensées pour l’accessibilité. Elles sont reconnues automatiquement par les lecteurs d’écran et gèrent nativement le clavier.

Un attribut ARIA doit intervenir uniquement quand le HTML atteint ses limites. Si vous pouvez résoudre un problème sans ARIA, alors vous avez probablement fait le bon choix.

Une autre bonne pratique essentielle consiste à maintenir la cohérence entre le visuel et l’accessibilité. Si un élément est visible à l’écran, il doit être accessible aux technologies d’assistance. À l’inverse, un élément masqué visuellement doit être masqué sémantiquement, ou au moins expliqué clairement.

ARIA ne doit jamais mentir. Si un bouton indique aria-expanded="true", alors quelque chose doit réellement être ouvert. Une incohérence entre l’état réel et l’état ARIA crée de la confusion et nuit fortement à l’expérience utilisateur.

Les erreurs ARIA les plus fréquentes chez les débutants

L’une des erreurs les plus courantes consiste à ajouter des rôles inutiles. Par exemple, appliquer role="button" sur un <button> n’apporte strictement rien. Pire encore, cela peut créer des comportements inattendus selon les lecteurs d’écran.

Une autre erreur fréquente est l’usage excessif de aria-label. Cet attribut est très pratique, mais il ne doit pas remplacer un vrai <label> dans un formulaire. Un formulaire bien structuré en HTML est toujours préférable à une rustine ARIA.

Il arrive aussi que certains développeurs utilisent aria-hidden="true" pour masquer visuellement des éléments interactifs. C’est une erreur grave. Un élément caché avec aria-hidden devient totalement inaccessible. Si l’utilisateur ne peut plus y accéder, l’accessibilité est rompue.

Enfin, beaucoup oublient que ARIA ne gère pas le comportement. Ajouter un rôle ou un attribut ne rend pas un élément cliquable, navigable ou interactif par magie. Le JavaScript reste indispensable pour gérer le focus, les événements clavier et les changements d’état.

Comment intégrer ARIA progressivement dans vos projets

Bonne nouvelle, vous n’avez pas besoin de rendre tout votre site parfait en une seule fois. L’accessibilité est un processus, pas un interrupteur.

Commencez par les zones critiques. Les formulaires, les menus, les modales et les composants dynamiques sont souvent les plus problématiques. En améliorant ces éléments en priorité, vous apportez déjà un gain énorme à vos utilisateurs.

Ensuite, adoptez une habitude simple : à chaque nouveau composant, posez-vous la question de son accessibilité dès la conception. Est-ce qu’un lecteur d’écran peut comprendre ce composant ? Est-ce qu’un utilisateur au clavier peut l’utiliser sans frustration ?

ARIA devient alors un réflexe réfléchi, et non une contrainte ajoutée après coup.

ARIA et SEO : un bonus souvent sous-estimé

Même si ARIA n’est pas un facteur de référencement direct, il contribue indirectement à un meilleur SEO. Un site accessible est généralement mieux structuré, plus cohérent et plus compréhensible pour les moteurs de recherche.

Les moteurs aiment les contenus clairs, bien organisés et orientés utilisateur. En améliorant l’accessibilité avec ARIA, vous améliorez aussi la qualité globale de votre code et de votre expérience utilisateur.

C’est un cercle vertueux. Ce qui aide vos utilisateurs aide souvent aussi votre visibilité.

Pourquoi ARIA change votre manière de coder

Apprendre ARIA HTML ne consiste pas seulement à ajouter des attributs. Cela change profondément votre façon de concevoir une interface. Vous commencez à penser en termes d’intention, de compréhension et de parcours utilisateur.

Vous ne codez plus uniquement pour l’œil, mais aussi pour l’oreille, le clavier et la logique. Et cette prise de conscience est souvent un tournant dans la progression d’un développeur web.

ARIA vous oblige à ralentir, à réfléchir, et finalement à écrire un meilleur HTML.

Rendre le web accessible n’est pas une option, ni une contrainte imposée par des normes abstraites. C’est un choix humain, pragmatique et profondément utile. Un attribut ARIA en HTML n’est pas là pour compliquer votre code, mais pour lui donner une voix plus claire et plus inclusive.

En comprenant quand utiliser ARIA, quand s’en passer et comment l’appliquer intelligemment, vous posez les bases d’un web plus juste et plus agréable pour tous. Même en tant que débutant, vous avez désormais les clés pour éviter les erreurs classiques et construire des interfaces compréhensibles.

L’accessibilité n’est pas une destination finale. C’est une manière de penser le web, jour après jour, projet après projet. Et si ARIA vous a semblé complexe au départ, rappelez-vous ceci : chaque petit effort compte, et chaque amélioration rend le web un peu meilleur qu’hier.

Alban

Fondateur de l’agence Créa-troyes, affiliée France Num
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr