Une image de couverture d’article de blog avec un attribut alt est un problème résolu. Un diagramme STEM ne l’est pas. Trois propriétés des illustrations scientifiques brisent les hypothèses intégrées à alt, aria-label et au modèle vocal des lecteurs d’écran.

Premièrement, la densité d’information est suffisamment élevée pour qu’une seule phrase ne puisse pas la restituer. Un noyau de benzène, ce sont six carbones, six hydrogènes, des liaisons doubles alternées, un système pi délocalisé, une géométrie plane, une longueur de liaison de 1,39 angström. La convention du texte alternatif demande « un bref remplacement textuel » ; le benzène nécessite un paragraphe entier. Le comprimer en une phrase fait soit perdre les informations structurelles (« une molécule de benzène »), soit produit un texte continu illisible que le lecteur d’écran doit épeler à 180 mots par minute.

Deuxièmement, les relations entre les éléments portent autant de sens que les éléments eux-mêmes. Dans un diagramme de forces, la flèche du bloc vers le mur n’est pas décorative — c’est la force normale, et son angle par rapport au vecteur gravitationnel est la réponse au problème. Une description plate ne peut pas encoder « l’angle entre ces deux flèches est de 90 degrés et c’est pourquoi le problème se résout ainsi », car la description plate n’a pas de structure. Le SVG, utilisé avec soin, en possède une.

Troisièmement, les étudiants en sciences ont besoin de naviguer dans le diagramme, pas seulement de l’entendre. Un apprenant qui travaille sur la courbe d’une fonction cubique ne veut pas entendre le texte alternatif du début à la fin — il veut atterrir sur le maximum local, demander « quelle est la pente ici », puis passer au point d’inflexion. C’est un modèle d’interaction différent de celui que les lecteurs d’écran proposent par défaut. Le construire nécessite des gestionnaires de clavier sur chaque nœud SVG, un arbre de contenu décrit par ARIA, et un mécanisme de secours pour les piles de technologies d’assistance qui ne suivent pas.

Presque tous les manuels de sciences publiés livrent encore leurs diagrammes en PNG ou JPG. Une image raster est une grille de pixels opaque : elle n’offre qu’un seul point d’entrée pour les technologies d’assistance, l’attribut alt, et un seul mécanisme de secours, l’attribut longdesc que les navigateurs ont passé dix ans à déprécier. Il n’existe pas de structure interne à l’image qu’un lecteur d’écran puisse adresser. Le diagramme est une boîte noire avec une étiquette sur la façade.

SVG inverse ce modèle. Chaque forme dans un document SVG est un nœud DOM — adressable, focusable, étiquetable. Un noyau de benzène rendu en SVG comprend six éléments circle pour les carbones, six éléments line pour les liaisons, et un élément englobant g qui nomme l’ensemble. Chacun de ces nœuds peut porter des attributs role, aria-label, aria-labelledby, aria-describedby et tabindex. Le lecteur d’écran voit un arbre d’accessibilité de régions nommées plutôt qu’un seul bloc opaque.

Le SVG accessible minimal porte trois éléments sur son élément racine svg : role=“img”, aria-labelledby pointant vers un enfant title, et aria-describedby pointant vers un enfant desc ou vers un paragraphe externe identifié par son ID. Chacun est compact. Chacun fait un travail que les deux autres ne peuvent pas faire.

Un avertissement important : role=“img” sur l’élément racine svg change le comportement des technologies d’assistance vis-à-vis des enfants. Avec role=“img”, NVDA et JAWS traitent tout le SVG comme une seule image étiquetée et n’exposent pas les nœuds internes — même si ces nœuds internes ont un attribut tabindex. Pour obtenir les deux comportements — une étiquette sommaire en haut et des enfants adressables à l’intérieur — laissez le rôle racine non défini (ou utilisez role=“graphics-document” du module W3C Graphics ARIA) et placez l’étiquette sur un g enfant plutôt que sur la racine. Les navigateurs et les lecteurs d’écran gèrent cette combinaison de manière inégale. La matrice de la section 6 documente ce qui fonctionne et où.

L’attribut longdesc était la réponse initiale à « un attribut alt ne suffit pas ». Les navigateurs ont progressivement cessé de le supporter ; Firefox l’a abandonné à la version 90, Safari ne l’a jamais implémenté, Chrome le traite comme une opération nulle. Quiconque écrit encore longdesc=“benzene-desc.html” en 2026 livre un balisage que rien ne lit. Le remplacement n’est pas un attribut unique mais un schéma à trois couches qui combine une description intégrée, un panneau extensible visible, et des métadonnées lisibles par machine.

La première couche est l’élément desc intégré dans le SVG. Deux à quatre phrases. Lu par les lecteurs d’écran lorsque la racine SVG est annoncée. C’est le nouveau longdesc — une description qui fait partie du document SVG et qui le suit partout où le SVG est utilisé.

La deuxième couche est un panneau de description extensible visible placé à côté du diagramme, accessible à tout lecteur, pas seulement aux utilisateurs de lecteurs d’écran. Une ligne de résumé plus un bouton de divulgation qui ouvre une description textuelle plus longue — généralement trois à dix phrases pour une molécule chimique, plus pour un diagramme de structure cellulaire avec vingt organites étiquetés. Le panneau visible résout un problème que l’élément desc intégré ne peut pas résoudre : les étudiants qui voient le diagramme mais ne peuvent pas le décoder (apprenants malvoyants, apprenants dyslexiques, toute personne apprenant la matière pour la première fois) ont également besoin de la description longue. La placer derrière un bouton ne la cache pas aux lecteurs d’écran — ceux-ci énumèrent la divulgation, l’utilisateur l’active, et la description est lue dans le tampon.

La troisième couche est constituée de métadonnées structurées via JSON-LD. Un objet CreativeWork dont le tableau accessibilityFeature énumère ce que le diagramme offre : longDescription, alternativeText, structuralNavigation, describedMath, tactileGraphic (si une version tactile imprimable est disponible). Les moteurs de recherche, les recommandateurs de contenu et les scanners de conformité d’accessibilité consomment tous ces métadonnées. Elles ne font rien pour l’expérience immédiate de lecture par lecteur d’écran, mais elles rendent le diagramme découvrable en tant que contenu accessible — ce qui compte lorsqu’un apprenant choisit entre trois manuels et que l’un d’eux annonce ses fonctionnalités d’accessibilité sous forme lisible par machine.

Les diagrammes statiques sont le cas simple. Le cas difficile est le diagramme animé — une mitochondrie qui tourne en 3D, une sinusoïde tracée sur l’axe des x, une réaction chimique avec des liaisons qui se rompent et se reforment en quatre secondes. La réponse habituelle est un fichier vidéo avec une piste d’audiodescription, mais cela abandonne l’adressabilité du SVG : dès que l’animation est encodée dans une vidéo, chaque nœud soigneusement étiqueté cesse d’être un nœud DOM et redevient un pixel.

L’alternative accessible consiste à conserver l’animation en SVG (ou en Canvas avec un arbre d’accessibilité hors écran) et à émettre des audiodescriptions à mesure que l’animation progresse, pilotées par les mêmes mutations DOM qui pilotent le changement visuel. Le schéma : un MutationObserver surveille le SVG pour détecter les modifications — un nouvel attribut transform, une liaison qui apparaît, un vecteur qui pivote — et à chaque changement significatif, il écrit une courte mise à jour textuelle dans une région aria-live=“polite” globale. L’animation visuelle génère une narration audio à la volée à partir de la même source de vérité.

L’implémentation comporte trois éléments mobiles. Le premier est l’animation elle-même, exprimée comme une séquence d’images clés de chronologie — les mêmes données que le moteur de rendu SVG utilise. Le second est une couche d’annotation : chaque image clé porte une courte description de ce qui change à ce moment (« liaison formée entre C1 et C2 », « l’onde passe par zéro en montant »). Le troisième est le pilote d’audiodescription, qui s’abonne à la chronologie, recueille chaque image clé annotée et écrit son texte dans la région dynamique quelques centaines de millisecondes avant que le changement visuel se produise. Le délai correspond à ce que fait l’audiodescription de production dans le cinéma : la description est entendue juste avant l’événement visuel, et non après.

Trois modes d’échec sont suffisamment courants pour mériter d’être signalés. Premièrement, les mises à jour en rafale. Une animation qui déclenche 60 mutations par seconde submerge le synthétiseur du lecteur d’écran — les annonces s’accumulent, retardent l’animation et deviennent incompréhensibles. Il faut n’annoter que les images clés sémantiquement significatives, et non chaque trame, et limiter à environ une annonce toutes les 1 500 ms. Deuxièmement, le début manqué. Une région dynamique qui n’existait pas avant le début de l’animation n’annoncera pas sa première mise à jour de manière fiable (voir l’article sur le framework aria-live pour le problème sous-jacent du planificateur). Il faut monter la région dynamique vide au chargement de la page. Troisièmement, l’absence de commande de pause. Les utilisateurs ont besoin de mettre en pause l’audiodescription, de la ralentir ou de la parcourir événement par événement. Il faut construire une petite barre de commande — lecture, pause, événement précédent, événement suivant — et relier ses boutons au même pilote de chronologie.

Un graphe de fonction mathématique qu’un étudiant voyant peut parcourir avec le curseur n’est pas accessible tant qu’un étudiant non-voyant ne peut pas le parcourir avec le clavier. Le mécanisme est bien connu et mal implémenté dans la pratique : chaque point de données significatif sur la courbe reçoit tabindex=“0”, un aria-label décrivant ses coordonnées et toute caractéristique nommée (« maximum local en x = -1, y = 4 »), et un gestionnaire de clavier qui répond aux touches fléchées pour un déplacement précis entre les points adjacents.

La granularité appropriée compte plus qu’on ne le réalise. Tabuler à travers chaque pixel tracé d’une courbe cubique est hostile — l’utilisateur entend des milliers de « x égal 0,1, y égal 0,001 » avant d’atteindre quoi que ce soit d’intéressant. Tabuler uniquement sur les caractéristiques nommées (maxima locaux, minima, points d’inflexion, intersections avec les axes x et y) est trop rare. Le compromis pragmatique : deux couches de navigation. La touche Tab parcourt uniquement les caractéristiques nommées — généralement trois à sept sur une courbe — et les touches fléchées, une fois qu’une caractéristique est mise en focus, se déplacent à gauche et à droite le long de la courbe à une taille de pas définie par l’apprenant, en annonçant la coordonnée à chaque pas. Origine et Fin sautent aux limites gauche et droite de la courbe. Page Haut et Page Bas sautent à la caractéristique nommée suivante.

Pour un graphique à plusieurs séries — un tracé cinétique en chimie, un graphe d’oscillation en physique avec deux formes d’onde — il faut ajouter un axe de commutation de séries. Les touches fléchées Haut et Bas se déplacent entre les séries à la coordonnée x courante ; Gauche et Droite se déplacent le long de la série courante. La convention est parallèle à la façon dont les lecteurs de tableurs naviguent dans les lignes et les colonnes, réutilisant un modèle mental que de nombreux utilisateurs possèdent déjà.

Un détail souvent négligé : le point de données mis en focus a besoin d’un indicateur de focus visible. Un utilisateur non-voyant n’en a pas besoin, mais un utilisateur voyant utilisant un lecteur d’écran, oui — de même que les instructeurs partenaires qui regardent par-dessus l’épaule de l’étudiant. Il faut rendre un anneau de focus autour de l’élément SVG mis en focus avec le style :focus-visible — la même convention que les anneaux de focus des boutons, appliquée aux nœuds SVG que le navigateur ne style pas par défaut.

La vérité la plus difficile à accepter dans cet article : la pile SVG accessible ne fonctionne pas de la même façon selon les navigateurs et les lecteurs d’écran, et les lacunes ne sont pas des bugs dans votre balisage. NVDA sur Firefox est la combinaison la plus fiable — la seule où chaque schéma de cet article se comporte comme le dit la correspondance d’accessibilité SVG du W3C. Toute autre combinaison présente au moins une lacune connue.

Safari sur macOS avec VoiceOver est la pile principale la plus problématique. L’arbre d’accessibilité SVG de WebKit présente des lacunes documentées dans la façon dont il expose les éléments g internes avec des étiquettes ARIA : les étiquettes sont présentes dans le DOM et inspectables avec l’inspecteur d’accessibilité, mais VoiceOver ne les récupère pas toujours lorsque l’utilisateur navigue avec VO-Flèche droite. Le comportement est incohérent — parfois les étiquettes internes sont annoncées, parfois seule l’étiquette SVG racine est lue, sans schéma visible côté client. Le bugzilla de WebKit comporte des problèmes ouverts remontant à 2020 sur ce point. L’implication pratique : si votre diagramme STEM fonctionne sur Mac, c’est une condition nécessaire, pas suffisante. Il faut tester sur Windows avec NVDA avant de livrer.

Chrome sur Windows avec JAWS est la deuxième pile la plus fiable — proche de NVDA + Firefox, avec une nuance : JAWS traite role=“img” sur un SVG de manière plus agressive que NVDA, en repliant les nœuds internes plus souvent. La correction consiste à utiliser role=“graphics-document” du module W3C Graphics ARIA sur le svg racine, que JAWS gère correctement. NVDA le gère aussi correctement. Firefox et Chrome fournissent tous deux les correspondances d’API de plateforme nécessaires.

Le mobile est un problème distinct. VoiceOver sur iOS hérite des lacunes SVG de WebKit ; TalkBack sur Android avec Chrome gère les nœuds internes de manière fiable mais ne prend pas encore en charge les rôles W3C Graphics ARIA, donc il se replie sur le comportement role=“img”. Pour un éditeur de manuels ciblant à la fois le bureau et le mobile, le choix sûr est de livrer deux modes SVG : un mode à navigation structurée pour le bureau et un mode « résumé plus description longue » qui désactive la navigation interne sur mobile. La commutation de mode est pilotée par l’agent utilisateur et par la préférence de l’utilisateur, stockée entre les sessions.

Une lecture de la matrice : adopter NVDA + Firefox comme cible de conformité de référence, documenter les mécanismes de secours pour Safari et TalkBack, et ne jamais utiliser l’absence d’une annonce de nœud interne sur Mac comme preuve que le SVG est inaccessible. Le diagramme peut être parfaitement accessible — la plateforme n’expose simplement pas les étiquettes que vous avez écrites. L’inspecteur d’accessibilité dans le menu Développement de Safari montre ce qui est dans l’arbre même quand VoiceOver échoue à le lire, et c’est le bon outil pour distinguer « balisage cassé » de « plateforme cassée ».

La plupart des guides publiés sur l’accessibilité des diagrammes STEM s’arrêtent à la couche title-et-desc. C’est les 30 % faciles. Les 70 % restants — le panneau de description longue, la chronologie d’audiodescription pilotée par les mutations DOM, la navigation au clavier à deux granularités, les mécanismes de secours spécifiques à la plateforme — relèvent autant de la conception d’interaction que du balisage. Le lecteur d’écran est un utilisateur ; un apprenant non-voyant utilisant un lecteur d’écran pour naviguer dans une courbe de fonction au rythme d’un camarade voyant en est un autre, avec des besoins différents.

Le dividende est important et inégalement réparti. Un éditeur de manuels qui livre la pile complète sur environ 600 diagrammes dans un manuel de calcul sert chaque apprenant non-voyant utilisant ce manuel, chaque apprenant malvoyant qui apprécie le panneau de divulgation, chaque apprenant dyslexique qui peut lire la description longue mais ne peut pas décoder le visuel, chaque apprenant dont la langue première n’est pas la langue du manuel et qui trouve la description structurée plus accessible que les conventions visuelles du domaine, et chaque instructeur voyant produisant des résumés audio pour des podcasts. Le même balisage sert cinq publics distincts. Le coût est de quelques heures par diagramme, amorti sur des décennies d’utilisation par les étudiants.

L’état actuel de l’art est inégal parce que les implémentations de l’arbre d’accessibilité diffèrent selon les systèmes d’exploitation que les étudiants utilisent réellement. NVDA et JAWS sur Windows ont comblé la plupart des lacunes SVG. Safari sur macOS ne l’a pas fait. Jusqu’à ce que les plateformes convergent, le schéma de production consiste à créer pour la cible la plus stricte — NVDA + Firefox — et à documenter les mécanismes de secours pour les plateformes présentant des lacunes connues. C’est plus de travail que ce que nécessitait le modèle du texte alternatif. C’est aussi le seul moyen de livrer un manuel de sciences qui n’exclut pas les lecteurs qu’il est censé enseigner.