L’accessibilité vous stresse ? Vous n’êtes pas seul. Voici comment avancer sans paralyser vos équipes.
Lundi matin, réunion d’équipe. Le PO annonce : “On doit être conforme RGAA pour le prochain sprint”. Silence gêné. Le lead dev soupire. Vous, designer, vous sentez déjà venir les 47 tickets Jira sur les contrastes de couleurs.
Je l’ai vécu des dizaines de fois. L’accessibilité, c’est comme le tri sélectif : tout le monde est d’accord que c’est important, mais personne ne sait vraiment par où commencer. Et surtout, on a peur que ça ralentisse tout.
Spoiler : ça ne devrait pas.
Pourquoi l’accessibilité vous fait flipper (et c’est normal)
Parlons cash. Quand on dit “accessibilité”, trois angoisses remontent :
- “On va devoir tout refaire” Vous imaginez déjà 6 mois de refonte pour rendre conformes vos 200 écrans. Le budget explose, le planning dérape, votre product manager fait une syncope.
- “C’est trop technique, je ne maîtrise pas” ARIA, niveaux de conformité AA/AAA, lecteurs d’écran, navigation au clavier… On vous parle un langage qui ressemble plus à du code qu’à du design. Vous ne savez même pas par où commencer.
- “Ça va tuer mon design” Vous avez passé 3 semaines sur cette palette de couleurs subtile. On vous dit maintenant que votre bleu #4A90E2 n’a pas assez de contraste. Vous sentez qu’on va vous forcer à mettre du noir sur blanc partout.
Résultat ? On procrastine. On se dit “on fera ça plus tard”. Et “plus tard” n’arrive jamais.
La vérité : Vous faites déjà 50% du travail sans le savoir
Petite expérience. Regardez votre dernière maquette et cochez ce que vous avez fait :
✓ Hiérarchie claire avec des titres et sous-titres
✓ Labels visibles sur vos champs de formulaire
✓ Boutons avec des textes explicites (pas juste des icônes)
✓ Espacement suffisant entre les éléments cliquables
✓ Maquettes mobile first
Si vous avez coché au moins 3 cases, félicitations : vous faites déjà de l’accessibilité. Vous ne l’appeliez juste pas comme ça.
Parce que voilà le secret : l’accessibilité, c’est d’abord du bon design. Un design clair, logique, prévisible. Ce qui aide une personne aveugle aide aussi votre grand-mère, un utilisateur pressé dans le métro, ou quelqu’un qui consulte votre site au soleil.
La méthodo qui ne bloque pas la prod : Le 80/20 de l’accessibilité
Chez UX-Republic, on a testé plein d’approches. Celle qui marche le mieux ? La règle du 80/20.
20% des actions couvrent 80% des problèmes d’accessibilité. Voici ces 20% :
1. Les contrastes de couleurs (10 minutes par écran)
Le problème : C’est LA source de non-conformité numéro 1. Et c’est réglé en 10 minutes chrono.
La solution rapide :
- Installez l’extension Chrome “WCAG Color Contrast Checker”
- Testez vos combinaisons texte/fond pendant que vous designez
Ratio minimum : 4.5:1 pour du texte normal, 3:1 pour du texte large (18px+) et les composants d’interface (exemple : bouton) Exemple concret : Votre bleu #4A90E2 sur fond blanc ? Ratio 3.4:1. Non conforme. Vous passez à #2F6DB5 : Ratio 4.6:1. Conforme. Différence visuelle ? Quasi imperceptible.
Astuce pro : Créez une palette “safe” dès le départ. 5 couleurs conformes que vous réutilisez partout. Gain de temps énorme.
2. Les textes alternatifs sur les images (2 minutes par image)
Le problème : Les lecteurs d’écran ne voient pas les images. Sans alt-text, l’utilisateur aveugle entend juste “image point JPEG”.
La solution rapide : Deux questions à se poser :
- L’image apporte une info ? → Décrivez-la simplement
- L’image est décorative ? → Mettez alt=”” (vide, pas absent)
Exemples concrets :
❌ Mauvais : alt=”photo” ✅ Bon : alt=”Graphique montrant une hausse de 32% des conversions en janvier 2026″
❌ Mauvais : alt=”banniere-hero.jpg” ✅ Bon : alt=”” (si c’est juste du décor)
Astuce pro : Intégrez cette étape dans votre workflow Figma. Créez un champ “Alt-text” dans vos composants. Les devs vous remercieront.
3. La navigation au clavier (test de 5 minutes)
Le problème : Beaucoup d’utilisateurs (handicap moteur, power users) naviguent sans souris. Si vous ne pouvez pas tout faire à la touche Tab, vous les bloquez.
La solution rapide : Débranchez votre souris. Testez votre interface uniquement avec :
- Tab : passer d’un élément à l’autre
- Entrée / Espace : cliquer
- Flèches : naviguer dans les menus
Vous êtes bloqué quelque part ? C’est là qu’il y a un problème.
Exemple vécu : Menu burger sur mobile. On clique dessus, il s’ouvre. Mais impossible de le fermer au clavier (pas de touche Échap gérée). Fix : 2 lignes de JavaScript.
Astuce pro : Faites ce test à chaque revue de design. Ça prend 5 minutes et vous évite 90% des problèmes de navigation.
4. Les labels de formulaires (1 minute par champ)
Le problème : Un placeholder n’est PAS un label. Dès qu’on tape, il disparaît. Le lecteur d’écran ne le voit pas. L’utilisateur oublie ce qu’il devait remplir.
La solution rapide : Un label visible au-dessus de chaque champ. Toujours.
Exemples :
❌ Mauvais :
[Entrez votre email…____]
Le placeholder disparaît dès qu’on tape.
✅ Bon :
[____________________]
Le label reste visible.
Astuce pro : Si vous tenez absolument à votre placeholder pour des raisons esthétiques, gardez aussi le label. Mais le label doit être là.
5. Les états de focus visibles (5 minutes pour tout le site)
Le problème : Quand on navigue au clavier, on doit VOIR où on est. Beaucoup de sites suppriment l’outline par défaut du navigateur (cette bordure bleue moche) sans la remplacer.
La solution rapide : Ne supprimez JAMAIS outline: none sans prévoir un remplacement.
Exemple de CSS conforme :
button:focus {
outline: 3px solid #2F6DB5;
outline-offset: 2px;
}
Astuce pro : Intégrez l’état focus dans votre design system dès le départ. Même traitement visuel que le hover, mais avec une bordure en plus.
La checklist “sprint 0” : Ce qu’on fait AVANT de designer
Pour ne pas tout reprendre après, voici ce qu’on met en place dès le début du projet :
Côté design :
☐ Palette de couleurs accessible validée (contrastes OK)
☐ Typographie avec tailles minimales définies (16px mobile, 14px desktop)
☐ États de focus designés pour tous les composants interactifs
☐ Convention alt-text documentée dans le design system
Côté process :
☐ Plugin accessibilité installé sur Figma (ex: Stark, A11y)
☐ Checklist accessibilité intégrée dans la Definition of Done
☐ Test clavier dans les critères de validation
Côté équipe :
☐ 1 personne référente accessibilité (pas besoin d’un expert, juste quelqu’un qui pilote)
☐ 30 minutes de formation pour l’équipe (on vous fait un Lunch & Learn)
Total temps de setup ? 2 heures.
Bénéfice ? Vous évitez 3 semaines de corrections en fin de projet.
Les mythes qui vous freinent (et comment les dégonfler)
Mythe 1 : “L’accessibilité, c’est moche” Faux. Apple, Airbnb, Gov.uk sont conformes RGAA. Personne ne trouve ça moche.
Le vrai problème ? Confondre accessibilité et manque de soin graphique. Vous pouvez avoir du design subtil ET conforme. Mythe 2 : “Ça va coûter 30% de temps en plus” Faux. Si vous intégrez l’accessibilité dès le départ, c’est 5% max.
Le surcoût vient quand vous devez TOUT refaire à la fin. Faire de l’accessibilité rétroactive, là oui, c’est cher.
Mythe 3 : “De toute façon, on n’a pas d’utilisateurs handicapés” Faux (et dangereux). 20% de la population a un handicap (temporaire ou permanent). Vous avez des utilisateurs concernés, vous ne le savez juste pas.
Et même sans handicap : vos utilisateurs ont le soleil dans les yeux, un bras cassé, sont dans un train qui bouge, ont 65 ans et voient moins bien. L’accessibilité les aide aussi.
Par où commencer (plan d’action 4 semaines)
Vous êtes convaincu mais vous ne savez pas par quoi attaquer ? Voici un plan progressif :
Semaine 1 : Audit express (2h)
- Prenez vos 5 écrans les plus utilisés
- Testez-les avec la checklist du 80/20 (ci-dessus)
- Notez les 10 problèmes les plus critiques
Semaine 2 : Quick wins (4h)
- Corrigez les contrastes de couleurs
- Ajoutez les alt-text manquants
- Testez la navigation clavier
Semaine 3 : Process (2h)
- Intégrez l’accessibilité dans votre Definition of Done
- Installez les outils de vérification
- Briefez l’équipe (30 min suffisent)
Semaine 4 : Consolidation (4h)
- Créez votre palette couleurs accessible
- Documentez les conventions dans le design system
- Planifiez un audit complet (si nécessaire)
Total temps investi : 12 heures. Résultat : Vous couvrez 80% des problèmes d’accessibilité côté Design.
Ce qu’on a appris en faisant ça 50 fois
Quelques leçons du terrain :
- Commencez petit Ne visez pas la conformité AA totale du jour au lendemain. Choisissez 3 écrans critiques. Rendez-les accessibles. Apprenez. Puis étendez.
- Impliquez les devs tôt L’accessibilité se joue à 50% dans le code (structure HTML, ARIA). Si vos devs découvrent ça en fin de sprint, c’est la cata.
- Automatisez ce qui peut l’être Intégrez des tests automatiques (Axe, Lighthouse) dans votre CI/CD. Ça détecte 30% des problèmes sans effort humain.
- Testez avec de vrais utilisateurs Un audit technique, c’est bien. Mais 30 minutes avec un utilisateur de lecteur d’écran vous apprend 10 fois plus.
Les ressources qu’on utilise vraiment
Pas de liste à rallonge. Voici les 5 outils/ressources qu’on utilise toutes les semaines :
Outils :
- Stark (plugin Figma) : Vérif contrastes + simulation daltonisme
- WAVE (extension Chrome) : Audit rapide d’une page
- Axe DevTools (extension navigateur) : Tests accessibilité en développement
Ressources :
- RGAA 4.1 (référentiel officiel français) : La source ultime, un peu aride mais complète
- AcceDe Web : Notices d’accessibilité par composant, super pratique
Et quand on ne peut vraiment pas tout faire ?
Soyons réalistes. Parfois, le budget ou le planning ne permettent pas de tout corriger. Dans ce cas :
Priorisez par impact utilisateur :
- Critique : Bloque un parcours complet (ex: formulaire non remplissable au clavier)
- Important : Rend difficile mais pas impossible (ex: contraste limite)
- Amélioration : Confort (ex: texte alternatif d’une image décorative)
Et documentez ce qui n’est pas fait Créez un backlog “dette accessibilité”. Au moins, c’est visible. Et vous pouvez y revenir par itérations.
L’accessibilité parfaite n’existe pas. L’accessibilité progressive, oui.
Pour aller plus loin sans culpabiliser
L’accessibilité n’est pas une montagne infranchissable. C’est une série de petits pas. Vous n’êtes pas obligé d’être expert. Vous devez juste être attentif.
Commencez par le 80/20. Testez au clavier. Vérifiez vos contrastes. Ajoutez des labels. En 4 semaines, vous aurez déjà fait un bond énorme.
Et si vous bloquez, n’hésitez pas à demander de l’aide. Il y a une vraie communauté prête à partager (et elle ne juge pas).
On en parle en vrai ? Si ces sujets vous parlent et que vous voulez creuser, on organise régulièrement des sessions sur ces thématiques. Vous pouvez aussi nous contacter directement pour un audit express ou un accompagnement sur vos projets >> chloe.fronty@ux-republic.com.
Laetitia Allais
Experte en Accessibilité numérique chez Smile
