Chapitre 1.3 — Pourquoi ça compte

⏱️ TL;DR — Quatre arguments, chacun suffisant à lui seul, se renforcent : l’humain (c’est un droit d’accès, pas une faveur), le légal (RGAA en France, Acte européen sur l’accessibilité depuis juin 2025 — avec de vraies sanctions), le business (part de marché, SEO, image, réduction des risques), et la qualité (l’a11y te rend meilleur développeur). Selon ton interlocuteur, tu sortiras l’argument qui porte : au dirigeant, la loi et le risque ; à l’équipe produit, le marché ; à toi-même, la fierté du travail bien fait.

🎯 Objectifs

• Maîtriser les quatre arguments pour justifier l’accessibilité.
• Savoir lequel utiliser selon l’interlocuteur (dev, PO, direction, client).
• Connaître, en survol, le poids légal (détaillé en Partie 2).
• Comprendre pourquoi coder accessible améliore ta pratique globale.

Argument 1 — L’humain (le vrai fond)

C’est le socle : le numérique est devenu essentiel — banque, santé, administration, éducation, emploi, achats. En rendre l’accès impossible à une partie de la population, c’est l’exclure de la vie courante. L’accessibilité n’est pas un « plus » qu’on accorde par bonté : c’est une question d’égalité d’accès et d’autonomie.

Environ une personne sur six dans le monde vit avec une forme de handicap (estimation OMS de cet ordre de grandeur). Ce ne sont pas des cas marginaux : ce sont des utilisateurs, des clients, des collègues, des proches. Et, comme vu au chapitre 1.1, chacun de nous rejoint ce groupe temporairement ou situationnellement.

💡 Réflexe — Quand l’argument business ou légal ne suffit pas à convaincre, reviens à l’humain : « Est-ce qu’on est d’accord pour livrer un produit qu’une personne aveugle ou tétraplégique ne peut littéralement pas utiliser ? » Formulé ainsi, le sujet cesse d’être une case à cocher pour redevenir une question de responsabilité.

Argument 2 — La loi (avec des dents)

L’accessibilité numérique est une obligation légale, de plus en plus contraignante. En survol (détails en Partie 2) :

• En France, le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) s’impose au secteur public et à de nombreux acteurs privés. Il impose une déclaration d’accessibilité et expose à des sanctions de l’ARCOM (jusqu’à 50 000 € par service, réitérables).
• En Europe, l’Acte européen sur l’accessibilité (EAA) est entré en application le 28 juin 2025. Il vise de nombreux produits et services numériques du secteur privé (e-commerce, banque, transport, etc.) vendus aux consommateurs de l’UE, avec des amendes selon les pays. Les premières mises en demeure et procédures ont déjà eu lieu.
• Le standard technique visé, dans tous les cas, est WCAG niveau AA.

Autrement dit : l’accessibilité est passée du « ce serait bien » au « c’est obligatoire, et le non-respect coûte cher ». Pour ta niche EdTech/formation, c’est particulièrement vrai — les plateformes de formation sont en première ligne.

⚠️ Piège — Croire qu’on est « trop petit » pour être concerné. Les seuils et périmètres varient (voir Partie 2), mais l’EAA vise déjà des entreprises modestes, et un client grand compte t’imposera la conformité contractuellement, quelle que soit ta taille. L’accessibilité devient une condition d’accès aux marchés.

Argument 3 — Le business

Au-delà de l’obligation, l’accessibilité rapporte :

• Part de marché : exclure une personne sur six, c’est renoncer à une part significative de clients — et à leur entourage, qui achète aussi.
• SEO : les bonnes pratiques d’a11y (HTML sémantique, titres structurés, alternatives textuelles, performances) recoupent largement ce que valorise le référencement. Un site accessible est mieux compris par Google.
• Image de marque & appels d’offres : de plus en plus d’acheteurs (publics comme privés) exigent la conformité. L’accessibilité devient un critère de sélection.
• Réduction du risque : éviter procès, amendes, et le coût (bien plus élevé) de tout corriger après coup.
• Robustesse : un produit accessible fonctionne mieux sur plus d’appareils, de navigateurs et de contextes.

Argument 4 — La qualité (l’argument égoïste)

Celui qui devrait te parler en tant que dev : faire de l’accessibilité te rend meilleur. Pour rendre une interface accessible, tu es obligé de :

• écrire du HTML sémantique propre (au lieu d’une soupe de <div>) ;
• structurer clairement titres, régions et ordre de lecture ;
• gérer proprement le focus et les états — ce qui révèle et corrige plein de bugs d’UX pour tout le monde ;
• nommer les choses correctement, penser aux cas limites, tester au clavier.

Ce sont les mêmes réflexes qui font le code de qualité. L’a11y agit comme un révélateur : un composant difficile à rendre accessible est souvent un composant mal conçu tout court.

🧭 Sur A11yLearn — Pour A11yLearn, les quatre arguments se cumulent : c’est une plateforme de formation (mission d’inclusion évidente), soumise au RGAA/EAA, qui vise un marché où la conformité est demandée dans les appels d’offres, et dont la qualité générale profitera de chaque correctif. On n’aura jamais à « choisir » un argument — mais savoir les articuler t’aidera à embarquer une équipe.

Adapter l’argument à l’interlocuteur

✏️ Exercices

Exercice 1 — Le bon argument. Ton client, un organisme de formation, dit « on n’a pas le budget pour l’accessibilité ». Quel(s) argument(s) déploies-tu, et dans quel ordre ?

Exercice 2 — L’argument qualité. Donne un exemple concret où rendre un composant accessible a aussi corrigé un problème pour les utilisateurs non handicapés.

🧠 Quiz de révision

Chapitre suivant : Les principes POUR — le modèle mental des WCAG qui organise toute la suite du cours.