L’utilisation de balises sémantiques est souvent recommandé pour des raisons d’accessibilité. Pour comprendre concrètement ce que cela signifie, passons en revue quelques balises pour voir comment elles sont interprétées par les lecteurs d’écrans.
La balise <section> est étonnement difficile
à comprendre et ses apports en terme d’accessibilité ne sont
pas aussi flagrants qu’on pourrait le penser. D’abord, voyons
dans quel cas il est recommandé de l’utiliser et ce qu’elle
signifie. D’après la MDN :
L'élément HTML section représente une section
générique d'un document, par exemple un groupe de contenu
thématique. Une section commence généralement avec un titre.
Voici un exemple d’utilisation :
<body> <header> <h1>The secret survey</h1> </header>
<main> <section> <h2>Our methodology</h2> <p>Lorem ipsum dolor sit amet.</p>
<h3>The questions</h3> <p>Lorem ipsum dolor sit amet consectetur adipisicing elit.</p>
<h3>The respondents.</h3> <p>Lorem, ipsum dolor.</p> </section>
<section> <h2>Results</h2>
<h3>What we expected</h3> <p> Lorem ipsum dolor sit amet consectetur adipisicing elit. Repellat, consequuntur? </p>
<h3>What we got</h3> <p>Lorem ipsum dolor sit amet consectetur.</p> </section> </main>
<footer> <p>© 2000 The secret survey. All rights reserved.</p> </footer></body>Dans cet extrait de code, représentant les résultats d’un sondage imaginaire, la méthodologie et les résultats peuvent être considérées comme des sections du document (ces parties possèdent un titre et séparent le document en des thématiques distinctes).
Il est cependant important de noter que la balise <section> possède un niveau assez haut de généricité et qu’avant
de l’utiliser, il faut se demander si une balise plus spécifique
ne serait plus à propos. Afin de faire ce choix, l’organigramme
des éléments HTML de html5doctor.com est très utile (voir l’organigramme ).
L’un des intérêts des balises sémantiques est qu’elles peuvent créer un repère (landmark). Ces derniers sont comme des marque-pages pouvant être accédés directement avec une combinaison de touches avec les lecteurs d’écrans. Sur Orca on peut parcourir les repères avec la touche M (Voir la documentation).
Si l’on regarde en pratique comment la balise section s’intègre dans la liste des repères, quelque chose d’étonnant
se produit. Essayons de parcourir l’exemple précédent en
essayant de passer de section en sections. Pour rappel, voici
la structure HTML :
<body> <header> <h1>The secret survey</h1> </header>
<main> <section> <h2>Our methodology</h2> <p>Lorem ipsum dolor sit amet.</p>
<h3>The questions</h3> <p>Lorem ipsum dolor sit amet consectetur adipisicing elit.</p>
<h3>The respondents.</h3> <p>Lorem, ipsum dolor.</p> </section>
<section> <h2>Results</h2>
<h3>What we expected</h3> <p> Lorem ipsum dolor sit amet consectetur adipisicing elit. Repellat, consequuntur? </p>
<h3>What we got</h3> <p>Lorem ipsum dolor sit amet consectetur.</p> </section> </main>
<footer> <p>© 2000 The secret survey. All rights reserved.</p> </footer></body>Voici maintenant ce qui se produit en listant la liste des repères puis en essayant de les parcourir :
Transcription
La page possède trois points de repère, sept en-têtes. M. Points de repère : trois éléments trouvés, boîte de dialogue. Bannière. Contenu principal. Information.
Il devrait y avoir en théorie cinq points de repère et
pourtant le lecteur n’en détecte que trois (ceux des
balises <header>, <main> et <footer>), les deux balises <section> semblent avoir été ignorées.
Ceci provient du fait que les balises <section> ne créent un repère que lorsqu’elles ont un nom accessible en utilisant aria-labelledby ou aria-label. Mettons à jour notre exemple précédent en utilisant aria-labelledby et voyons ce que nous dit le lecteur d’écran. Voici le
code mis à jour :
<body> <header> <h1>The secret survey</h1> </header>
<main> <section aria-labelledby="methodology"> <h2 id="methodology">Our methodology</h2> <p>Lorem ipsum dolor sit amet.</p>
<h3>The questions</h3> <p>Lorem ipsum dolor sit amet consectetur adipisicing elit.</p>
<h3>The respondents.</h3> <p>Lorem, ipsum dolor.</p> </section>
<section aria-labelledby="results"> <h2 id="results">Results</h2>
<h3>What we expected</h3> <p> Lorem ipsum dolor sit amet consectetur adipisicing elit. Repellat, consequuntur? </p>
<h3>What we got</h3> <p>Lorem ipsum dolor sit amet consectetur.</p> </section> </main>
<footer> <p>© 2000 The secret survey. All rights reserved.</p> </footer></body>Écoutons maintenant le lecteur d’écran :
Transcription
Chargement de document terminé. La page possède cinq points de repère, sept en-têtes. Maj gauche, Alt gauche, M. Points de repère : cinq éléments trouvés, boîte de dialogue. Bannière. Contenu principal. Our methodology, region. Results, region. Information.
Cette expérience nous montre que sans l’utilisation
d’attributs supplémentaires, utiliser une balise <section> ou <div> ne fait aucune différence.
Afin de représenter une section d’un document contenant
des champs de formulaire liés à une opération de
recherche ou de filtrage, la balise <search> peut être utilisée. Voici un exemple extrait de la documentation
de la MDN (<search> The generic search element) :
<body> <header> <h1>Movie website</h1> <search> <form action="./search/"> <label for="movie">Find a Movie</label> <input type="search" id="movie" name="q" /> <button type="submit">Search</button> </form> </search> </header></body>La MDN indique clairement les avantages de cette balise en terme d’accessibilité :
L'élément<search>définit un repère de recherche. Il n'est donc plus nécessaire d'ajouter role=search à un élément<form>.
Cette affirmation est à prendre avec vigilance car la
balise <search> est relativement récente
(arrivée en 2023) et par conséquent sa capacité à devenir
un repère n’est pas assurée sur les navigateurs
plus anciens.
À titre de comparaison pour l’année 2025, la balise <search> affiche un indice de compatibilité de 89,32% sur Can I Use alors
que l’attribut role assure une compatibilité
de 93,42%. Il est donc préférable pour le moment de préférer
l’attribut role pour une meilleure compatibilité.
D’ailleurs, si vous regardez le code HTML des principaux
moteurs de recherche (Google, DuckDuckGo, Yandex) tous utilisent l’attribut <search>
au lieu de la balise <nav>. Ceci peut
aussi s’expliquer pour des raisons historiques.
Avant de conclure, voici comment est traité l’exemple de la MDN par les lecteurs d’écrans. Voici le code d’exemple :
<body> <header> <h1>Movie website</h1> <search> <form action="./search/"> <label for="movie">Find a Movie</label> <input type="search" id="movie" name="q" /> <button type="submit">Search</button> </form> </search> </header></body>Et son rendu avec Orca :
Transcription
La page possède deux points de repère, un en-tête, un formulaire. Maj gauche, Alt gauche, M. Points de repère : deux éléments trouvés, boîte de dialogue. Bannière. Recherche.
La balise <time> est intéressante car
elle rend disponible, grâce à l’attribut datetime, la valeur exacte d’une date indépendamment du format
affiché. D’après la MDN (voir la documentation), la balise <time> permet d’afficher
une heure, une date ou une durée.
Voici un exemple d’utilisation :
<body> <p>Le concert a lieu <time datetime="2001-05-15T19:00">le 15 mai</time>.</p></body>
En terme d’accessibilité, la balise <time> n’apporte pour le moment rien de marquant. L’attribut datetime ne semble pas traité par les lecteurs d’écrans et c’est
donc le contenu de la balise qui est lu.
Exemple avec ce code :
<body> <p>Le concert a lieu <time datetime="2001-05-15T19:00">le 15 mai</time>.</p></body>Qui sera interprété ainsi par le lecteur d’écran :
Transcription
Le concert a lieu. Le quinze Mai. Point.
Lorsqu'on a besoin d’indiquer des raccourcis clavier, la
balise <code> est souvent utilisée en
premier recours. Il existe cependant une balise spéciale
pour ce genre de tâches : la balise <kbd>. Voici un exemple simple d’utilisation :
Code
<p>To leave earth, press <kbd>Space</kbd>.</p>Résultat
Press Ctrl + C to copy text (Windows).
Il est également possible d’imbriquer ces balises pour présenter des raccourcis :
Code
<p> Press <kbd><kbd>Alt</kbd> + <kbd>F4</kbd></kbd> and something nice will happen.</p>Résultat
Press Alt + F4 and something nice will happen.
Pour le moment, l’utilisation de la balise <kbd> ne présente aucun avantage en terme d’accessibilité. En
effet, les lecteurs d’écrans traitent cette balise comme
un <span> et sera lu sans ajout de contexte.
Pourquoi préférer le <kbd> au <code> dans ce cas ? Deux raisons :
<output> est une balise très intéressante
permettant d’afficher le résultat d’un calcul ou de toute
autre action de l’utilisateur.
Voici un exemple simple affichant en direct le prix sélectionné par l’utilisateur en fonction de la valeur du curseur de sélection :
Code
<body> <form oninput="result.value = price.value"> <label for="price">Prix : </label> <input type="range" id="price" name="price" min="0" max="100" value="50" /> <output name="result" for="price"> 50 </output>€ </form></body>Résultat
L’attribut oninput, placé sur un
formulaire peut accéder à tous les champs de
formulaire possédant un attribut name.
La même chose pourrait s’écrire de cette façon dans un fichier JavaScript séparé :
const form = document.querySelector("form");form.oninput = () => { form.result.value = form.price.value;};
La balise <output> est interprétée par
la plupart des navigateurs comme une Zone live ARIA. Cela signifie que si le contenu à l’intérieur de
cette balise change, le lecteur d’écran le lira.
Reprenons le code vu précédemment :
<body> <form oninput="result.value = price.value"> <label for="price">Prix : </label> <input type="range" id="price" name="price" min="0" max="100" value="50" /> <output name="result" for="price"> 50 </output>€ </form></body>Puis testons le lecteur d’écran en essayant d’interagir avec le curseur de sélection :