Accessibilité numérique par type de handicap

Article 01

📖 Les troubles DYS

Dyslexie, dysorthographie, dyscalculie, dyspraxie, dysphasie

6 à 10 % de la population française Lecture : ~8 min

Comprendre

Qu'est-ce que les troubles DYS ?

Les troubles DYS sont des troubles neurodéveloppementaux spécifiques des apprentissages. Ils touchent entre 6 et 10 % de la population française selon le Gouvernement et n'ont aucun lien avec le niveau d'intelligence. Ce sont des handicaps invisibles — un utilisateur DYS peut paraître parfaitement à l'aise alors qu'il fournit un effort cognitif considérable pour lire votre page.

📖 Dyslexie

Trouble de la lecture et du déchiffrage
Les lettres semblent se déplacer, se retourner, se confondre (b/d, p/q)
Lecture lente et fatigante
Impact sur la navigation web et les formulaires

✏️ Dysorthographie

Trouble de l'écriture orthographique
Erreurs fréquentes dans les champs texte
Sensibilité aux corrections automatiques agressives
Stress face aux formulaires complexes

🔢 Dyscalculie

Trouble du calcul et du raisonnement logico-mathématique
Difficulté à saisir des numéros (carte, téléphone, date)
Besoin de formats clairement indiqués
Messages d'erreur avec exemples concrets indispensables

🧩 Dyspraxie / Dysphasie

Dyspraxie : trouble de la coordination motrice et visuo-spatiale
Difficulté à cliquer sur des éléments petits ou proches
Dysphasie : trouble du langage oral et de sa compréhension
Vocabulaire complexe = barrière supplémentaire

"À 18h, après avoir lu des documents numériques toute la journée, j'ai l'impression que les lettres dansent devant mes yeux. Polices trop fines ou trop serrées, formulaires illisibles, menus confus… chaque clic devient un exercice de concentration épuisant." — Marion Ranvier, directrice de la Contentsquare Foundation, dyslexique

Impacts concrets

Qu'est-ce qui bloque un utilisateur DYS sur votre site ?

✗ Ce qui pose problème

Texte justifié — crée des "rivières blanches" visuelles qui perturbent la lecture
Police avec empattements (serif) — les lettres se confondent plus facilement
Lignes de plus de 80 caractères — fatigue oculaire et perte du fil
Fonds blancs pure (#fff) éblouissants — augmentent le flou visuel
Blocs de texte denses sans espacement ni hiérarchie
Texte en majuscules, en italique ou souligné en dehors des liens
Animations, textes défilants ou éléments mobiles — distracteurs
Placeholder comme seul label de champ — disparaît à la saisie
Messages d'erreur sans exemple de correction
Contenu uniquement en image (le texte ne peut pas être relu par un outil de lecture)

Code

Bonnes pratiques HTML, CSS et JS

Typographie et espacement — Le WCAG 1.4.12 exige que le contenu reste lisible si l'utilisateur modifie l'espacement du texte. En pratique, utiliser des unités relatives et ne jamais bloquer ces propriétés CSS :

/* ✓ Espacement WCAG 1.4.12 — ne jamais bloquer */
body {
  font-family: 'Segoe UI', system-ui, sans-serif; /* Sans empattement */
  font-size: 1rem; /* Base relative, respecte le zoom navigateur */
  line-height: 1.6;  /* Min 1.5 recommandé (WCAG 1.4.12) */
  letter-spacing: 0.05em; /* Min 0.12em WCAG, adaptation douce ici */
  word-spacing: 0.1em;
  color: #1a1a2e; /* Pas de noir pur — légèrement adouci */
  background: #fafaf8; /* Fond ivoire — moins éblouissant que #fff */
}

p {
  max-width: 70ch; /* 65-80 caractères max par ligne */
  text-align: left;  /* Jamais justify — crée des rivières */
  margin-bottom: 1.2em;
}

/* Respecter prefers-reduced-motion (WCAG 2.3.3) */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: .01ms !important;
    transition-duration: .01ms !important;
  }
}
        

Formulaires clairs — Un champ mal étiqueté est l'un des obstacles les plus fréquents pour les personnes dyslexiques et dyscalculiques :

<!-- ✓ Label lié + format explicite + exemple d'erreur -->
<div class="form-field">
  <label for="date-naissance">
    Date de naissance <span class="format-hint">(JJ/MM/AAAA)</span>
  </label>
  <input
    type="text"
    id="date-naissance"
    inputmode="numeric"
    autocomplete="bday"
    aria-describedby="date-aide date-erreur"
    placeholder="01/06/1990">
  <span id="date-aide" class="hint">Format : jour/mois/année</span>
  <span id="date-erreur" role="alert" hidden>
    Format incorrect. Exemple valide : 01/06/1990
  </span>
</div>
        

Option de lecture adaptée — Permettre à l'utilisateur de basculer vers une police DYS-friendly. Les polices comme Luciole ou OpenDyslexic n'aident qu'une partie des personnes dyslexiques, mais le choix est essentiel :

/* CSS : variable de police commutable via JS */
:root { --police-lecture: 'Segoe UI', system-ui, sans-serif; }
[data-font="dys"] { --police-lecture: 'Luciole', 'OpenDyslexic', sans-serif; }
body { font-family: var(--police-lecture); }

// JS : basculer la police
document.getElementById('btn-police-dys').addEventListener('click', function() {
  var actif = document.documentElement.getAttribute('data-font') === 'dys';
  document.documentElement.setAttribute('data-font', actif ? '' : 'dys');
  localStorage.setItem('police-dys', actif ? 'non' : 'oui');
});
        

WCAG 2.2 & RGAA 4.1

Critères clés applicables aux troubles DYS

WCAG 1.4.3 — AA Contraste du texte : ratio minimum 4,5:1 pour le texte normal, 3:1 pour le grand texte (>18pt). Un fond ivoire (#fafaf8) avec texte foncé (#1a1a2e) offre un contraste de 16:1.

WCAG 1.4.12 — AA Espacement du texte : le contenu reste lisible si l'utilisateur applique line-height ≥ 1,5, letter-spacing ≥ 0,12em, word-spacing ≥ 0,16em. Ne jamais fixer ces valeurs en px absolus.

WCAG 1.4.10 — AA Reflow : à 400% de zoom (320px effectifs), le contenu reste lisible sans scroll horizontal. Indispensable pour les utilisateurs qui agrandissent pour mieux distinguer les lettres.

WCAG 3.3.2 — A Labels et instructions : chaque champ de formulaire doit avoir un label visible ET son format doit être précisé (ex : date JJ/MM/AAAA). Le placeholder seul ne compte pas.

WCAG 3.3.3 — AA Suggestion après erreur : en cas de saisie incorrecte, suggérer la correction avec un exemple concret. Critique pour la dyscalculie et la dysorthographie.

RGAA 10.8 Contenu caché accessible : les contenus masqués doivent être ignorés des technologies d'assistance. Pertinent pour les outils de lecture qui suivent l'ordre du DOM.

Récapitulatif — À retenir pour les DYS

Police sans empattement Max 70ch par ligne Pas de texte justifié Fond ivoire, pas blanc pur Labels explicites Format des champs visible prefers-reduced-motion Option police DYS Line-height ≥ 1,5

Sources vérifiées

Article 02

⚡ Le TDAH

Trouble du Déficit de l'Attention avec ou sans Hyperactivité

5 à 7 % des enfants, 2 à 5 % des adultes Lecture : ~6 min

Comprendre

Qu'est-ce que le TDAH ?

Le Trouble du Déficit de l'Attention avec ou sans Hyperactivité (TDAH) est un trouble neurodéveloppemental caractérisé par des difficultés de concentration, d'impulsivité et parfois d'hyperactivité. Sur le web, cela se traduit par une difficulté à maintenir l'attention sur un parcours complexe, une sensibilité extrême aux distracteurs visuels, et une frustration rapide face aux interfaces non intuitives.

Le cerveau TDAH fonctionne différemment : il a besoin de stimulation et de clarté simultanément. Une interface surchargée est épuisante, mais une interface trop vide peut aussi nuire à l'engagement. L'enjeu est la juste densité d'information avec des repères visuels forts.

⚡ Difficultés d'attention

Perd le fil dans les longs formulaires
Oublie où il en est dans un processus multi-étapes
Abandonne une tâche si elle prend trop de temps
Distrait par les animations et publicités

🎯 Impulsivité et mémoire

Clique sans lire les confirmations
Soumet des formulaires incomplets
Difficultés à mémoriser les étapes précédentes
Besoin de toujours voir où il en est (progression)

Code

Bonnes pratiques pour le TDAH

✓ Ce qui aide concrètement

Diviser les longs formulaires en étapes courtes avec une barre de progression visible
Sauvegarder automatiquement la progression (localStorage ou serveur)
Afficher clairement où l'utilisateur en est (étape 2/4)
Bouton "Continuer plus tard" pour les tâches longues
Espaces blancs généreux entre les sections
Titres et intertitres réguliers pour permettre de "retrouver le fil"
Alertes d'inactivité avec prolongation facile (WCAG 2.2.1)
Résumé visible des actions effectuées avant confirmation

Formulaire multi-étapes avec progression :

<!-- ✓ Indicateur de progression accessible -->
<nav aria-label="Progression du formulaire">
  <ol role="list">
    <li aria-current="step">Étape 1 : Informations</li>
    <li>Étape 2 : Choix</li>
    <li aria-disabled="true">Étape 3 : Paiement</li>
  </ol>
</nav>

<!-- Barre visuelle -->
<div role="progressbar"
     aria-valuenow="33"
     aria-valuemin="0"
     aria-valuemax="100"
     aria-valuetext="Étape 1 sur 3"
     style="width:33%">
</div>

<!-- Sauvegarde automatique -->
<div role="status" aria-live="polite" aria-atomic="true">
  <!-- Injecté par JS quand la sauvegarde est effectuée -->
  Brouillon sauvegardé à 14:32
</div>
        

Réduire les distracteurs — Supprimer ou mettre en pause tout ce qui bouge pendant une tâche critique :

/* ✓ Désactiver les animations si prefers-reduced-motion */
@media (prefers-reduced-motion: reduce) {
  .banniere-pub, .carousel-auto, .notification-popup {
    animation: none;
    transition: none;
  }
}
/* ✓ Mettre en avant le contenu actif, atténuer le reste */
.formulaire-actif ~ .sidebar { opacity: 0.4; pointer-events: none; }
        

WCAG 2.2 & RGAA 4.1

Critères clés pour le TDAH

WCAG 2.2.1 — A Durée suffisante : tout délai peut être désactivé, ajusté (×10) ou prolongé (×20). Un formulaire qui expire en 15 minutes sans avertissement est une barrière majeure pour le TDAH.

WCAG 2.2.2 — A Pause / Stop / Masquer : tout contenu qui bouge, clignote ou défile doit pouvoir être mis en pause. Les animations auto-jouées sont particulièrement problématiques.

WCAG 3.2.3 — AA Navigation cohérente : la navigation et les composants répétés doivent apparaître dans le même ordre relatif sur toutes les pages. Réduit la charge cognitive de réorientation.

WCAG 3.3.4 — AA Prévention des erreurs : pour les soumissions importantes, permettre de vérifier, corriger, et confirmer avant envoi définitif. Compense l'impulsivité.

Récapitulatif — À retenir pour le TDAH

Étapes courtes et numérotées Barre de progression Sauvegarde automatique Pas d'animations auto Alertes de délai Résumé avant confirmation Espaces blancs généreux

Sources vérifiées

Article 03

🔷 TSA — Trouble du Spectre Autistique

Un spectre large, des besoins spécifiques en matière de prévisibilité et de clarté

~1 % de la population mondiale (OMS) Lecture : ~7 min

Comprendre

Qu'est-ce que le TSA ?

Le Trouble du Spectre Autistique (TSA) est un handicap neurodéveloppemental, pas une maladie. Il se caractérise par des particularités dans la communication, l'interaction sociale, et une sensibilité sensorielle variable (hyper ou hyposensibilité). Le TSA est un spectre : les besoins varient énormément d'une personne à l'autre.

Comme le souligne l'article de référence des 24 Jours de Web (2023), basé sur des entretiens avec des personnes autistes travaillant dans le web : la majorité des critères WCAG et RGAA traitent des handicaps visuels, physiques et auditifs. L'autisme est encore sous-représenté dans les référentiels, mais de nombreux critères s'appliquent indirectement.

🔷 Particularités sensorielles

Hypersensibilité aux stimuli visuels (couleurs vives, animations)
Hypersensibilité aux stimuli sonores (autoplay audio)
Certaines textures visuelles sont désagréables (patterns répétitifs)
Les contenus clignotants peuvent être très perturbants

🔷 Besoin de prévisibilité

Les changements de contexte non annoncés sont déstabilisants
Les métaphores, l'ironie, le second degré sont difficiles à décoder
Les instructions doivent être littérales et non ambiguës
Les comportements inattendus des interfaces créent de l'anxiété

🔷 Lecture et traitement

Temps de traitement de l'information souvent plus long
Besoin de relire plusieurs fois pour être certain de comprendre
Certaines personnes utilisent des lecteurs d'écran même avec une bonne vision
Les CAPTCHA textuels/visuels sont particulièrement difficiles

Code

Bonnes pratiques pour le TSA

✗ Ce qui crée des barrières

Sons ou vidéos qui se lancent automatiquement
Pop-ups inattendus qui interrompent la navigation
Comportements incohérents d'une page à l'autre (même bouton, résultats différents)
Texte qui utilise des métaphores sans les expliquer ("plongez dans notre univers")
CAPTCHA complexes ou basés sur la reconnaissance d'images subjectives
Erreurs de formulaire qui effacent tout ce qui a été saisi
Notifications intrusives et fréquentes

✓ Ce qui aide

Langage clair, direct, sans métaphore ni tournure ambiguë
Comportements prévisibles : un clic = une action, toujours la même
Pas de changement de contexte sans avertissement explicite
Conserver les données saisies en cas d'erreur de formulaire
Toujours proposer une alternative aux CAPTCHA visuels
Mode "pas de distracteurs" (pas d'animations, pas de notifications)
Instructions textuelles claires accompagnées d'exemples concrets

Éviter les changements de contexte non annoncés (WCAG 3.2.1 et 3.2.2) :

<!-- ✗ Mauvais : navigation au changement de valeur -->
<select onchange="window.location = this.value">
  <option value="/fr">Français</option>
</select>

<!-- ✓ Correct : bouton explicite pour confirmer l'action -->
<form>
  <label for="langue">Choisir la langue</label>
  <select id="langue" name="langue">
    <option value="fr">Français</option>
    <option value="en">English</option>
  </select>
  <button type="submit">Appliquer la langue</button>
</form>

<!-- ✓ Empêcher l'autoplay (WCAG 1.4.2) -->
<video controls preload="metadata">
  <!-- Pas d'attribut "autoplay" -->
  <source src="video.mp4" type="video/mp4">
</video>
        

WCAG 2.2 & RGAA 4.1

Critères clés pour le TSA

WCAG 1.4.2 — A Contrôle du son : tout audio démarrant automatiquement et durant plus de 3 secondes doit pouvoir être coupé, mis en pause ou son volume réduit.

WCAG 2.3.1 — A Pas plus de 3 flashs par seconde : critique pour les personnes photosensibles, mais aussi très perturbant pour certaines personnes autistes avec hypersensibilité visuelle.

WCAG 3.2.1 — A Au focus : recevoir le focus ne doit pas provoquer un changement de contexte inattendu (navigation automatique, ouverture de modale, etc.).

WCAG 3.2.2 — A À la saisie : changer la valeur d'un champ ne doit pas déclencher automatiquement une action (navigation, rechargement de page).

WCAG 3.3.7 — A Authentification accessible : ne pas imposer de test cognitif (CAPTCHA) sans alternative. Les CAPTCHA visuels complexes sont particulièrement excluants pour le TSA.

Récapitulatif — À retenir pour le TSA

Langage clair et direct Pas d'autoplay Comportements prévisibles Pas de changement de contexte Alternative au CAPTCHA Données conservées après erreur Pas de flashs

Sources vérifiées

Article 04

🖐️ Handicap moteur

Tremblements, paralysie, amputation, maladies neuro-dégénératives

~2,3 millions de personnes en France Lecture : ~8 min

Comprendre

Qu'est-ce que le handicap moteur dans le contexte numérique ?

Le handicap moteur couvre un spectre très large : tremblements essentiels, Parkinson, sclérose en plaques, tétraplégie, paraplégie, hémiplégie, amputation, douleurs chroniques limitant les mouvements. Chaque situation conduit à des adaptations différentes pour accéder au numérique.

Les technologies d'assistance utilisées sont variées : navigation au clavier seul, commande vocale (Dragon NaturallySpeaking), contacteurs à un seul bouton (switch access), trackball, joystick, système de suivi oculaire (eye tracking), ou souris alternative. Votre site doit fonctionner 100% sans souris.

⌨️ Navigation clavier

Toutes les fonctionnalités accessibles avec Tab, Entrée, Échap, flèches
Focus visible à chaque élément interactif
Pas de piège clavier (modale sans fermeture au clavier)
Raccourcis clavier documentés

🎯 Taille des cibles

Minimum 44×44px pour tous les éléments cliquables
Espacement suffisant entre les boutons (pas de boutons collés)
Liens textuels larges plutôt qu'icônes minuscules
Zones de clic étendues aux libellés des checkboxes

⏱️ Temps et délais

Pas de double-clic obligatoire
Délais d'expiration ajustables (WCAG 2.2.1)
Pas de drag-and-drop sans alternative clavier
Gestes complexes évités ou avec alternative

🖱️ Pointage

Actions au relâchement du clic (pas au pressé) — WCAG 2.5.2
Éviter les survols nécessaires pour révéler des contenus
Les menus au survol ont une alternative au focus clavier
Pas de contenu qui disparaît au déplacement de la souris

Code

Implémentation technique : navigation clavier complète

Focus visible obligatoire — C'est le critère WCAG 2.4.7 (AA) le plus souvent cassé par les CSS :

/* ✗ L'erreur la plus fréquente — NE JAMAIS FAIRE */
* { outline: none; }
:focus { outline: none; }

/* ✓ Focus visible uniquement pour la navigation clavier */
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
  border-radius: 3px;
  /* ratio 7:1 sur fond blanc — dépasse les exigences WCAG 2.4.11 */
}
:focus:not(:focus-visible) { outline: none; }

/* ✓ Taille de cible minimale (WCAG 2.5.5 — AA) */
button, a, input, select, textarea, [role="button"] {
  min-height: 44px;
  min-width: 44px;
}
/* Pour les boutons inline : étendre la zone de clic */
.btn-icon {
  padding: 10px;
  display: inline-flex;
  align-items: center;
}
        

Skip link (lien d'évitement) — WCAG 2.4.1 (A) : le premier élément focusable de toute page :

<!-- Premier élément dans le body — WCAG 2.4.1 obligatoire -->
<a href="#contenu-principal" class="skip-link">
  Aller au contenu principal
</a>

/* Invisible sauf au focus clavier */
.skip-link {
  position: absolute;
  top: -100px; left: 16px; z-index: 9999;
  background: #1a1a2e; color: #fff;
  padding: 10px 18px; border-radius: 0 0 6px 6px;
  text-decoration: none; transition: top .2s;
}
.skip-link:focus { top: 0; }
        

Action au relâchement du clic — WCAG 2.5.2 (A) : déclencher l'action à pointerup, pas à pointerdown, pour permettre d'annuler en glissant hors de la cible :

// ✗ Mauvais : action immédiate au pressé (mousedown)
bouton.addEventListener("mousedown", supprimerFichier);

// ✓ Correct : action au relâchement (click = mouseup + même élément)
bouton.addEventListener("click", supprimerFichier);
// Le HTML natif <button> fait déjà ça correctement
// Ne PAS utiliser mousedown/pointerdown pour des actions destructives
        

WCAG 2.2 & RGAA 4.1

Critères clés pour le handicap moteur

WCAG 2.1.1 — A Clavier : toutes les fonctionnalités disponibles à la souris doivent l'être au clavier. Le critère le plus fondamental pour le handicap moteur.

WCAG 2.1.2 — A Pas de piège clavier : l'utilisateur peut toujours sortir d'un composant au clavier. Les modales sans fermeture par Échap sont un piège classique.

WCAG 2.4.7 — AA Focus visible : tout composant qui reçoit le focus clavier doit avoir un indicateur visuel. La suppression de l'outline CSS est la violation la plus répandue.

WCAG 2.5.2 — A Annulation du pointeur : pour les fonctions à un seul clic, l'action est déclenchée au relâchement (up-event) et peut être annulée en déplaçant le curseur hors de la cible.

WCAG 2.5.5 — AA Taille de la cible : chaque cible d'activation mesure au minimum 44×44 pixels CSS, ou dispose d'un espace équivalent autour d'elle.

WCAG 2.4.1 — A Bypass blocks : un lien d'évitement permet de sauter la navigation répétée et d'accéder directement au contenu. Critique pour les utilisateurs de clavier.

Récapitulatif — À retenir pour le handicap moteur

100% navigable au clavier Focus visible toujours Skip link en premier Cibles ≥ 44×44px Action au relâchement Délais ajustables Pas de piège clavier Alt aux gestes complexes

Sources vérifiées

Article 05

👁️ Troubles visuels

Cécité, malvoyance, daltonisme, basse vision

~1,7 million de malvoyants en France (Inserm) Lecture : ~10 min

Comprendre

Les différents troubles visuels

🔲 Cécité totale

Utilise un lecteur d'écran (NVDA, JAWS, VoiceOver)
Navigation au clavier uniquement
Écoute le contenu linéairement ou saute de titre en titre
Les images sans alt text sont ignorées ou annoncées "image"

👁️ Malvoyance / basse vision

Zoom navigateur à 200%, 400% ou plus
Personnalisation des couleurs et polices
Lecteur d'écran parfois utilisé en complément
Loupe d'écran système (ZoomText, loupe Windows)

🎨 Daltonisme

8% des hommes, 0,5% des femmes
Types : deutéranopie (vert), protanopie (rouge), tritanopie (bleu)
Rouge/vert indistinguables pour la majorité
Toute information uniquement par la couleur est inaccessible

☀️ Photophobie / sensibilité à la lumière

Fonds très blancs douloureux
Mode sombre indispensable
prefers-color-scheme CSS à respecter
Contrastes trop élevés aussi problématiques

Code — Lecteurs d'écran

Rendre votre site compatible avec les lecteurs d'écran

Textes alternatifs des images — WCAG 1.1.1 (A), le critère le plus fondamental :

<!-- ✓ Image informative : décrire l'information portée par l'image -->
<img src="graphique-ventes.png"
     alt="Graphique : les ventes ont augmenté de 40% en 2024 vs 2023"
     width="600" height="300">

<!-- ✓ Image décorative : alt vide pour être ignorée -->
<img src="separateur.svg"
     alt=""
     aria-hidden="true">

<!-- ✓ Icône SVG fonctionnelle -->
<button type="button">
  <svg aria-hidden="true" focusable="false">...icône...</svg>
  <span>Télécharger le PDF</span>
</button>

<!-- ✗ À éviter : texte dans image, illisible par lecteur d'écran -->
<img src="bouton-contact.png" alt="Bouton Nous contacter">
<!-- Utiliser du vrai HTML à la place -->
        

Structure sémantique — Les lecteurs d'écran naviguent par landmarks et titres :

<!-- ✓ Structure de page complète avec landmarks -->
<header><!-- role="banner" implicite -->
  <nav aria-label="Navigation principale">...</nav>
</header>
<main id="contenu-principal"><!-- role="main" implicite -->
  <h1>Titre principal (un seul par page)</h1>
  <section aria-labelledby="titre-section">
    <h2 id="titre-section">Titre de section</h2>
  </section>
</main>
<aside aria-label="Informations complémentaires">...</aside>
<footer>...</footer>
        

Mode sombre et prefers-color-scheme — Respecter le paramètre système :

/* ✓ Mode sombre automatique selon le système (WCAG 1.3.4) */
:root {
  --fond: #ffffff;
  --txt:  #1a1a2e;
  --bord: #e2e8f0;
}
@media (prefers-color-scheme: dark) {
  :root {
    --fond: #0f0f1a;
    --txt:  #e8e8f0;
    --bord: #2d2d4e;
  }
}
/* ✓ Aussi : mode sombre manuel via data-theme */
[data-theme="dark"] {
  --fond: #0f0f1a;
  --txt:  #e8e8f0;
}
        

Daltonisme — Ne jamais transmettre une information uniquement par la couleur (WCAG 1.4.1) :

<!-- ✗ Mauvais : erreur signalée uniquement par couleur rouge -->
<input type="email" style="border-color:red">

<!-- ✓ Correct : couleur + icône + texte -->
<input type="email"
       aria-invalid="true"
       aria-describedby="email-err">
<span id="email-err" role="alert">
  ⚠ Format invalide — Ex : contact@intally-solutions.fr
</span>

/* Indicateur visuel multi-canal */
[aria-invalid="true"] {
  border-color: #b91c1c;
  box-shadow: 0 0 0 3px rgba(185,28,28,.2);
  /* + icône d'avertissement dans le label ou à côté du champ */
}
        

WCAG 2.2 & RGAA 4.1

Critères clés pour les troubles visuels

WCAG 1.1.1 — A Contenu non textuel : toute image, icône, graphique ou CAPTCHA a une alternative textuelle. Images décoratives : alt="" obligatoire.

WCAG 1.4.1 — A Utilisation de la couleur : la couleur n'est pas le seul moyen de transmettre une information. Toujours doubler d'un texte, d'une icône ou d'un motif.

WCAG 1.4.3 — AA Contraste du texte : 4,5:1 minimum pour le texte normal, 3:1 pour le grand texte. Vérifier avec WebAIM Contrast Checker ou l'extension axe.

WCAG 1.4.4 — AA Redimensionnement du texte : le texte reste lisible jusqu'à 200% de zoom sans perte de contenu ni de fonctionnalité. Utiliser rem/em, jamais px pour les tailles de police.

WCAG 1.4.10 — AA Reflow : à 400% de zoom (320px CSS effectifs), le contenu ne nécessite pas de scroll dans les deux directions. Le responsive design résout généralement ce critère.

RGAA 1.1 à 1.9 Images (thématique RGAA) : 9 critères couvrant les alternatives textuelles des images informatives, décoratives, captchas, images texte, et images légendées.

🛠️ Outils de test recommandés

NVDA + Chrome (Windows) VoiceOver + Safari (macOS/iOS) TalkBack (Android) WebAIM Contrast Checker Colour Contrast Analyser Sim Daltonism (simulateur) axe DevTools Accessibility Insights

Récapitulatif — À retenir pour les troubles visuels

Alt text sur toutes les images Contraste ≥ 4,5:1 Pas d'info par couleur seule Structure sémantique H1>H2>H3 rem/em pour les polices Mode sombre (prefers-color-scheme) Landmarks ARIA Reflow 400% de zoom

Sources vérifiées

Article 06

👂 Troubles auditifs

Surdité, malentendance, acouphènes

~5 millions de malentendants en France Lecture : ~6 min

Comprendre

L'impact du handicap auditif sur le web

Les personnes sourdes ou malentendantes n'ont pas accès au contenu audio et vidéo sans adaptation. C'est le type de handicap qui touche le plus directement la consommation de contenus multimédia. Mais c'est aussi celui pour lequel les solutions techniques sont les plus directes et les plus efficaces à mettre en œuvre : sous-titres, transcriptions, et langage des signes.

Une particularité importante : pour de nombreuses personnes sourdes de naissance, la langue des signes est leur langue maternelle. Le français écrit est pour elles une langue seconde. Il est donc essentiel que vos contenus textuels soient également clairs et simples.

🎬 Vidéos

Sous-titres synchronisés (captions) sur toutes les vidéos
Distinguer sous-titres (traduction) et captions (dialogue + sons)
Format .vtt pour les pistes <track> HTML
Contrôle d'affichage des sous-titres

🎙️ Audio seul

Transcription textuelle complète (podcasts, messages vocaux)
Pas d'information exclusive en audio sans alternative
Niveau sonore contrôlable par l'utilisateur

📢 Notifications et alertes

Pas de notification uniquement sonore
Toujours accompagner d'un visuel (clignotant, badge, popup)
Vibration sur mobile en complément du son

Code

Implémentation des sous-titres et transcriptions

Élément <video> avec pistes de sous-titres — WCAG 1.2.2 (A) obligatoire pour toute vidéo :

<!-- ✓ Vidéo avec sous-titres et audiodescription -->
<video
  controls
  width="800"
  height="450"
  aria-label="Tutoriel : créer un formulaire HTML accessible">

  <!-- Sources en plusieurs formats pour compatibilité -->
  <source src="tuto.webm" type="video/webm">
  <source src="tuto.mp4"  type="video/mp4">

  <!-- Sous-titres = traduction du dialogue -->
  <track kind="subtitles"
         src="sous-titres-fr.vtt"
         srclang="fr"
         label="Français"
         default>

  <!-- Captions = dialogue + sons (WCAG 1.2.2 — A) -->
  <track kind="captions"
         src="captions-fr.vtt"
         srclang="fr"
         label="Français (sourd/malentendant)">

  <!-- Audiodescription (WCAG 1.2.5 — AA) -->
  <track kind="descriptions"
         src="audiodescription-fr.vtt"
         srclang="fr"
         label="Audiodescription">

  <!-- Chapitres pour navigation (bonus UX) -->
  <track kind="chapters"
         src="chapitres.vtt"
         srclang="fr"
         label="Chapitres">

  Votre navigateur ne supporte pas la balise video.
</video>

<!-- ✓ Lien vers transcription complète -->
<details>
  <summary>Lire la transcription complète du tutoriel</summary>
  <div class="transcription">
    <!-- Texte complet incluant description des sons importants -->
    <p>[Musique de générique] Bienvenue dans ce tutoriel...</p>
  </div>
</details>
        

Format WebVTT (.vtt) — Le format standard pour les sous-titres HTML :

WEBVTT

00:00:01.000 --> 00:00:04.000
Bienvenue dans ce tutoriel HTML.

00:00:04.500 --> 00:00:08.000
Aujourd'hui nous allons créer un formulaire accessible.

00:00:08.500 --> 00:00:11.000
[Bruit de clavier] Commençons par écrire la balise form.

/* Les sons importants doivent être décrits entre crochets */
/* pour les captions (sourds/malentendants) */
        

WCAG 2.2 & RGAA 4.1

Critères clés pour les troubles auditifs

WCAG 1.2.1 — A Contenu audio ou vidéo pré-enregistré : fournir une transcription textuelle ou une alternative pour les contenus audio-seulement et vidéo-seulement.

WCAG 1.2.2 — A Sous-titres (pré-enregistrés) : toute vidéo pré-enregistrée avec du son doit avoir des sous-titres synchronisés. C'est la loi pour tous les sites publics français.

WCAG 1.2.4 — AA Sous-titres (en direct) : les flux vidéo en temps réel (webinaires, événements live) doivent avoir des sous-titres en direct. Certains outils d'IA (Otter.ai, Azure Cognitive) le permettent.

WCAG 1.2.5 — AA Audiodescription : pour les vidéos dont le contenu visuel transmet des informations importantes non décrites à l'oral (graphiques, gestes, texte à l'écran).

WCAG 1.4.2 — A Contrôle du son : tout audio démarrant automatiquement plus de 3 secondes doit pouvoir être coupé ou pausé. Les lecteurs d'écran sont "noyés" par l'audio automatique.

RGAA 4.1 à 4.13 Multimédia (thématique RGAA) : 13 critères couvrant transcriptions, sous-titres, audiodescriptions, contrôles des médias et accessibilité des lecteurs intégrés.

Récapitulatif — À retenir pour les troubles auditifs

Sous-titres sur toutes les vidéos Transcription des podcasts Format WebVTT Pas d'info audio seulement Pas d'autoplay Notifications visuelles Audiodescription si nécessaire

Sources vérifiées

Article 07

📄 Rendre les PDF accessibles

RGAA 4.1, PDF/UA (ISO 14289), bonnes pratiques Word, InDesign et Acrobat

Format le plus difficile à rendre accessible Lecture : ~9 min

Comprendre

Pourquoi les PDF posent-ils problème ?

Le PDF est le format le plus répandu pour diffuser des documents en ligne. C'est aussi l'un des plus difficiles à rendre accessibles. Contrairement au HTML, le PDF n'a pas naturellement une structure sémantique : sans balisage (tags), un lecteur d'écran ne peut pas distinguer un titre d'un paragraphe, ni déterminer l'ordre de lecture dans un document multi-colonnes.

Un PDF peut être dans l'un de ces états : non balisé (illisible par les lecteurs d'écran), scan image (strictement inaccessible sans OCR), balisé mais mal structuré, ou conforme PDF/UA (le seul niveau vraiment accessible). L'objectif est la conformité à la norme ISO 14289-1 (PDF/UA), référencée par les WCAG.

✗ Les erreurs les plus fréquentes dans les PDF

PDF non balisé : exporté sans cocher "Créer un PDF balisé"
PDF issu d'un scan : c'est une image, pas du texte — nécessite une OCR
Ordre de lecture incorrect : le lecteur d'écran lit dans le mauvais ordre
Images sans texte alternatif
Tableaux sans en-têtes balisés (th)
Langue du document non définie dans les propriétés
Titre du document absent (les métadonnées sont vides)
Formulaires PDF non interactifs (champs non balisés)
Liens non étiquetés (l'URL brute n'est pas un texte de lien)
Utilisation d'espaces ou de sauts de ligne pour créer des colonnes (au lieu d'une vraie mise en page)

Méthode

Créer un PDF accessible — Méthode par outil

1. Depuis Microsoft Word — La méthode la plus simple pour les non-spécialistes :

✓ Checklist Word → PDF accessible

Utiliser les styles de titre (Titre 1, Titre 2, Titre 3…) pour toute la structure — ne jamais simuler des titres en gras+grande taille
Ajouter un texte alternatif sur chaque image (clic droit → Format de l'image → Texte de remplacement)
Marquer les images décoratives comme décoratives (cocher "Marquer comme décoratif")
Utiliser de vrais styles de liste (pas de tirets manuels)
Remplir les propriétés du document : Fichier → Informations → Propriétés (Titre, Auteur)
Définir la langue : Révision → Langue → Définir la langue de vérification
Utiliser l'outil "Vérifier l'accessibilité" (onglet Révision)
Exporter en PDF : Fichier → Enregistrer sous → PDF → Options → cocher "Balises de structure du document pour l'accessibilité" et "PDF conforme ISO 19005-1 (PDF/A)"

2. Depuis Adobe InDesign — Pour les mises en page complexes :

✓ Checklist InDesign → PDF accessible

Définir les styles de paragraphe avec balisage (panneau Styles → Export Tagging : H1, H2, p…)
Définir l'ordre des articles dans le panneau Articles (Window → Articles)
Ajouter les textes alternatifs sur les images (Object → Object Export Options → Alt Text)
Définir la langue du document (File → Document Setup → Language)
Exporter en PDF : File → Export → Adobe PDF (Print) → cocher "Tagged PDF" et "Hyperlinks"
Vérifier et corriger ensuite dans Adobe Acrobat Pro

3. Correction dans Adobe Acrobat Pro — Étape finale obligatoire :

✓ Vérifications Acrobat Pro

Outils → Accessibilité → Vérification complète (génère un rapport PDF/UA)
Vérifier et corriger l'ordre de lecture : Outils → Accessibilité → Ordre de lecture
Ouvrir le panneau Balises (Tags) pour vérifier la hiérarchie H1 > H2 > P
Ajouter les textes alternatifs manquants via le panneau Balises
Définir la langue : Fichier → Propriétés → Avancé → Langue
Définir le titre : Fichier → Propriétés → Description → Titre
Valider avec PAC 2024 (PDF Accessibility Checker — gratuit, Windows)

Structure des balises dans un PDF balisé :

/* Arborescence des balises PDF/UA attendue */
<Document>
  <H1> Titre principal du document </H1>
  <P>  Premier paragraphe d'introduction. </P>

  <H2> Section 1 </H2>
  <P>  Contenu de la section. </P>

  <Figure>
    <Alt> Description de l'image informative </Alt>
  </Figure>

  <Table>
    <TR>
      <TH scope="Column"> En-tête colonne 1 </TH>
      <TH scope="Column"> En-tête colonne 2 </TH>
    </TR>
    <TR>
      <TD> Donnée </TD>
      <TD> Donnée </TD>
    </TR>
  </Table>

  <L>  /* Liste */
    <LI> Élément de liste </LI>
    <LI> Élément de liste </LI>
  </L>

  <Link> /* Lien avec texte explicite */
    <OBJR/> En savoir plus sur l'accessibilité numérique
  </Link>
</Document>
        

Checklist rapide

Avant de publier un PDF en ligne

RGAA 13.3 Documents bureautiques accessibles : tout document PDF ou bureautique téléchargeable doit être accessible ou une version alternative accessible doit être proposée.

PDF/UA Titre du document : les métadonnées "Titre" doivent être renseignées. Le nom de fichier ne suffit pas (un lecteur d'écran annonce le titre, pas le nom de fichier).

PDF/UA Langue définie : la langue principale doit être définie dans les propriétés pour que les synthèses vocales utilisent la bonne prononciation.

PDF/UA Structure hiérarchique : H1 → H2 → H3 sans saut de niveau. Les signets (bookmarks) doivent correspondre aux titres pour la navigation.

WCAG 1.4.3 Contraste des couleurs : le contraste texte/fond doit atteindre 4,5:1. À vérifier avec Colour Contrast Analyser.

PDF/UA Tableaux balisés : les en-têtes de colonnes et de lignes doivent être définis avec scope="Column" ou scope="Row" pour que les lecteurs d'écran les associent aux données.

🛠️ Outils de test pour les PDF

PAC 2024 (gratuit, Windows) Adobe Acrobat Pro Accessibility Checker Word NVDA + Adobe Reader Colour Contrast Analyser RGAA Checker (en ligne)

Récapitulatif — À retenir pour les PDF accessibles

Styles de titre (pas de mise en forme manuelle) PDF balisé (Tagged PDF) Alt text sur les images Titre dans les métadonnées Langue définie Tableaux avec en-têtes Ordre de lecture vérifié Validé avec PAC 2024 Contraste ≥ 4,5:1

Sources vérifiées

Accessibilité numérique
par type de handicap

📖 Les troubles DYS

Qu'est-ce que les troubles DYS ?

Qu'est-ce qui bloque un utilisateur DYS sur votre site ?

Bonnes pratiques HTML, CSS et JS

Critères clés applicables aux troubles DYS

⚡ Le TDAH

Qu'est-ce que le TDAH ?

Bonnes pratiques pour le TDAH

Critères clés pour le TDAH

🔷 TSA — Trouble du Spectre Autistique

Qu'est-ce que le TSA ?

Bonnes pratiques pour le TSA

Critères clés pour le TSA

🖐️ Handicap moteur

Qu'est-ce que le handicap moteur dans le contexte numérique ?

Implémentation technique : navigation clavier complète

Critères clés pour le handicap moteur

👁️ Troubles visuels

Les différents troubles visuels

Rendre votre site compatible avec les lecteurs d'écran

Critères clés pour les troubles visuels

👂 Troubles auditifs

L'impact du handicap auditif sur le web

Implémentation des sous-titres et transcriptions

Critères clés pour les troubles auditifs

📄 Rendre les PDF accessibles

Pourquoi les PDF posent-ils problème ?

Créer un PDF accessible — Méthode par outil

Avant de publier un PDF en ligne

🔗 Ressources et références officielles

Référentiels officiels

Outils de test

Ressources pédagogiques

Obligations légales France

Accessibilité numériquepar type de handicap

Qu'est-ce que les troubles DYS ?

Qu'est-ce qui bloque un utilisateur DYS sur votre site ?

Bonnes pratiques HTML, CSS et JS

Critères clés applicables aux troubles DYS

Qu'est-ce que le TDAH ?

Bonnes pratiques pour le TDAH

Critères clés pour le TDAH

Qu'est-ce que le TSA ?

Bonnes pratiques pour le TSA

Critères clés pour le TSA

Qu'est-ce que le handicap moteur dans le contexte numérique ?

Implémentation technique : navigation clavier complète

Critères clés pour le handicap moteur

Les différents troubles visuels

Rendre votre site compatible avec les lecteurs d'écran

Critères clés pour les troubles visuels

L'impact du handicap auditif sur le web

Implémentation des sous-titres et transcriptions

Critères clés pour les troubles auditifs

Pourquoi les PDF posent-ils problème ?

Créer un PDF accessible — Méthode par outil

Avant de publier un PDF en ligne

🔗 Ressources et références officielles

Référentiels officiels

Outils de test

Ressources pédagogiques

Obligations légales France

Accessibilité numérique
par type de handicap