Plus d'un milliard de personnes dans le monde vivent avec une forme de handicap. Cela représente environ 15 % de la population mondiale. Parmi elles, des personnes aveugles ou malvoyantes, des personnes sourdes ou malentendantes, des personnes avec des troubles moteurs, des différences cognitives, ou des conditions temporaires comme un bras cassé ou une migraine.
Quand on construit des sites web sans tenir compte de ces réalités, on ne crée pas simplement un inconvénient. On empêche des personnes d'accéder à des informations, des services et des opportunités que d'autres considèrent comme acquis. L'accessibilité n'est pas une fonctionnalité. C'est une responsabilité.
Ce que signifie l'accessibilité web
L'accessibilité web consiste à concevoir et développer des sites pour que les personnes en situation de handicap puissent percevoir, comprendre, naviguer et interagir avec le contenu. Cela signifie aussi qu'elles peuvent contribuer au web.
Cela va bien au-delà des lecteurs d'écran. L'accessibilité couvre :
- Visuel : cécité, basse vision, daltonisme
- Auditif : surdité, malentendance
- Moteur : motricité fine limitée, tremblements, paralysie
- Cognitif : dyslexie, TDAH, troubles de la mémoire, difficultés d'apprentissage
- Temporaire et situationnel : poignet cassé, soleil sur l'écran, environnement bruyant, connexion lente
Le point essentiel : un design accessible profite à tout le monde. Les sous-titres aident dans un lieu bruyant. Un bon contraste aide en plein soleil. La navigation au clavier aide les utilisateurs avancés. Un texte clair aide les non-francophones. L'accessibilité n'est pas un mode spécial — c'est du bon design.
Le standard WCAG
Les Web Content Accessibility Guidelines (WCAG) sont le standard international pour l'accessibilité web, publié par le W3C. La version actuelle est WCAG 2.2, organisée autour de quatre principes résumés par l'acronyme POUR :
Perceptible
L'information doit être présentée de manière perceptible par tous les utilisateurs.
- Alternatives textuelles : chaque image a besoin d'un attribut
altdécrivant son contenu. Les images décoratives utilisentalt="". - Sous-titres et transcriptions : les vidéos nécessitent des sous-titres ; le contenu audio nécessite des transcriptions.
- Structure adaptable : le contenu doit rester compréhensible sans styles. Utilisez du HTML sémantique (
<h1>,<nav>,<main>,<article>). - Contenu distinguable : contraste de couleurs suffisant, texte redimensionnable, pas d'information transmise uniquement par la couleur.
Utilisable
Les utilisateurs doivent pouvoir interagir avec l'interface.
- Accessible au clavier : chaque élément interactif doit être atteignable et utilisable au clavier seul. Pas de piège au clavier.
- Temps suffisant : si le contenu a des limites de temps, les utilisateurs doivent pouvoir les prolonger ou les désactiver.
- Pas de déclencheur de crises : éviter le contenu qui clignote plus de trois fois par seconde.
- Navigable : titres de page clairs, hiérarchie de titres logique, liens d'évitement, indicateurs de focus visibles.
Compréhensible
Le contenu et l'interface doivent être compréhensibles.
- Texte lisible : spécifiez la langue de la page (attribut
lang). Utilisez un langage clair et simple quand c'est possible. - Comportement prévisible : la navigation doit être cohérente. Les pages ne doivent pas changer de contexte de manière inattendue.
- Aide à la saisie : étiquetez clairement les champs de formulaire. Fournissez des messages d'erreur utiles qui expliquent le problème et comment le corriger.
Robuste
Le contenu doit être suffisamment robuste pour fonctionner avec les technologies actuelles et futures.
- HTML valide : un balisage sémantique correct que les technologies d'assistance peuvent interpréter de manière fiable.
- Nom, rôle, valeur : les composants personnalisés doivent exposer leur fonction aux API d'accessibilité (via ARIA si nécessaire).
Niveaux de conformité
WCAG définit trois niveaux :
| Niveau | Signification | Exemple |
|---|---|---|
| A | Accessibilité minimale | Les images ont un texte alternatif, les pages ont des titres |
| AA | Objectif standard pour la plupart des sites | Ratio de contraste d'au moins 4,5:1 pour le texte normal |
| AAA | Niveau le plus élevé, pas toujours atteignable | Ratio de contraste de 7:1, langue des signes pour toutes les vidéos |
La plupart des législations dans le monde exigent la conformité au Niveau AA. C'est le niveau que vous devriez viser.
Obstacles courants et comment les corriger
Texte alternatif manquant sur les images
Le problème : les utilisateurs de lecteurs d'écran entendent "image" ou rien du tout.
La solution : ajoutez un texte alt descriptif à chaque image informative. Pour les images décoratives, utilisez alt="" pour que les lecteurs d'écran les ignorent.
<!-- Bien -->
<img
src="graphique.png"
alt="Graphique en barres montrant une augmentation de 40 % des ventes de janvier à juin 2025"
/>
<!-- Décoratif -->
<img src="separateur.svg" alt="" />
Contraste de couleurs insuffisant
Le problème : les personnes malvoyantes ou daltoniennes ne peuvent pas lire le texte.
La solution : assurez un ratio de contraste minimum de 4,5:1 pour le texte normal et 3:1 pour le gros texte (18px+ ou 14px gras). Utilisez un outil de vérification du contraste pour tester vos combinaisons de couleurs.
Vous pouvez vérifier votre contraste de couleurs dès maintenant avec notre outil Vérificateur de contraste. Il affiche instantanément les résultats WCAG AA et AAA.
Labels de formulaire manquants
Le problème : les utilisateurs de lecteurs d'écran ne savent pas à quoi sert un champ.
La solution : chaque champ de saisie a besoin d'un élément <label> visible lié par l'attribut for.
<!-- Bien -->
<label for="email">Adresse email</label>
<input type="email" id="email" name="email" />
<!-- Mauvais : le placeholder n'est pas un label -->
<input type="email" placeholder="Adresse email" />
Pas de navigation au clavier
Le problème : les utilisateurs qui ne peuvent pas utiliser une souris sont bloqués.
La solution : utilisez les éléments HTML natifs (<button>, <a>, <select>) qui sont accessibles au clavier par défaut. Si vous créez des composants personnalisés, assurez-vous qu'ils sont focalisables et répondent aux événements clavier. Ne supprimez jamais les contours de focus sans fournir une alternative.
Structure de page manquante
Le problème : les utilisateurs de lecteurs d'écran ne peuvent pas naviguer efficacement.
La solution : utilisez du HTML sémantique. Un seul <h1> par page, hiérarchie de titres logique (sans sauter de niveaux), landmarks (<nav>, <main>, <footer>).
Médias en lecture automatique
Le problème : un audio inattendu perturbe les utilisateurs de lecteurs d'écran. Une vidéo en lecture automatique peut provoquer des crises ou du stress.
La solution : ne lancez jamais automatiquement un audio. Si une vidéo se lance automatiquement, assurez-vous qu'elle est muette par défaut et fournit des contrôles de pause.
La couleur ne suffit pas
Ne comptez jamais uniquement sur la couleur pour transmettre une information. Considérez :
- Un champ de formulaire avec une bordure rouge pour les erreurs a aussi besoin d'une icône ou d'un message texte
- Un graphique avec des lignes colorées a aussi besoin de motifs, d'étiquettes ou d'une légende
- Un lien dans un texte a besoin d'un soulignement ou d'un autre indice visuel, pas uniquement d'un changement de couleur
Environ 8 % des hommes et 0,5 % des femmes ont une forme de déficience de la vision des couleurs. Concevoir en tenant compte de cela n'est pas un cas marginal — c'est de l'inclusivité fondamentale.
Tester l'accessibilité
Tests automatisés
Les outils automatisés détectent environ 30 à 40 % des problèmes d'accessibilité. C'est un bon premier pas, mais pas une solution complète.
- axe DevTools (extension navigateur) — analyse une page et signale les violations WCAG
- Lighthouse (intégré à Chrome DevTools) — inclut un audit d'accessibilité
- WAVE (outil web) — surcouche visuelle montrant les problèmes
Tests manuels
Beaucoup de problèmes d'accessibilité nécessitent un jugement humain :
- Test clavier : débranchez votre souris et naviguez sur tout votre site avec Tab, Entrée, Échap et les flèches. Pouvez-vous tout atteindre ? L'ordre de focus est-il logique ?
- Test lecteur d'écran : essayez VoiceOver (Mac), NVDA (Windows, gratuit) ou TalkBack (Android). Le contenu a-t-il du sens quand il est lu à voix haute ?
- Test zoom : zoomez votre navigateur à 200 %. La mise en page fonctionne-t-elle toujours ? Du contenu est-il coupé ou superposé ?
- Mouvement réduit : activez "réduire les animations" dans les paramètres de votre OS. Les animations respectent-elles cette préférence ?
Tests utilisateurs
Les retours les plus précieux viennent des personnes qui utilisent réellement les technologies d'assistance au quotidien. Si votre budget le permet, incluez des utilisateurs en situation de handicap dans votre processus de test.
L'accessibilité est un spectre, pas une case à cocher
L'accessibilité n'est pas un projet ponctuel avec une ligne d'arrivée. C'est une pratique continue. Les sites web évoluent, du contenu est ajouté, et de nouvelles barrières peuvent apparaître à chaque mise à jour.
L'objectif n'est pas la perfection. L'objectif est l'amélioration continue et une attention sincère envers les personnes qui utilisent ce que vous construisez. Commencez par les changements les plus impactants — contraste des couleurs, texte alternatif, navigation au clavier, labels de formulaire — et progressez à partir de là.
Chaque barrière que vous supprimez est une porte que vous ouvrez.
Checklist rapide
- Toutes les images ont un texte
altpertinent (oualt=""si décoratives) - Le contraste des couleurs respecte WCAG AA (4,5:1 pour le texte, 3:1 pour le gros texte)
- Tous les champs de formulaire ont des labels visibles
- Le site est entièrement navigable au clavier
- Les titres suivent une hiérarchie logique
- Les indicateurs de focus sont visibles
- La langue de la page est définie (attribut
langsur<html>) - Aucune information transmise uniquement par la couleur
- Les vidéos ont des sous-titres
- Les animations respectent
prefers-reduced-motion