Rendre un site web accessible : comment faire pour que tout le monde puisse utiliser votre site

Un site web peut parfaitement s’afficher sur votre ordinateur portable et pourtant être presque inutilisable pour quelqu’un d’autre. Pensez à un visiteur qui n’utilise pas de souris, agrandit fortement le texte, navigue avec un lecteur d’écran, ne peut pas lire de son, ou ne peut temporairement utiliser qu’une seule main. Rendre un site web accessible signifie tenir compte de ce type de situations dans votre design, vos contenus et votre code.

Cela ne doit pas commencer par un dossier juridique ou une longue liste de termes techniques. La meilleure première étape est bien plus simple : essayez d’utiliser votre propre site web d’une manière différente de celle à laquelle vous êtes habitué. Où êtes-vous bloqué ? Quelles informations disparaissent ? Quel bouton n’est utilisable qu’avec une souris ? De petits tests comme ceux-là montrent rapidement où se trouvent les véritables obstacles.

Que signifie rendre un site web accessible ?

L’accessibilité numérique ne concerne pas une version séparée et simplifiée de votre site web. L’objectif est justement que le même site puisse être utilisé par davantage de personnes, avec différents appareils et technologies d’assistance.

Pour une personne aveugle ou malvoyante, cela peut signifier qu’un lecteur d’écran peut lire la page dans un ordre logique. Pour une personne ayant une limitation motrice, le site doit être utilisable sans souris. Les sous-titres aident les personnes sourdes et malentendantes, mais aussi quelqu’un qui regarde une vidéo dans un train sans son. Un bon contraste aide les personnes ayant une vision réduite et toute personne qui consulte un écran très lumineux à l’extérieur.

Les directives internationales WCAG rassemblent ces exigences en quatre principes : le contenu doit être perceptible, utilisable, compréhensible et robuste. WCAG 2.2 est la version actuelle du W3C et ajoute notamment des critères supplémentaires concernant le focus, les cibles tactiles, le glisser-déposer et l’authentification accessible.

Commence d’abord par cette vérification rapide de l’accessibilité

Tu n’as pas besoin d’être développeur pour repérer les premiers problèmes. Ouvre ton site web et essaie les contrôles suivants :

• Pose ta souris. Peux-tu naviguer dans les menus, boutons, formulaires et pop-ups avec Tab, Shift+Tab, Entrée et Échap ?
• Agrandis la page à 200 %. Le texte reste-t-il lisible et le contenu important reste-t-il utilisable, sans que des éléments se chevauchent ou disparaissent ?
• Consulte la page sur ton téléphone et agrandis-y aussi le texte. Peux-tu encore accéder au menu, aux boutons des cookies et aux actions principales ?
• Ouvre un formulaire et fais volontairement une erreur. Est-il clair quel champ est erroné, pourquoi, et comment le corriger ?
• Coupe le son d’une vidéo. Le message reste-t-il compréhensible grâce à des sous-titres ou à une alternative textuelle ?
• Regarde les liens et les boutons. Comprends-tu encore leur fonction si tu n’entendais que le texte du lien ou du bouton ?

Si tu veux suivre une première vérification neutre, W3C Easy Checks propose une série de tests manuels simples. Considère cela comme un premier dépistage, et non comme un audit complet.

1. Assure-toi que l’ensemble du site web fonctionne au clavier

L’un des tests les plus utiles est étonnamment simple : utilisez votre site web sans souris. Avec la touche Tab, vous devez pouvoir passer d’un élément interactif à un autre. Avec Entrée ou Espace, vous devez pouvoir exécuter des actions, et avec Échap, vous devez par exemple pouvoir fermer un menu ou une boîte de dialogue ouverte lorsque cela est logique.

Faites particulièrement attention aux menus de navigation, aux bannières de cookies, aux filtres, aux formulaires, aux sliders et aux pop-ups. Ce sont souvent les endroits où un site web a l’air bien visuellement, mais où les utilisateurs au clavier se retrouvent bloqués.

Ceux qui veulent rendre un site web accessible aux visiteurs aveugles et malvoyants en tirent aussi profit : les lecteurs d’écran fonctionnent bien mieux lorsque la commande sous-jacente et l’ordre sont logiques.

2. Montrez toujours où se trouve le focus clavier

Lorsque vous naviguez dans une page avec Tab, vous devez pouvoir voir quel élément est actif. Un contour de focus clair autour d’un lien, d’un bouton ou d’un champ de saisie évite que l’utilisateur doive deviner où il se trouve sur la page.

Ne supprimez donc pas le style de focus par défaut simplement parce qu’un designer trouve le contour peu esthétique. Vous pouvez personnaliser le focus selon votre charte graphique, tant qu’il reste visible et qu’il contraste suffisamment avec son environnement.

WCAG 2.2 accorde une attention particulière au focus : un élément actif ne doit pas disparaître entièrement derrière d’autres contenus. Cela est par exemple pertinent avec les en-têtes fixes (sticky headers), les panneaux de cookies et les boutons de chat fixes.

3. Structurez votre page avec de vrais titres, logiques

Un H1, H2 ou H3 n’est pas un moyen de rendre le texte plus grand. Les titres décrivent la structure de la page. Cela permet aux visiteurs de parcourir rapidement la page, et aux lecteurs d’écran de sauter de titre en titre.

Utilisez un seul titre de page clair, puis continuez de manière hiérarchique. Un H3 doit se trouver sous un H2, non pas parce que la taille de police convient mieux, mais parce qu’il fait, sur le fond, partie de ce H2.

Cette même rigueur est également bénéfique pour les moteurs de recherche : Google recommande des titres descriptifs, des en-têtes clairs et un HTML sémantique. Cela ne signifie pas que la conformité aux WCAG est en soi un facteur de classement. L’accessibilité est avant tout destinée aux utilisateurs ; certaines bonnes pratiques recoupent simplement de bonnes pratiques SEO.

4. Vérifiez le contraste, la taille du texte et le zoom

Un texte gris clair sur fond blanc peut sembler élégant, mais il est difficile à lire pour beaucoup de personnes. Il en va de même pour du texte posé sur une photo ou pour un bouton dont le texte et l’arrière-plan se distinguent à peine.

Les WCAG utilisent des critères de contraste mesurables. Pour le texte courant, 4,5:1 est un seuil AA bien connu ; pour le texte de grande taille, c’est généralement 3:1. Par ailleurs, ne faites pas de la couleur le seul moyen de communiquer une erreur, un statut ou un choix.

Testez aussi ce qui se passe lorsque quelqu’un agrandit le texte. Le visiteur ne doit pas perdre d’informations importantes parce que des éléments sortent de l’écran, se chevauchent ou ne sont lisibles qu’avec un défilement horizontal.

5. Rédigez des textes alternatifs (alt) qui expliquent la fonction d’une image

Le texte alternatif n’est pas un endroit où caser des mots-clés supplémentaires. C’est une alternative textuelle pour quelqu’un qui ne voit pas l’image. Décrivez donc ce que l’image apporte dans ce contexte précis.

Une photo purement décorative n’a généralement pas besoin de texte descriptif et peut recevoir une valeur alt vide. En revanche, un graphique contenant des chiffres importants demande davantage d’explications qu’une seule courte phrase. Mettez donc l’essentiel dans le texte normal ou fournissez une description plus longue.

Un bon texte alternatif peut être utile à la fois pour l’accessibilité et pour Google Images, mais rédigez-le d’abord pour l’utilisateur. Une suite de mots-clés n’aide personne.

6. Rendez les textes des liens et des boutons compréhensibles sans contexte visuel

Un utilisateur de lecteur d’écran peut faire résumer une page sous forme de liste de liens. Dix fois « cliquez ici » ne veut alors rien dire. Utilisez des textes qui décrivent la destination ou l’action : « Découvrez nos services de webmaster » est par exemple plus clair que « Plus d’infos ».

Il en va de même pour les boutons avec icône. Une loupe est reconnaissable comme « recherche » pour beaucoup de visiteurs voyants, mais un lecteur d’écran a besoin d’un nom accessible. Utilisez, lorsque possible, de vrais boutons HTML avec un texte ou un nom clair.

7. Veillez à ce que les formulaires restent compréhensibles même en cas d’erreur

Les formulaires de contact et de paiement sont des éléments commercialement importants d’un site web. C’est précisément là que les problèmes d’accessibilité se font souvent durement sentir : libellés invisibles, champs obligatoires peu clairs, messages d’erreur qui ne font que passer en rouge, ou un formulaire qui, après une erreur, revient en haut sans explication.

Donnez à chaque champ un véritable libellé, indiquez clairement quelles informations sont attendues et décrivez les erreurs en langage courant. « Saisie invalide » est moins utile que « Saisissez une adresse e-mail valide, par exemple nom@entreprise.be ».

Vérifiez aussi que le message d’erreur est lié par programmation au champ concerné. C’est un travail technique, mais cela fait une grande différence pour les lecteurs d’écran.

8. Prévoyez des alternatives pour la vidéo et l’audio

Si des informations importantes ne sont communiquées qu’à l’oral, vous excluez les personnes qui ne peuvent pas entendre le son. De bons sous-titres aident les personnes sourdes et malentendantes et sont aussi pratiques dans les environnements où le son est indésirable.

Pour l’audio, une transcription peut être une bonne solution. Pour les vidéos où des informations pertinentes n’apparaissent que visuellement, une description supplémentaire peut être nécessaire. L’alternative adéquate dépend du contenu ; un sous-titrage généré automatiquement sans vérification n’est pas toujours suffisant.

9. N’oubliez pas les menus, les pop-ups et les bannières de cookies

Un site web peut être assez accessible sur ses pages « normales » et pourtant échouer à cause d’une seule superposition. Une bannière de cookies qui bloque toute la page mais qui ne peut pas être fermée au clavier rend le reste du site pratiquement inaccessible.

Testez donc séparément les menus de navigation, les modales, les fenêtres de chat, les filtres, les préférences de cookies et les autres couches. Le focus doit aller vers une boîte de dialogue ouverte, l’utilisateur doit comprendre ce qui s’est ouvert et, après la fermeture, pouvoir reprendre logiquement.

Ce sont des points typiques que l’on ne résout pas simplement en ajoutant quelques textes alternatifs. Parfois, il faut adapter la structure HTML ou l’interaction JavaScript.

10. Sur mobile, pensez au toucher, à la rotation et au zoom

L’accessibilité ne s’arrête pas au bureau. De petits boutons très proches les uns des autres sont difficiles pour une personne ayant une motricité fine limitée, mais aussi pour toute personne qui navigue en déplacement d’une seule main.

WCAG 2.2 contient un critère AA concernant la taille minimale de nombreuses cibles tactiles, avec des exceptions. En pratique, le message est simple : donnez suffisamment d’espace aux boutons et aux liens, et évitez qu’un utilisateur doive viser une icône minuscule.

Vérifiez aussi si les fonctions importantes continuent de fonctionner lorsque l’écran est pivoté et lorsque le texte est agrandi via les options d’accessibilité d’iOS ou d’Android.

11. Écrivez de façon claire et prévisible

L’accessibilité technique est importante, mais la compréhension l’est tout autant. Utilisez des intitulés cohérents dans votre navigation, ne cachez pas les informations importantes dans de longs paragraphes et faites en sorte que les boutons fassent ce que leur texte promet.

Évitez les instructions qui ne renvoient qu’à une couleur ou à une position, comme « cliquez sur le bouton vert à droite ». Cette indication ne fonctionne pas pour tout le monde et peut même être factuellement inexacte sur mobile.

Une structure claire, des messages d’erreur explicites et un langage simple rendent un site web non seulement plus accessible, mais réduisent aussi l’hésitation des visiteurs qui veulent simplement trouver ou commander quelque chose rapidement.

12. Utilisez du HTML sémantique et n’utilisez ARIA que là où c’est nécessaire

Une grande partie de l’accessibilité commence dans le code source. Un vrai bouton, une étiquette de formulaire correcte, un élément nav et un niveau de titres logique portent déjà une signification que les navigateurs et les technologies d’assistance comprennent.

Les attributs ARIA peuvent fournir des informations supplémentaires lorsque le HTML standard ne suffit pas, mais ils ne sont pas un pansement pour un balisage médiocre. Un élément visuel qui se comporte comme un bouton se construit de préférence comme un vrai bouton, plutôt que comme une div générique avec une pile d’attributs supplémentaires.

C’est aussi pour cela qu’un widget d’accessibilité ne peut jamais résoudre automatiquement tous les problèmes d’un site web. Si la structure de base, les formulaires ou les interactions sont mal construits, le site sous-jacent doit être adapté.

Que signifient WCAG 2.2 et l’EAA pour les entreprises belges ?

WCAG et l’European Accessibility Act (EAA) ne sont pas la même chose. WCAG est une norme technique internationale pour l’accessibilité du web. L’EAA est une législation européenne qui impose des exigences d’accessibilité à certains produits et services.

En Belgique, les règles sont pertinentes depuis le 28 juin 2025 notamment pour les services de commerce électronique et les services bancaires destinés aux consommateurs. SPF Économie mentionne à ce sujet que les micro-entreprises — moins de dix travailleurs et un chiffre d’affaires annuel ou un total du bilan inférieur à 2 millions d’euros — disposent de cinq années supplémentaires pour se conformer à la nouvelle réglementation belge.

Cela ne signifie pas que chaque site web d’entreprise ordinaire relève automatiquement de l’EAA exactement de la même manière. La question dépend de ce que votre entreprise propose, à qui vous fournissez des services et quelles parties de la réglementation s’appliquent à votre situation. Une boutique en ligne qui vend aux consommateurs nécessite par exemple une évaluation différente d’un simple site d’information B2B.

Si votre entreprise est soumise aux règles, il ne s’agit pas seulement du contraste des couleurs ou des textes alternatifs. FOD Economie souligne aussi l’importance d’informations claires sur le service, de plateformes numériques utilisables et de la compatibilité avec les technologies d’assistance.

Ce paragraphe constitue une information générale et ne représente pas un avis juridique. En cas de doute sur les obligations légales de votre entreprise, il est judicieux de vérifier les directives actuelles de FOD Economie ou de solliciter un conseil spécialisé.

Un vérificateur WCAG automatique peut-il dire si votre site est accessible ?

Non. Un scan automatique est pratique pour trouver rapidement certaines erreurs techniques, mais un tableau de score au vert n’est pas la preuve que de vraies personnes peuvent utiliser votre site web sans barrières.

Un outil peut par exemple signaler des attributs alt manquants ou certains problèmes de contraste. Mais il ne comprend pas automatiquement si un texte alternatif est pertinent sur le fond, si un message d’erreur est compréhensible, si l’ordre de focus paraît logique et si un processus de paiement complexe est réellement utilisable avec un lecteur d’écran.

W3C recommande donc une évaluation plus large. Combinez des contrôles automatiques avec des tests manuels au clavier, le zoom, la vérification des formulaires, des tests avec des lecteurs d’écran et — lorsque c’est possible — les retours de personnes qui utilisent elles-mêmes des technologies d’assistance.

Quand avez-vous besoin d’une aide technique ?

Les gestionnaires de contenu peuvent déjà améliorer beaucoup de choses eux-mêmes : des titres clairs, de meilleurs textes de liens, des textes alternatifs utiles, des sous-titres et des textes de formulaires compréhensibles. Mais certains problèmes sont plus profonds et viennent du thème, du constructeur de pages, des plug-ins ou du code sur mesure.

Faites appel à une aide technique lorsque la navigation au clavier ne fonctionne pas, que le focus disparaît, que des menus ou des modales se bloquent, que des libellés de formulaire manquent dans le HTML, que l’ordre de lecture est incorrect ou que le site se désagrège lors de l’agrandissement. Un checkout ou un portail client mérite aussi une attention particulière, car un seul blocage peut y coûter directement une demande ou une vente.

Parfois, un contrôle d’accessibilité révèle que le site existant est techniquement difficile à corriger. Dans ce cas, faire refaire votre site web peut être plus judicieux que de continuer à empiler des correctifs. Pour des ajustements ciblés et un suivi, vous pouvez aussi consulter les services de webmaster de Moonbeetle.

Questions fréquentes sur un site web accessible

Comment savoir si mon site web est accessible ?

Commencez par des vérifications manuelles : utilisez le site sans souris, agrandissez le texte, vérifiez les formulaires et essayez les éléments importants avec un lecteur d’écran. Un scanner automatique peut trouver des erreurs supplémentaires, mais pour une évaluation fiable, un audit plus large est nécessaire.

Chaque site web belge doit-il se conformer à l’EAA ?

Pas automatiquement de la même manière. L’EAA et la transposition belge visent certains produits et services. Pour l’e-commerce et les services bancaires destinés aux consommateurs, des règles spécifiques s’appliquent. Les obligations exactes dépendent de votre activité et de votre entreprise.

WCAG 2.2 est-il obligatoire pour mon site web ?

WCAG 2.2 est la norme actuelle du W3C et un objectif pratique solide pour les sites web nouveaux ou modifiés. La version ou la norme juridiquement applicable dépend du cadre légal pertinent. Utilisez donc WCAG comme base technique, mais vérifiez séparément les obligations légales.

L’accessibilité aide-t-elle à mieux se positionner sur Google ?

L’accessibilité n’est pas un facteur de classement général permettant de prévoir une position. Il existe toutefois un recoupement avec un bon SEO : Google utilise par exemple le texte alternatif pour mieux comprendre les images et recommande un HTML sémantique, des titres clairs et des liens descriptifs. La raison principale de concevoir accessible reste que davantage de personnes peuvent utiliser votre site web.

Un plugin d’accessibilité peut-il rendre mon site web conforme aux WCAG ?

Un plugin ou un widget peut améliorer certaines fonctions, mais ne peut pas corriger automatiquement des problèmes structurels dans le HTML, les formulaires, la navigation au clavier ou les composants interactifs. Considérez un tel outil comme une aide possible, et non comme un substitut à une bonne conception, au développement et aux tests.

Dois-je adapter tout mon site web en une seule fois ?

Pas toujours. Commencez par les parcours utilisateurs les plus importants : navigation, formulaire de contact, demande de devis, connexion et — pour une boutique en ligne — page produit, panier et paiement. Supprimez d’abord les blocages, puis poursuivez de manière systématique.

Sources pour une vérification plus approfondie

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• W3C — Easy Checks: A First Review of Web Accessibility
• SPF Économie — Directive sur l’accessibilité : un pas de plus vers une société inclusive
• Belgian Web Accessibility — informations et outils autour de l’accessibilité numérique