Accessibilité web WCAG : checklist pratique pour votre site
Checklist concrète d'accessibilité web WCAG pour PME suisses. Contraste, textes alternatifs, navigation clavier, ARIA et obligations légales en Suisse.
L’accessibilité web consiste à rendre votre site utilisable par toutes les personnes, y compris celles en situation de handicap. En Suisse, environ 1,8 million de personnes vivent avec un handicap. Ignorer l’accessibilité, c’est exclure une part significative de votre clientèle potentielle.
Au-delà de l’obligation morale, l’accessibilité web présente des avantages concrets pour votre PME : meilleur référencement, meilleure expérience utilisateur pour tous et conformité avec les exigences légales qui se renforcent.
Ce guide propose une checklist pratique basée sur les directives WCAG (Web Content Accessibility Guidelines), adaptée aux PME suisses romandes.
Le cadre légal en Suisse
La Loi sur l’égalité pour les handicapés (LHand)
La LHand impose aux organismes publics et aux entreprises proposant des prestations en ligne de rendre leurs sites accessibles. Si cette obligation vise principalement les administrations, la tendance est clairement à l’élargissement vers le secteur privé.
L’European Accessibility Act (EAA)
Entré en vigueur dans l’Union européenne en juin 2025, l’European Accessibility Act impose des exigences d’accessibilité aux services numériques. Bien que la Suisse ne soit pas membre de l’UE, les entreprises suisses qui servent des clients européens ou qui souhaitent anticiper l’évolution du droit suisse ont tout intérêt à s’y conformer.
Le niveau WCAG à viser
Les WCAG définissent trois niveaux de conformité : A (minimum), AA (recommandé) et AAA (optimal). Pour une PME, le niveau AA est le standard à viser. C’est celui exigé par la plupart des législations et recommandé par la Confédération suisse.
Checklist : perception du contenu
Contrastes de couleurs
Le texte doit être suffisamment contrasté par rapport à son arrière-plan pour être lisible par les personnes malvoyantes ou dans des conditions d’éclairage défavorable (écran en plein soleil).
Critères WCAG AA :
- Texte normal : ratio de contraste minimum de 4,5:1
- Texte large (18px bold ou 24px normal) : ratio minimum de 3:1
- Éléments d’interface (boutons, champs de formulaire) : ratio minimum de 3:1
Outils de vérification :
- WebAIM Contrast Checker (gratuit en ligne)
- L’inspecteur de Chrome DevTools affiche le ratio de contraste directement
Erreur fréquente : un texte gris clair (#999) sur fond blanc (#FFF) a un ratio de 2,85:1, insuffisant pour le niveau AA.
Textes alternatifs (alt text)
Chaque image porteuse de sens doit avoir un attribut alt descriptif. Ce texte est lu par les lecteurs d’écran et affiché si l’image ne se charge pas.
Bonnes pratiques :
- Décrire le contenu de l’image, pas son apparence : “L’équipe tacelo devant ses bureaux à Vétroz” plutôt que “photo d’équipe”
- Les images purement décoratives doivent avoir un
alt=""vide (pas d’attribut manquant, mais un attribut vide) - Les images contenant du texte doivent reproduire ce texte dans le
alt - Les boutons avec uniquement une icône doivent avoir un
aria-labeldescriptif
Le SEO des images bénéficie aussi d’attributs alt bien rédigés. C’est un cas où accessibilité et référencement vont de pair.
Sous-titres et transcriptions
Les contenus audio et vidéo doivent proposer des alternatives textuelles :
- Sous-titres pour les vidéos (pas les sous-titres automatiques de YouTube, qui contiennent des erreurs)
- Transcriptions pour les podcasts et contenus audio
- Audio-description pour les vidéos dont le contenu visuel est essentiel à la compréhension
Hiérarchie des titres
Les titres (h1, h2, h3…) ne sont pas de simples choix visuels. Ils structurent le contenu pour les lecteurs d’écran et permettent aux utilisateurs de naviguer rapidement entre les sections.
Règles à respecter :
- Un seul h1 par page (le titre principal)
- Les niveaux ne sautent pas (pas de h1 suivi directement d’un h3)
- Chaque titre résume le contenu de sa section
- Ne pas utiliser un titre uniquement pour grossir du texte (utiliser CSS pour cela)
Checklist : navigation et interaction
Navigation au clavier
Toutes les fonctionnalités du site doivent être utilisables sans souris, uniquement au clavier. C’est essentiel pour les personnes à mobilité réduite qui utilisent un clavier ou un périphérique alternatif.
Points à vérifier :
- Tab permet de naviguer entre tous les éléments interactifs (liens, boutons, champs)
- Entrée ou Espace active les boutons et liens
- L’ordre de tabulation suit un ordre logique (de gauche à droite, de haut en bas)
- Le focus est toujours visible (ne jamais supprimer le outline avec
outline: nonesans alternative) - Les menus déroulants sont navigables au clavier
- Il n’y a pas de piège au clavier (l’utilisateur peut toujours quitter un élément avec Tab ou Escape)
Liens et boutons
- Les liens ont un texte descriptif : “Voir nos réalisations” plutôt que “Cliquez ici”
- Les liens qui ouvrent un nouvel onglet l’indiquent (visuellement et via
aria-label) - Les boutons utilisent la balise
<button>, pas un<div>avec un onclick - La zone cliquable est suffisamment grande (minimum 44x44 pixels recommandé)
Formulaires accessibles
Les formulaires de contact doivent être utilisables par tous :
- Chaque champ a un
<label>explicitement associé (via l’attributfor) - Les champs obligatoires sont indiqués de manière textuelle, pas seulement par la couleur
- Les messages d’erreur sont explicites et associés au champ concerné via
aria-describedby - L’autocomplétion est activée avec les attributs
autocompleteappropriés - Le formulaire est navigable et soumissible au clavier
Gestion du temps
Si votre site contient des sessions avec expiration (espace client, formulaire multi-étapes) :
- L’utilisateur est averti avant l’expiration
- Il peut prolonger la session
- Aucune limite de temps n’est imposée pour les actions simples (remplir un formulaire de contact)
Checklist : compréhension et robustesse
Langage et lisibilité
- La langue de la page est déclarée dans la balise HTML (
lang="fr") - Les changements de langue dans le contenu sont marqués (
<span lang="en">web design</span>) - Le texte est rédigé de manière claire et concise (un guide de rédaction web peut vous aider)
- Les abréviations et termes techniques sont expliqués
Prévisibilité
- La navigation est cohérente sur toutes les pages
- Les éléments similaires sont présentés de manière similaire
- Aucune action ne se déclenche de manière inattendue (pas de popup au chargement, pas de lecture automatique de vidéo avec son)
Compatibilité technique
- Le code HTML est valide et sémantique
- Les attributs ARIA sont utilisés correctement (préférer les éléments HTML natifs quand ils existent)
- Le site fonctionne avec les technologies d’assistance (lecteurs d’écran comme VoiceOver, NVDA, JAWS)
ARIA : quand et comment l’utiliser
ARIA (Accessible Rich Internet Applications) est un ensemble d’attributs qui enrichissent le HTML pour les technologies d’assistance. La règle d’or : utiliser ARIA uniquement quand le HTML natif ne suffit pas.
Exemples d’utilisation justifiée
aria-label: pour nommer un bouton qui ne contient qu’une icônearia-expanded: pour indiquer si un menu déroulant est ouvert ou ferméaria-live: pour annoncer des mises à jour dynamiques (notifications, chargement)role="alert": pour les messages d’erreur ou de confirmation importants
Erreurs courantes
- Ajouter
role="button"à un<div>au lieu d’utiliser un vrai<button> - Utiliser
aria-hidden="true"sur du contenu visible - Mettre un
aria-labelen conflit avec le texte visible de l’élément
Outils d’audit d’accessibilité
Plusieurs outils gratuits permettent de détecter les problèmes d’accessibilité :
- axe DevTools (extension Chrome) : détecte automatiquement de nombreuses violations WCAG
- WAVE (WebAIM) : analyse visuelle des problèmes d’accessibilité
- Lighthouse (Chrome DevTools) : inclut un audit d’accessibilité avec score
- Pa11y : outil en ligne de commande pour les audits automatisés
Ces outils détectent environ 30 à 40 % des problèmes d’accessibilité. Les tests manuels (navigation au clavier, test avec un lecteur d’écran) restent indispensables pour une évaluation complète.
Par où commencer ?
Si l’accessibilité de votre site n’a jamais été vérifiée, commencez par ces cinq actions prioritaires :
- Vérifier les contrastes de couleurs sur toutes les pages
- Ajouter des attributs
altdescriptifs à toutes les images - S’assurer que le site est navigable au clavier
- Associer des labels à tous les champs de formulaire
- Déclarer la langue de la page (
lang="fr")
Ces cinq actions couvrent les problèmes d’accessibilité les plus fréquents et les plus impactants. Elles ne demandent que quelques heures de travail pour un site de taille moyenne.
L’accessibilité n’est pas un projet ponctuel mais une pratique continue. Chaque nouvelle page, chaque nouveau composant doit être pensé pour être accessible dès sa conception. Chez tacelo, nous intégrons les critères WCAG AA dans chaque projet, parce qu’un site web vraiment professionnel est un site accessible à tous.