L’accessibilité (A11y) est souvent considérée comme « agréable à avoir ». Ce n’est pas.

Risque juridique : L’ADA (Americans with Disabilities Act) s’applique aux sites Web. Les poursuites ont augmenté de 300 %.
Taille du marché : 15 % de la population mondiale est handicapée. Il s’agit d’un énorme segment de clientèle.
SEO : A11y et SEO se chevauchent à 90 %. Le HTML sémantique gagne les deux. Si vous bloquez un utilisateur aveugle, vous bloquez GoogleBot.

Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

Nous ne le faisons pas uniquement pour les procès. Nous le faisons parce que la « Purple Pound » (le pouvoir d’achat des ménages handicapés) vaut 274 milliards de dollars rien qu’au Royaume-Uni. Nous le faisons parce que les « effets de coupe de trottoir » existent. (Des coupes de trottoir ont été faites pour les fauteuils roulants, mais elles aident les poussettes et les valises). Les sous-titres ont été faits pour les sourds, mais ils aident les gens qui regardent des vidéos dans le métro. A11y améliore l’expérience de tout le monde.

1. HTML sémantique : la fondation

Arrêtez d’utiliser <div> pour tout.

Bouton : <bouton>, pas <div onClick>.
Titre : <h1>, pas <div class="text-3xl">.
Navigation : <nav>, pas <div>. Les lecteurs d’écran s’appuient sur ces balises pour naviguer. Si vous utilisez un bouton « div », un utilisateur aveugle ne peut pas y accéder par « Tabulation ». Ils ne peuvent pas cliquer dessus. C’est un mur.

2. Le style « Bague de mise au point »

Les concepteurs détestent le contour bleu : « contour : aucun ». NE JAMAIS supprimer le contour à moins de le remplacer. Les utilisateurs de clavier (déficients moteurs) comptent sur la bague de mise au point pour savoir où ils se trouvent. Utilisez :focus-visible pour l’afficher uniquement pour les utilisateurs de clavier, pas pour les utilisateurs de souris.

/* Bonne expérience utilisateur */
bouton : focus {
  contour : aucun ; /* Masquer la valeur par défaut */
}

bouton : focus-visible {
  contour : 2px solid var(--color-electric);
  décalage du contour : 2 px ;
}

3. Étiquettes ARIA (Combler le fossé)

Lorsque les repères visuels échouent, utilisez ARIA. Exemple : Une icône “X” pour fermer un modal. Visuellement : c’est évident. Audiblement : il lit « Image ». Correctif : <button aria-label="Close Modal">X</button>. Règle : utilisez d’abord le HTML natif. Utilisez ARIA uniquement lorsque HTML ne suffit pas. N’utilisez pas role="button" sur un div si vous pouvez utiliser un <button>.

4. Contraste des couleurs (l’échec n°1)

Le texte gris sur un fond gris légèrement plus clair semble « moderne ». Il est illisible pour les utilisateurs malvoyants (et pour les personnes regardant leur téléphone au soleil). Vous avez besoin d’un rapport de contraste de 4,5:1 pour le corps du texte. Utilisez Chrome DevTools « Présentation CSS » pour vérifier toutes les couleurs. Prend également en charge correctement le Mode sombre. Le mode contraste élevé est essentiel pour les personnes âgées.

5. Tests automatisés (le pipeline)

Nous intégrons Axe-core dans le processus de développement. Un humain ne peut pas tout attraper.

Linting : eslint-plugin-jsx-a11y détecte les balises alt manquantes <img>.
Exécution : @axe-core/react enregistre les erreurs sur la console pendant le développement.
CI/CD : Pa11y s’exécute dans le pipeline. Si l’accessibilité tombe en dessous de 90 %, la construction échoue.

# Exécution de Pa11y sur CLI
npx pa11y https://maisoncode.paris

6. Le lien “Passer au contenu”

Un utilisateur aveugle ne veut pas écouter votre Mega Menu (50 liens) à chaque chargement de page. Ajoutez un lien caché en haut : “Passer au contenu principal”. Il devient visible sur Focus. <a href="#main" class="sr-only focus:not-sr-only">Passer au contenu</a> C’est la marque d’un site professionnel.

7. Sensibilité au mouvement (troubles vestibulaires)

Certaines animations provoquent des nausées. Respectez le paramètre du système d’exploitation de l’utilisateur : prefers-reduced-motion.

@media (préfère le mouvement réduit : réduire) {
  * {
    durée de l'animation : 0,01 ms !important ;
    durée de transition : 0,01 ms !important ;
  }
}

S’ils demandent le calme, accordez-leur le calme.

8. Test du lecteur d’écran (manuel)

L’automatisation détecte 30 % des erreurs. Vous devez tester manuellement. Activez VoiceOver (Mac) ou NVDA (Windows). Fermez les yeux. Essayez d’acheter un produit sur votre site. Si vous ne pouvez pas… vous êtes brisé. Cet exercice d’empathie change votre façon de coder.

10. La charge cognitive (Neurodiversité)

L’accessibilité n’est pas seulement physique. C’est mental. Pour les utilisateurs atteints de TDAH ou d’autisme, une interface chaotique est écrasante. Directives :

Cohérence : la navigation doit être au même endroit sur chaque page.
Clarté : Pas de jargon. Utilisez un langage simple.
Calme : évitez la lecture automatique des vidéos. Évitez les lumières clignotantes (risque d’épilepsie). Une interface calme est une interface à conversion élevée.

11. La révolution de la commande vocale (Siri/Dragon)

Les utilisateurs ayant une déficience motrice utilisent la commande vocale. “Cliquez sur Ajouter au panier.” Si votre bouton est codé comme <div onClick=...>, le logiciel vocal ne peut pas le voir. Il recherche des « boutons ». Si vous utilisez du HTML sémantique, Voice Control fonctionne immédiatement. “Faites défiler vers le bas. Cliquez sur Commander.” C’est l’avenir du commerce « Mains Libres » (Conduite, Cuisine). A11y permet le commerce vocal.

12. La vérification du zoom (basse vision)

Les utilisateurs malvoyants zooment à 200 % ou 400 %. Votre mise en page se casse-t-elle ? Les lettres se chevauchent-elles ? Typographie fluide : utilisez les unités rem, pas px. font-size : 1rem respecte les paramètres du navigateur de l’utilisateur. font-size : 16px force votre paramètre. Testez votre site avec un zoom de 200 %. Si le menu disparaît, vous avez échoué.

13. L’étude de cas juridique (Domino’s)

Dans Robles c. Domino’s Pizza, la Cour suprême a rejeté la requête de Domino. La décision est maintenue : l’ADA s’applique au monde numérique. Domino’s affirmait : “La loi a été écrite en 1990, avant le Web”. La Cour a déclaré : « L’intention est l’égalité d’accès. Le support n’a pas d’importance. » La leçon : Attendre une « loi Web » spécifique est une stratégie perdante. Le risque est rétroactif. Vous pouvez être poursuivi aujourd’hui pour un site que vous avez construit il y a 3 ans. La réhabilitation coûte 10 fois plus cher que la bonne construction du premier coup.

14. La liste de contrôle d’audit (WCAG 2.1 AA)

Ne devinez pas. Suivez la liste.

Perceptible : Texte alternatif, Légendes, Contraste.
Utilisable : navigation au clavier, pas de clignotement, limites de temps réglables.
Compréhensible : navigation cohérente, identification des erreurs, prévisible.
Robuste : Compatible avec les technologies d’assistance (ARIA). Imprimez cette liste. Enregistrez-le sur votre moniteur. Chaque PR doit réussir cette liste de contrôle.

15. L’avenir d’A11y (assistance IA)

L’IA va révolutionner l’accessibilité. Texte alternatif génératif : des modèles comme GPT-4 Vision peuvent sous-titrer automatiquement 10 000 images en 1 heure. Simplification en temps réel : l’IA peut réécrire des textes juridiques complexes en « anglais simple » pour les utilisateurs ayant des déficiences cognitives. Navigation vocale : “Agent, achetez-moi les chaussures rouges.” Nous construisons ces fonctionnalités aujourd’hui. L’accessibilité passe de « Conformité » à « Assistance ».

16. L’expérience développeur (DX)

Écrire du code accessible est un code plus propre. Le HTML sémantique est plus facile à lire que la soupe div. button est plus clair que div class="btn". L’application d’A11y améliore la santé de la base de code. Cela réduit la dette technique. Cela accélère l’intégration de nouveaux développeurs. Bon DX = Bon UX.

17. Le piège de l’index des tabulations (n’utilisez pas d’entiers positifs)

Une erreur courante est tabindex="1". Cela force l’ordre. Si vous réorganisez le DOM, l’ordre de tabulation est rompu. Règle :

tabindex="0" : Rendre un div focalisable (dans l’ordre naturel).
tabindex="-1" : rendez-le focalisable par programme (JS), mais ignorez via Tab.
tabindex="1" : NE JAMAIS UTILISER CECI. Il combat le navigateur. Laissez le DOM dicter l’ordre.

18. L’exigence HTML valide (analyse)

Les lecteurs d’écran sont des navigateurs. Ils analysent votre HTML. Si vous avez des balises non fermées ou des identifiants en double, l’analyseur devine. Parfois, il se trompe. Règle : Votre code HTML doit être validé. Utilisez le validateur W3C. HTML cassé = accessibilité brisée. C’est l’erreur inattendue qui tue l’expérience. Écrivez du code valide.

19. Le coût de maintenance (Clean Code)

Le code accessible est moins cher à maintenir. Pourquoi? Parce que cela force la structure. Si vous utilisez <div> partout, votre CSS devient un cauchemar de sélecteurs imbriqués .card div div span. Si vous utilisez <article> <h1> <p>, votre CSS est simple. Cela dissocie le style de la structure. Cela rend la refactorisation plus sûre. A11y est techniquement une métrique de qualité du code. Investissez-y.

20. Conclusion

L’accessibilité est l’empathie codée. Cela signifie que vous vous souciez de tous les utilisateurs, pas seulement de ceux qui ont une vision parfaite et un contrôle moteur fin. Cela vous protège des poursuites. Cela améliore votre référencement. Cela ouvre votre marché. Il n’y a aucun inconvénient.

Avez-vous été poursuivi récemment ?

Nous auditons et remédions aux violations d’accessibilité.

Audit Mon A11y. Engagez nos Architectes.