Accessibilité web : guide pratique WCAG 2.2 et conception sans barrières

Introduction

Environ un adulte sur quatre dans l’UE vit avec une forme de handicap. Pour beaucoup d’entre eux, la question de savoir s’ils peuvent utiliser votre site web n’est pas une gêne mineure — c’est la différence entre accomplir une tâche de façon autonome ou ne pas pouvoir l’accomplir du tout.

L’accessibilité est aussi devenue une exigence légale de base. L’European Accessibility Act (EAA) s’applique à un large éventail de produits et services numériques à partir de juin 2025. Mais même pour les équipes pas encore soumises à la réglementation, l’argument pratique est difficile à contester : meilleure structure, meilleur SEO, portée plus large et moins d’utilisateurs frustrés.

Ce guide couvre ce que l’accessibilité web signifie en pratique — cinq barrières spécifiques que votre site présente peut-être déjà, comment le cadre WCAG 2.2 s’applique à des décisions concrètes, et une liste de contrôle pour prioriser le travail.

Cinq barrières que votre site crée peut-être déjà

La majorité des problèmes d’accessibilité sur le web se concentrent dans une courte liste de patterns récurrents. Voici les cinq barrières qui excluent le plus grand nombre d’utilisateurs.

1. Du texte difficile ou impossible à lire

Faible contraste, petites tailles de police et langage trop complexe se cumulent. Un utilisateur avec une déficience visuelle modérée peut gérer l’un de ces problèmes — rarement les trois à la fois.

La base pratique : le texte courant devrait s’afficher à 15–16 px minimum, avec un rapport de contraste d’au moins 4,5:1 par rapport à son arrière-plan (le seuil WCAG AA). Pour le grand texte (18 px ou 14 px en gras et plus), le seuil descend à 3:1. Des outils comme le vérificateur de contraste WebAIM permettent de vérifier n’importe quelle paire de couleurs en quelques secondes.

Le langage clair est plus difficile à tester automatiquement, mais il compte énormément pour les utilisateurs avec des handicaps cognitifs ou un niveau de lecture plus faible. Des phrases courtes, la voix active et éviter le jargon non expliqué aident considérablement.

2. Des images sans alternative textuelle

Un utilisateur avec un lecteur d’écran rencontre une image et n’entend rien — ou pire, un nom de fichier brut comme img_20240312_banner_v3.jpg lu à voix haute mot pour mot.

La solution est le texte alt : une description courte et précise de ce que montre l’image et, le cas échéant, de ce qu’elle communique. Les images décoratives sans signification doivent porter un attribut alt="" vide pour que les lecteurs d’écran les ignorent entièrement. Les images contenant du texte sont un problème particulier — le contenu textuel devrait figurer dans le document lui-même plutôt qu’être intégré dans un graphique.

C’est l’une des corrections les plus rapides en matière d’accessibilité et l’une des plus systématiquement négligées. Chaque image sur votre site devrait avoir soit un texte alt descriptif, soit être explicitement marquée comme décorative.

3. Vidéos et audio sans sous-titres ni transcriptions

Un utilisateur sourd ou malentendant ne peut pas accéder au contenu audio uniquement. Un utilisateur avec des difficultés cognitives ou d’attention peut traiter une transcription écrite bien plus efficacement qu’une narration audio. Les sous-titres — texte synchronisé qui apparaît pendant la lecture de la vidéo — s’adressent au premier groupe. Les transcriptions complètes disponibles séparément s’adressent aux deux.

Pour le contenu marketing, les démonstrations de produits et les webinaires, les sous-titres sont désormais largement attendus. Le sous-titrage automatique est disponible dans la plupart des plateformes d’hébergement vidéo et s’est nettement amélioré, mais les sous-titres générés automatiquement pour les termes techniques et les noms de produits nécessitent une révision avant publication.

4. Pièges clavier et navigation inaccessible

Tous les utilisateurs n’interagissent pas avec un site web à l’aide d’une souris. Les utilisateurs avec des déficiences motrices, les utilisateurs de lecteurs d’écran et les utilisateurs préférant le clavier naviguent tous via Tab, Entrée et les touches fléchées. Un site utilisable uniquement avec un dispositif de pointage exclut une part significative de ce groupe.

L’accessibilité clavier a des exigences concrètes : chaque élément interactif — liens, boutons, champs de formulaire, menus déroulants, dialogues — doit être accessible via Tab ; la position de focus actuelle doit être visuellement indiquée à tout moment ; les modales ne doivent pas créer de pièges ; et l’ordre de focus doit suivre une séquence logique correspondant à la disposition visuelle.

Ce test nécessite cinq minutes et aucun outil : posez la souris et naviguez sur votre site uniquement avec Tab, Maj+Tab, Entrée et les touches fléchées. Si vous vous retrouvez bloqué, ne voyez pas où vous êtes ou ne pouvez pas activer des éléments, vous avez des problèmes d’accessibilité clavier.

5. Des formulaires et CAPTCHAs qui créent des barrières insurmontables

Les formulaires sont là où les enjeux de l’accessibilité sont les plus élevés. Les pages de contact, les flux de connexion, les écrans d’inscription et les pages de paiement sont fonctionnels — un utilisateur qui ne peut pas compléter un formulaire ne peut pas atteindre l’objectif pour lequel il est venu.

Les CAPTCHAs à images traditionnels figurent parmi les problèmes d’accessibilité les mieux documentés en conception web. La tâche d’identifier des lettres déformées ou de sélectionner des images contenant des objets spécifiques est explicitement problématique pour les utilisateurs avec des déficiences visuelles, des handicaps cognitifs et les utilisateurs de lecteurs d’écran. Les alternatives audio aident — mais elles présentent leurs propres difficultés pour les utilisateurs avec des déficiences auditives.

WCAG 2.2 traite cela directement. Le critère de succès 3.3.8 (Authentification accessible) exige explicitement que les processus d’authentification ne reposent pas uniquement sur des tests de fonction cognitive — une catégorie qui inclut entièrement les CAPTCHAs à puzzles.

La solution pratique est de se débarrasser entièrement des CAPTCHAs à challenges. TrustCaptcha exécute la détection de bots de façon invisible en arrière-plan pendant qu’un utilisateur remplit un formulaire — aucun puzzle à résoudre, aucune image à interpréter, rien à cliquer. La vérification se déroule pendant l’interaction normale, sans interrompre le flux du formulaire pour aucun utilisateur. Cette approche s’aligne sur WCAG 2.2 SC 3.3.8 et supprime l’une des barrières actives les plus courantes là où les utilisateurs ont le plus besoin de réussir.

Ce que WCAG 2.2 requiert réellement

Les Web Content Accessibility Guidelines (WCAG) sont la norme internationale pour l’accessibilité du contenu web. Publiées par le W3C, elles constituent la base de la plupart des exigences légales d’accessibilité nationales et au niveau de l’UE. La version actuelle est WCAG 2.2, publiée en octobre 2023.

WCAG est organisé autour de quatre principes : le contenu doit être Perceptible, Utilisable, Compréhensible et Robuste — souvent désigné par l’acronyme POUR. Chaque principe se décompose en directives, qui se décomposent en critères de succès testables.

Les niveaux de conformité déterminent ce que “conforme” signifie en pratique :

• Niveau A — le minimum. Ne pas satisfaire les critères de niveau A crée de sérieuses barrières pour les utilisateurs de technologies d’assistance.
• Niveau AA — l’objectif légal dans la plupart des pays, y compris les exigences d’accessibilité de l’UE. C’est ce que “conformité WCAG” signifie généralement.
• Niveau AAA — le niveau le plus élevé, non requis par la loi et souvent impraticable pour des sites entiers, mais réalisable pour des composants spécifiques prioritaires.

WCAG 2.2 a ajouté neuf nouveaux critères de succès par rapport à WCAG 2.1. Les ajouts les plus significatifs pour la plupart des équipes concernent l’apparence du focus (rendre les états de focus clavier plus visibles), l’authentification accessible (affectant directement la conception des CAPTCHAs et des flux de connexion) et les alternatives aux interactions glisser-déposer. WCAG 2.2 est rétrocompatible — satisfaire 2.2 AA satisfait automatiquement tous les critères 2.1 AA, avec une exception supprimée (4.1.1 Parsing, déprécié dans la version 2.2).

Pour la plupart des sites web d’entreprise, atteindre WCAG 2.2 Niveau AA est l’objectif approprié et légalement pertinent.

Une liste de contrôle d’accessibilité utilisable dès aujourd’hui

Ce n’est pas un audit exhaustif — c’est un point de départ pratique organisé par domaine. Parcourez-le depuis le début.

Texte et présentation visuelle

• Le texte courant s’affiche à 15 px ou plus
• Le rapport de contraste est d’au moins 4,5:1 pour le texte courant, 3:1 pour le grand texte
• Le texte peut être agrandi à 200 % dans le navigateur sans perte de contenu ou de fonction
• Aucun contenu n’est présenté sous forme de texte dans une image (sauf logos et graphiques décoratifs)
• La langue et le niveau de lecture sont adaptés à votre audience cible

Images et médias

• Chaque image significative a un texte alt précis
• Les images décoratives portent alt=""
• Les vidéos ont des sous-titres précis et synchronisés
• Le contenu audio uniquement dispose d’une transcription écrite

Clavier et navigation

• Tous les éléments interactifs sont accessibles et utilisables au clavier seul
• L’indicateur de focus est clairement visible à tout moment
• Aucun piège clavier dans les modales, dialogues ou composants personnalisés
• Un lien “aller au contenu principal” apparaît en haut de chaque page
• L’ordre de tabulation correspond à la séquence de lecture visuelle

Formulaires et authentification

• Les labels de formulaire sont associés programmatiquement à leurs champs via for/id ou aria-labelledby
• Les messages d’erreur identifient quel champ a échoué et expliquent comment corriger
• Aucune limite de temps imposée sur la complétion du formulaire, sauf si ajustable
• Aucun CAPTCHA nécessitant de résoudre un puzzle d’images ou un challenge audio
• Les flux d’authentification n’exigent pas de tests de fonction cognitive (WCAG 2.2 SC 3.3.8)

Structure et sémantique

• Les titres suivent une hiérarchie logique sans niveaux sautés
• Les régions de repère sont utilisées (header, nav, main, footer)
• Chaque page a un élément <title> descriptif et unique
• Les liens utilisent un texte d’ancre descriptif, pas “cliquez ici” ou “lire la suite”
• Les tableaux définissent les en-têtes avec <th> et les attributs scope appropriés

Comment prioriser si vous partez de zéro

Un audit d’accessibilité complet d’un site mature peut révéler des centaines de problèmes. L’approche la plus efficace en partant sans travail d’accessibilité préalable est de séquencer l’effort par impact et effort, plutôt que d’essayer de tout résoudre en même temps.

Deux premières semaines : Corrigez les éléments à fort impact et faible effort. Cela correspond presque toujours au texte alt des images manquant, aux défaillances de contraste et aux associations de labels de formulaire manquantes. Faites passer votre site dans Lighthouse (intégré dans Chrome DevTools) ou l’extension navigateur WAVE et résolvez tout ce qui est signalé comme une erreur — pas un avertissement, une erreur. Ce sont des détections automatisées représentant des défaillances graves.

Mois suivant : Traitez la navigation au clavier et la gestion du focus. Cela nécessite des tests manuels et implique souvent de travailler avec un développeur sur des composants interactifs — modales, menus déroulants, contrôles de formulaires personnalisés — que les outils automatisés évaluent incomplètement. Remplacez tout CAPTCHA à puzzle pendant cette phase ; c’est un changement à fort impact avec une implémentation technique simple.

En continu : L’accessibilité structurelle et de contenu — hiérarchie des titres, niveau de lecture, sous-titres pour les nouveaux contenus vidéo — devient une partie de votre processus de production plutôt qu’un effort de remédiation ponctuel.

Atteindre une base WCAG 2.2 AA pour un site web d’entreprise typique demande deux à quatre semaines de travail de développement concentré, plus pour les sites avec des composants interactifs complexes ou de vastes archives de contenu.

Conclusion

L’accessibilité n’est pas un audit ponctuel ni une case à cocher de conformité. C’est un standard de qualité continu — et la barre fixée par WCAG 2.2 Niveau AA est à la fois atteignable et de plus en plus attendue. Les cinq barrières décrites ici représentent la grande majorité des problèmes qui excluent les utilisateurs des sites web. La plupart se corrigent plus rapidement que les équipes ne le pensent.

L’une des améliorations les plus rapides pour l’accessibilité des formulaires est de remplacer un CAPTCHA à puzzles par une solution conçue pour une vérification invisible et sans barrières. 👉 Essayez TrustCaptcha gratuitement — conforme WCAG 2.2, hébergement UE inclus dans chaque plan.