Pourquoi l’attribut alt existe depuis HTML 2.0, et ce qu’il ratait à l’origine

En novembre 1995, l’IETF publie la RFC 1866, qui formalise ce que l’on appellera HTML 2.0. L’élément <img> y figure déjà, avec un attribut alt présenté comme une exigence : un texte de remplacement doit être fourni pour les agents utilisateurs qui ne peuvent pas afficher l’image. La formulation est sobre, presque administrative, et elle ne mentionne à aucun moment le handicap visuel.

Comprendre cette origine change la façon d’écrire un texte alternatif aujourd’hui. L’attribut n’a pas été conçu comme un outil d’accessibilité au sens où on l’entend maintenant : il a été détourné, enrichi, réinterprété au fil des années pour répondre à un besoin que ses créateurs n’avaient pas anticipé avec cette précision.

Le problème que alt devait résoudre en 1995

Le web du milieu des années 1990 tourne majoritairement sur des connexions par modem, à quelques kilooctets par seconde. Les images se chargent lentement, parfois pas du tout selon la configuration du navigateur. Des navigateurs texte comme Lynx, déjà largement utilisés, n’affichent tout simplement aucune image. L’attribut alt répond d’abord à cette contrainte matérielle : donner un texte à afficher à la place d’un contenu binaire absent ou en attente.

Marc Andreessen, dans les discussions préparatoires à Mosaic quelques années plus tôt, avait déjà évoqué l’idée d’un texte de repli pour les images. La RFC 1866 reprend ce principe et le rend obligatoire dans la grammaire du langage, sans imposer de contrôle réel : rien n’empêchait alors, et rien n’empêche toujours, de laisser un attribut vide ou incohérent.

Ce que la spécification originelle ne traitait pas

Trois manques structurent encore aujourd’hui les erreurs les plus fréquentes sur alt, et les trois viennent de cette origine :

• Aucune distinction entre image décorative et image porteuse d’information. La notion d’un alt="" volontaire, signalant à un lecteur d’écran d’ignorer l’image, ne s’impose que progressivement, bien après 1995, à mesure que les technologies d’assistance se standardisent autour du texte alternatif.
• Aucune indication sur la longueur ou le style rédactionnel. Rien ne distingue un alt de trois mots d’une description de trois phrases ; cette question ne sera outillée que plus tard, notamment via longdesc en HTML 4, un attribut aujourd’hui retiré des spécifications du fait de son adoption trop faible et de son support inégal.
• Aucun lien avec le contexte d’usage de l’image. Le même fichier peut nécessiter un texte différent selon qu’il illustre un article ou qu’il sert de lien vers une autre page ; la spécification de 1995 ne dit rien de cette dépendance au contexte.

Comment la pratique a comblé ces manques

Ce sont les guides de rédaction produits par les communautés d’accessibilité, bien plus que les spécifications elles-mêmes, qui ont fixé les règles aujourd’hui enseignées : décrire la fonction plutôt que l’apparence pour un lien-image, laisser vide pour une image purement décorative, éviter les préfixes redondants comme « image de » puisque les lecteurs d’écran annoncent déjà la nature de l’élément. Ces conventions n’ont jamais été gravées dans la grammaire HTML ; elles relèvent de bonnes pratiques transmises par la documentation et par l’expérience de terrain.

Le développement de la norme WCAG, dont la première version date de 1999, formalise ensuite l’exigence sous la forme d’un critère de succès dédié aux contenus non textuels, sans toucher à la définition technique de l’attribut lui-même : la balise reste celle de 1995, seule son interprétation évolue.

Ce que cela change pour un développeur WordPress aujourd’hui

Dans l’éditeur de blocs, le champ « texte alternatif » d’un bloc image repose toujours sur ce même attribut alt, hérité tel quel depuis vingt-cinq ans. Aucune évolution du HTML n’a modifié sa mécanique : ce qui a changé, c’est l’attente que l’on porte sur son contenu. Un champ resté vide n’est plus une négligence mineure, c’est un manquement direct au critère 1.1.1 des Web Content Accessibility Guidelines, consacré aux contenus non textuels.

<!-- Image porteuse d'information : décrire la fonction -->
<img src="graphique-frequentation.png" alt="Frequentation en hausse de 40 % entre janvier et juin">

<!-- Image purement decorative : alt vide, jamais absent -->
<img src="motif-fond.png" alt="">

La différence entre un alt absent et un alt vide est souvent mal comprise : l’absence de l’attribut laisse un lecteur d’écran annoncer le nom du fichier ou son chemin complet, une information sans aucune valeur, alors qu’un attribut vide signale explicitement une décision assumée.

Une trace persistante d’un choix ancien

Peu d’éléments HTML ont conservé une syntaxe aussi stable depuis 1995. Cette stabilité a un revers : elle donne l’illusion d’une évolution achevée, alors que la spécification n’a jamais rattrapé l’écart entre son intention d’origine et son usage actuel. Comprendre cette histoire aide à ne pas traiter alt comme une simple case à cocher dans un formulaire de publication, mais comme l’héritage d’une contrainte technique des années 1990, réinterprétée depuis pour servir un besoin bien plus large.

Un repère utile en relecture éditoriale : si le texte alternatif proposé pourrait légender la photo dans un magazine imprimé, il décrit probablement l’apparence plutôt que la fonction, et mérite d’être reformulé.

Notion à retenir

alt n’a jamais été pensé, à l’origine, comme un dispositif d’accessibilité pour les lecteurs d’écran. Il a été conçu pour un web sans images fiables, sur des connexions lentes, à une époque où le handicap visuel n’apparaissait pas dans les motivations documentées de sa création. Son détournement progressif vers un usage d’accessibilité est une réussite collective de la communauté du web, pas une intention initiale du langage.