Les WCAG (Web Content Accessibility Guidelines) fournissent un cadre technique pour rendre les contenus numériques utilisables par tous. Comprendre ce que recouvre un exemple WCAG, c’est identifier un critère précis, mesurable, applicable à une interface réelle. Ce n’est ni un principe abstrait, ni une recommandation vague : c’est un cas de test qu’un développeur ou un auditeur peut vérifier en quelques secondes sur une page web.
Critères WCAG 2.2 : exemples concrets par niveau de conformité
Chaque version des WCAG définit des critères de succès classés en trois niveaux. Un exemple WCAG correspond à l’application d’un de ces critères sur un élément d’interface. Le tableau ci-dessous illustre la différence entre niveaux à travers des cas directement observables.
A lire également : Qu'est-ce que RSS dans SharePoint ?
| Niveau | Critère | Exemple concret |
|---|---|---|
| A | Contenu non textuel (1.1.1) | Chaque image informative possède un attribut alt décrivant son contenu |
| A | Accessibilité au clavier (2.1.1) | Tous les boutons et liens sont atteignables et activables sans souris |
| AA | Contraste minimal (1.4.3) | Le texte courant affiche un ratio de contraste d’au moins 4,5:1 avec son arrière-plan |
| AA | Taille minimale de cible (2.5.8) | Les zones cliquables mesurent au moins 24 x 24 pixels CSS |
| AAA | Contraste renforcé (1.4.6) | Le ratio de contraste du texte atteint 7:1 |
Le niveau AA est celui que la plupart des réglementations exigent. Le niveau AAA reste un objectif rarement atteint sur l’ensemble d’un site, car certains de ses critères (comme la langue des signes pour tout contenu audio) impliquent des moyens considérables.
A lire en complément : Qu'est-ce qui est mieux, FastAPI ou Django ?
Focus clavier et bandeaux fixes : un exemple WCAG souvent ignoré
Un cas de test très parlant concerne la navigation au clavier en présence d’éléments fixes. Le critère 2.4.11, introduit dans WCAG 2.2, exige que l’élément recevant le focus ne soit pas masqué par un bandeau fixe. Bandeau de cookies, en-tête collant, module de chat : tous peuvent recouvrir le bouton ou le lien sur lequel l’utilisateur vient de tabuler.
Pour tester ce critère, il suffit de naviguer avec la touche Tab sur une page comportant un en-tête fixe. Si un lien reçoit le focus mais disparaît sous le bandeau, le critère est en échec. C’est un exemple WCAG directement reproductible, sans outil spécialisé.
En revanche, le critère autorise que l’élément soit partiellement masqué. L’exigence porte sur la visibilité totale, pas sur un positionnement parfait. La distinction est fine, mais elle change le verdict d’un audit.
Glisser-déposer et alternatives simples
WCAG 2.2 a aussi introduit l’obligation de proposer une alternative au glisser-déposer. Si une interface permet de réorganiser des éléments en les faisant glisser, un bouton « monter/descendre » ou un menu contextuel doit offrir la même fonction. Un utilisateur naviguant au clavier ou avec un dispositif de pointage limité ne peut pas effectuer un geste de drag-and-drop.
Ce type d’exemple montre que les WCAG ne se limitent pas au texte et aux images. Ils couvrent les interactions complexes, y compris celles apparues avec les interfaces modernes.
Contraste et texte : l’exemple WCAG le plus audité
Le ratio de contraste entre un texte et son arrière-plan reste le critère le plus fréquemment testé lors d’un audit d’accessibilité. Les outils de vérification automatique le détectent facilement, ce qui en fait un exemple WCAG de référence pour débuter une démarche de conformité.
- Un texte gris clair (#999) sur fond blanc (#FFF) affiche un ratio d’environ 2,8:1, insuffisant pour le niveau AA qui exige 4,5:1 minimum
- Un texte de grande taille (au moins 18 points ou 14 points en gras) bénéficie d’un seuil réduit à 3:1, car la lisibilité augmente avec la taille des caractères
- Les éléments décoratifs ou les logos ne sont pas soumis à cette exigence de contraste
Le contraste ne concerne pas uniquement le texte. Depuis WCAG 2.1, les composants d’interface (bordures de champs de formulaire, icônes fonctionnelles) doivent aussi respecter un ratio minimal de 3:1 avec leur environnement immédiat.
Authentification accessible : un critère WCAG récent et méconnu
WCAG 2.2 impose que l’authentification ne repose pas uniquement sur un test cognitif. Concrètement, demander à un utilisateur de résoudre un puzzle visuel ou de mémoriser un mot de passe complexe sans alternative constitue un échec de conformité.
Les alternatives conformes incluent l’autocomplétion du navigateur (attribut autocomplete), l’authentification par lien envoyé par courriel ou la connexion via un gestionnaire de mots de passe. L’objectif est de ne pas créer une barrière cognitive à l’entrée d’un service.
Ce critère illustre bien la portée actuelle des WCAG. Ils ne se cantonnent plus au contenu affiché : les parcours utilisateur complets, de la connexion à la validation d’un formulaire, sont concernés.
Documents numériques et au-delà des pages web
Un exemple WCAG peut aussi s’appliquer à un fichier PDF ou à un document bureautique transmis par un service en ligne. Un PDF sans structure de titres balisés, sans texte alternatif sur les images, ou avec un ordre de lecture incohérent échoue aux mêmes critères qu’une page HTML mal construite.
L’European Accessibility Act, applicable à partir de juin 2025, étend ces obligations à des secteurs comme le commerce en ligne et les services bancaires. Les exemples WCAG deviennent alors des cas de test pour des audits réglementaires, pas seulement des bonnes pratiques techniques.
Un exemple WCAG n’est pas une illustration théorique. C’est un cas de test binaire : un élément d’interface passe ou échoue. Tabuler, mesurer un contraste, vérifier un attribut alt, chaque critère se traduit par une action vérifiable. C’est cette granularité qui rend les WCAG exploitables au quotidien par les équipes de développement et les auditeurs.
