Chapitre 1.2 — Les utilisateurs & leurs outils

⏱️ TL;DR — Pour concevoir accessible, il faut savoir qui utilise ton interface et comment. On distingue quatre grandes familles de situations de handicap — visuelle, auditive, motrice, cognitive/neurologique — auxquelles s’ajoutent la parole et des combinaisons. Chacune s’appuie sur des technologies d’assistance : lecteurs d’écran, loupes, navigation clavier ou à la voix, contacteurs, sous-titres. Comprendre ces outils change tout : tu ne codes plus « pour une norme abstraite », tu codes pour quelqu’un qui va réellement écouter ta page ou la parcourir à la tabulation.

🎯 Objectifs

• Nommer les quatre grandes familles de situations de handicap.
• Associer à chacune les technologies d’assistance courantes.
• Comprendre ce qu’est un lecteur d’écran et comment il « lit » une page.
• Réaliser que ton code HTML est l’interface que ces outils exploitent.

Les quatre grandes familles

Le handicap est divers, mais on peut le regrouper en quatre familles pour raisonner (une même personne peut en cumuler plusieurs).

1. Visuel

De la cécité totale à la malvoyance (vision floue, tunnel, tache centrale) en passant par le daltonisme (perception des couleurs altérée). Outils :

• Lecteur d’écran (screen reader) : logiciel qui transforme l’interface en synthèse vocale ou en braille (via un afficheur braille). C’est l’outil central de ce cours.
• Loupe d’écran (zoom) : agrandit tout ou partie de l’écran ; l’utilisateur ne voit qu’une portion à la fois.
• Feuilles de style / contrastes personnalisés, mode sombre, agrandissement du texte du navigateur.

2. Auditif

De la surdité à la malentendance. Sur le web, l’enjeu est le contenu audio :

• Sous-titres (captions) synchronisés pour les vidéos.
• Transcriptions textuelles pour l’audio (podcasts).
• Interprétation en langue des signes pour certains contenus.

3. Moteur

Difficultés à utiliser une souris ou un écran tactile avec précision : tremblements, paralysie, amputation, douleurs (tendinite, arthrose). Outils :

• Navigation au clavier seul (Tab, flèches, Entrée, Espace) — d’où l’importance capitale du clavier (Partie 4).
• Contacteurs (switch), commande à la voix, suivi oculaire (eye-tracking), claviers adaptés.
• Grandes cibles de clic, tolérance aux erreurs, pas de gestes complexes obligatoires.

4. Cognitif & neurologique

La famille la plus large et la plus oubliée : troubles de l’attention (TDAH), dyslexie, troubles de la mémoire, autisme, déficience intellectuelle, mais aussi épilepsie (photosensibilité) et troubles vestibulaires (animations). Outils et besoins :

• Langage clair, structure prévisible, étapes simples, peu de distractions.
• Respect de prefers-reduced-motion, absence de flashs (risque de crise d’épilepsie).
• Tolérance au temps (pas de délais trop courts), aides à la saisie.

⚠️ Piège — Réduire l’accessibilité aux lecteurs d’écran. C’est la partie la plus visible, mais le handicap cognitif concerne énormément de monde et se traite surtout par la simplicité et la clarté — pas par de l’ARIA. Ne construis pas une usine à gaz technique en oubliant que « simple et clair » est déjà une immense victoire d’accessibilité.

Zoom sur le lecteur d’écran

C’est l’outil que les devs comprennent le moins, alors qu’il structure la moitié du cours. Un lecteur d’écran lit à voix haute (ou envoie en braille) le contenu et la sémantique de la page : « lien Accueil », « bouton Envoyer », « titre de niveau 1 : Tableau de bord », « case à cocher, non cochée : Se souvenir de moi ».

Les principaux : NVDA (gratuit, Windows), JAWS (payant, Windows, très répandu en entreprise), VoiceOver (intégré à macOS/iOS), TalkBack (Android), Orca (Linux). On les détaille en Partie 5.

Point crucial : le lecteur d’écran ne voit pas ton design. Il exploite ce que ton HTML déclare. Si tu écris un bouton avec une <div> stylée au lieu d’un <button>, l’utilisateur n’entendra ni « bouton », ni qu’il est cliquable — l’élément sera invisible pour lui. Ton HTML est l’interface pour ces utilisateurs.

<!-- ❌ Le lecteur d'écran n'annonce ni le rôle « bouton », ni l'état -->
<div class="btn" onclick="valider()">Valider</div>
 
<!-- ✅ Annoncé « Valider, bouton », focusable et activable au clavier nativement -->
<button type="button" onclick="valider()">Valider</button>

♿ Côté utilisateur — Face au premier exemple, une personne aveugle entend juste « Valider », sans savoir que c’est cliquable, et ne peut même pas l’atteindre au clavier. Face au second, elle entend « Valider, bouton », y accède avec Tab et l’active avec Entrée ou Espace. Le même mot à l’écran, deux expériences radicalement différentes — et la seule différence, c’est le choix de la balise.

La technologie d’assistance lit l’arbre d’accessibilité

Sous le capot, le navigateur construit à partir de ton DOM un arbre d’accessibilité (accessibility tree) : une version simplifiée où chaque élément a un nom, un rôle et un état/valeur. C’est cet arbre que les technologies d’assistance consomment. On l’étudiera en détail (Partie 5), mais retiens dès maintenant le triptyque qui reviendra sans cesse : nom / rôle / valeur (name / role / value).

🧭 Sur A11yLearn — Notre fil rouge, la plateforme A11yLearn, aura des utilisateurs de chacune de ces familles : un apprenant aveugle sur NVDA, un malvoyant qui zoome à 300 %, un apprenant à mobilité réduite qui ne navigue qu’au clavier, un sourd qui a besoin des vidéos sous-titrées. À chaque partie, on gardera ces personnes en tête : ce n’est pas « la norme WCAG » qu’on satisfait, ce sont elles.

✏️ Exercices

Exercice 1 — Associe outil et besoin. Pour chaque personne, cite une technologie d’assistance probable : (a) une personne aveugle, (b) une personne malvoyante, (c) une personne tétraplégique, (d) une personne sourde regardant une vidéo.

Exercice 2 — Pourquoi la <div> échoue. Explique, du point de vue du lecteur d’écran, pourquoi un « bouton » fait en <div onclick> pose problème, et cite deux choses que le <button> natif apporte gratuitement.

🧠 Quiz de révision

Chapitre suivant : Pourquoi ça compte — les quatre arguments (humain, légal, business, qualité) pour prendre l’a11y au sérieux.