Partie 1 — Comprendre l’accessibilité

⏱️ TL;DR — Avant les balises et les critères, il faut comprendre de quoi on parle et pour qui. L’accessibilité, ce n’est pas « une fonctionnalité pour aveugles » : c’est concevoir des interfaces utilisables par la plus grande diversité d’utilisateurs et de contextes — handicap permanent, temporaire ou situationnel. Cette partie pose les fondations : ce qu’est l’a11y, qui sont les utilisateurs et leurs outils, pourquoi ça compte (éthique, loi, business, qualité), le modèle mental POUR des WCAG, et les mythes tenaces à déconstruire.

Le problème qu’on résout

Beaucoup de devs « savent » qu’il faut faire de l’accessible, sans savoir pourquoi ni pour qui concrètement. Résultat : ils appliquent des recettes sans comprendre (un alt vide ici, un aria-label au hasard là), passent à côté de l’essentiel, et abandonnent au premier composant compliqué. On répare ça en construisant d’abord une compréhension solide : quand tu sais ce que vit un utilisateur de lecteur d’écran face à ton code, tu prends les bonnes décisions toi-même.

Ce que tu sauras faire à la fin de cette partie

• Définir l’accessibilité et dépasser l’image réductrice « c’est pour les aveugles ».
• Nommer les grandes familles de handicaps et les technologies d’assistance associées.
• Défendre l’accessibilité avec les quatre arguments (humain, légal, business, qualité).
• Utiliser le modèle POUR (Perceptible, Utilisable, Compréhensible, Robuste) comme grille de lecture.
• Répondre aux mythes classiques qui freinent l’a11y dans les équipes.

Les chapitres

On commence : C’est quoi, l’accessibilité.