Comme nous l’avions déjà abordé dans notre précédent article, concevoir un site web accessible est aujourd’hui un enjeu incontournable pour garantir l’inclusion de tous les internautes, quel que soit leur contexte ou leurs capacités. L’accessibilité numérique ne se limite pas à respecter une contrainte réglementaire : elle améliore aussi l’expérience de l’ensemble des utilisateurs et valorise la qualité des sites dans les moteurs de recherche. Or, une grande partie de l’accessibilité repose sur la qualité et la pertinence du HTML utilisé. Respecter les bonnes pratiques — structure sémantique, équivalents textuels, navigabilité au clavier, libellés explicites — est donc essentiel pour offrir un web réellement inclusif et performant.
Voici les principaux réflexes à adopter en HTML pour viser l’excellence en matière d’accessibilité numérique.
Utilisez un HTML sémantique
Employez les éléments HTML appropriés (ex. : <header>, <nav>, <main>, <section>, <footer>, <article>) pour structurer la page. Cela aide les technologies d’assistance à identifier et parcourir les différentes régions et contenus du site, et améliore la compréhension globale pour tous les utilisateurs.
Structurez les titres de manière hiérarchique
Utilisez les balises de titres (<h1>, <h2>, <h3>…) selon la structure logique du document, sans sauter de niveau, pour offrir un plan clair aux lecteurs d’écran et garantir la cohérence de la navigation.
Soignez l’accessibilité clavier
Utiliser des éléments interactifs natifs
- Privilégiez les éléments HTML conçus pour l’interactivité et la navigation au clavier, comme
<button>,<a href="">,<input>,<select>,<textarea>. Ces éléments gèrent automatiquement le focus, la navigation avec Tab et Shift+Tab, ainsi que l’activation par la touche Entrée ou Espace. - Évitez d’utiliser des
<div>ou<span>pour créer des boutons, liens ou contrôles interactifs car ils ne sont pas gérés naturellement par les navigateurs pour le clavier.
Assurer la navigabilité clavier
- Vérifiez que l’ordre de tabulation est logique et cohérent avec les attentes de l’utilisateur. Le focus doit passer intuitivement d’un élément interactif à l’autre.
- Utilisez l’attribut
tabindex="0"seulement lorsque vous devez rendre focusable un élément non naturellement focalisable (avec prudence). - Évitez
tabindexavec valeur positive, car cela perturbe l’ordre naturel de navigation.
Gérer l’activation clavier
- Les éléments natifs déclenchent automatiquement les événements au clavier (touche Entrée ou Espace).
- Si vous devez créer un composant interactif personnalisé avec
<div>ou<span>, il faut ajouter les rôles ARIA correspondants (role="button"par exemple), rendre l’élément focusable (tabindex="0"), et gérer explicitement les événements clavier (keydownoukeypresssur Entrée et Espace) pour imiter le comportement natif.
Ajoutez des alternatives textuelles
- Chaque image doit avoir un attribut alt pertinent. Si l’image est purement décorative (ou illustrative) c’est-à-dire si elle n’apporte aucune information complémentaire au contenu textuel, il faut alors renseigner une alternative textuelle vide.
- Accompagnez les graphiques de descriptions.
- Pour tous les contenus vidéo et audio, ajoutez des sous-titres synchronisés et fournissez des transcriptions textuelles complètes ou une synthèse explicative du contenu.
Contraste et lisibilité
- Le contraste entre le texte et l’arrière-plan doit être suffisant (minimum WCAG AA). Tester le contraste avec des outils comme WebAIM Contrast Checker, Colour Contrast Analyser, ou Contrast Finder.
- Évitez d’utiliser uniquement la couleur pour transmettre une information (utile pour les daltoniens).
- Le texte doit rester lisible lors d’un zoom à 200 %, il ne doit pas y avoir de perte de structure ou de contenus lorsque l’utilisateur zoom. Pour cela privilégiez les polices sans empattement et utilisez dans la css des unités de taille flexibles (em, rem).
Déclarez la langue du document
L’attribut lang dans la balise <html> est essentiel pour l’interprétation correcte par les lecteurs d’écran et les synthèses vocales : <html lang= »fr »>.
Soignez les textes de liens et boutons
Privilégiez des intitulés explicites compréhensibles hors contexte (ex. : « Télécharger le rapport » plutôt que « cliquez ici »).
Cela facilite la navigation des utilisateurs de lecteurs d’écran.
Formulaires accessibles
Étiquettes explicites et association des champs
- Chaque champ doit posséder une étiquette (« label ») clairement associée à l’élément du formulaire via l’attribut
for, pour être lisible par les lecteurs d’écran. - L’intitulé du champ doit être explicite, par exemple : « Adresse e-mail » plutôt que simplement « E-mail ».
Structuration et navigation
- Les champs doivent être regroupés de façon logique et ordonnée. Utiliser les balises
<fieldset>et<legend>pour structurer les groupes de champs connexes (par exemple, coordonnées personnelles). - La navigation dans le formulaire doit être possible entièrement au clavier : chaque champ et bouton doit recevoir le focus, qui doit être visible.
Indications et gestion des erreurs
- Préciser quels champs sont obligatoires, soit par une mention explicite, soit par un symbole compréhensible pour tous (et non simplement une couleur).
- Aider l’utilisateur en cas d’erreur de saisie avec des messages clairs, placés à proximité du champ concerné, et indiquant comment corriger l’erreur.
Informations de saisie et aide contextuelle
- Indiquer le type de données attendu pour chaque champ (par exemple, format de la date, numéro de téléphone).
- Les placeholders ne doivent jamais remplacer les labels, mais seulement fournir une aide complémentaire à la saisie.
- Veiller à ce que les boutons possèdent des intitulés explicites, comme « Envoyer la demande » plutôt que « OK », afin d’éviter toute confusion.
Aria et rôles complémentaires
Si un comportement personnalisé est nécessaire, appliquez les attributs ARIA (Accessible Rich Internet Applications) pour enrichir la sémantique là où HTML de base n’est pas suffisant, en gardant à l’esprit que trop d’ARIA peut nuire s’il est mal utilisé.
Quand utiliser ARIA ?
- ARIA doit être utilisée seulement si le HTML natif ne suffit pas. Si un rôle ou une fonctionnalité existe déjà avec des éléments standards (<button>, <nav>, <input>…), il faut les privilégier, car ils sont naturellement accessibles.
- ARIA est utile pour les widgets “riches” créés en JavaScript (menus déroulants personnalisés, carrousels, accordéons, etc.) qui ne sont pas accessibles d’origine.
Types d’attributs ARIA
Les rôles (role)
- Précisent la fonction de l’élément : role =
"button", role ="navigation", role ="dialog", etc. - Exemples :
- Un menu personnalisée reçoit role =
"menu"et chaque option role ="menuitem". - Un élément principal reçoit role =
"main"si <main> ne peut être utilisé.
- Un menu personnalisée reçoit role =
Les états et propriétés (aria-*)
- Fournissent des informations supplémentaires :
- aria-label=
"Description": nom accessible spécifique si le texte visible n’est pas clair. - aria-expanded=
"true/false": indique qu’un menu ou une section est développé ou replié. - aria-checked=
"true/false": état d’une case à cocher personnalisée. - aria-describedby=
"id": attribue une description accessible par l’ID d’un autre élément. - aria-details=
"id": référence une explication ou contenu détaillé lié à l’élément. - D’autres nombreux attributs existent en fonction du widget (voir les références MDN pour la liste complète).
- aria-label=
Domaines d’application typiques
- Composants personnalisés (accordéons, carrousels, sliders, menus dynamiques…)
- Indications d’état dynamiques : erreurs, notifications d’update en temps réel (attributs “live regions” comme aria-live).
Bonnes pratiques et précautions
- N’utilisez ARIA que si nécessaire : HTML sémantique reste la meilleure solution si disponible.
- Respectez la hiérarchie des rôles : ne donnez pas des rôles qui changent le sens natif d’un élément sans raison valable.
- Veillez à l’accessibilité clavier : tous les éléments interactifs ARIA doivent être accessibles au clavier, pas uniquement à la souris.
- Donnez des noms accessibles explicites : grâce à aria-label, aria-labelledby, etc., pour garantir la compréhension hors contexte.
- N’utilisez pas ARIA pour masquer un contenu interactif ou visible, ou pour supprimer le focus, sauf en toute connaissance de cause.
Focus visible
Il est essentiel d’offrir un indicateur clair et perceptible (bordure, surbrillance, etc.) lorsqu’un élément interactif (lien, bouton, champ de formulaire, etc.) reçoit le focus, notamment lors de la navigation au clavier
Un focus visible permet aux personnes naviguant sans souris, souvent via la touche « Tab » ou des dispositifs d’assistance, de repérer leur position dans la page et d’interagir efficacement. Masquer ou supprimer ce focus (par exemple via outline: none;) nuit à l’accessibilité, car des utilisateurs peuvent être complètement perdus dans l’interface.
Bonnes pratiques techniques
- Utiliser la pseudo-classe CSS
:focus(et de préférence:focus-visible) pour personnaliser et renforcer l’indicateur natif :
- Respecter un contraste suffisant (au moins 3:1) pour l’indicateur par rapport à l’arrière-plan, afin qu’il soit perceptible même pour les utilisateurs ayant une vision réduite.
- Éviter de supprimer complètement l’outline sans proposer d’alternative visible et accessible.
Recommandations complémentaires
En résumé
Privilégiez toujours la sémantique native HTML, structurez logiquement vos pages, testez systématiquement la navigation clavier, offrez des textes alternatifs adaptés et assurez lisibilité et clarté à tous les niveaux. L’accessibilité doit être intégrée dès la conception, et non ajoutée après coup.
Pour aller plus loin, référez-vous aux lignes directrices WCAG (W3C) et aux référentiels officiels
Accompagnement Lùkla sur l’accessibilité numérique
Vous avez des questions sur cet article ?
Vous souhaitez être accompagné pour créer un site Web accessible ou pour améliorer l’accessibilité de votre site ?
Les équipes de Lùkla se tiennent à votre disposition. Contactez-nous.
