Accessibilité Web 8 min de lecture

La chaîne brisée

Vingt ans après : ce que j'ai appris en rouvrant un livre que je croyais connaître

Par
Gros plan sur un clavier d'ordinateur portable avec une touche bleue mise en avant, marquée « accessibility », avec une icône de fauteuil roulant, à côté de touches portant des symboles d'œil, d'oreille et de braille.

En 2009, j’ai écrit un livre sur l’accessibilité web. C’était le premier publié au Brésil sur le sujet, du moins à ma connaissance. À l’époque, j’étais étudiant en fin de cycle, et le thème m’était tombé dessus presque par hasard : un chapitre de mon mémoire de fin d’études sur les technologies web avait attiré l’attention de mon directeur de recherche. Nous avions décidé d’en faire quelque chose de plus grand.

Je me souviens de la réunion qui a tout déclenché. Nous étions chez la directrice des éditions Edufal, la maison d’édition de l’Université Fédérale d’Alagoas, pour parler d’un éventuel projet autour des standards web. Elle nous a mentionné, presque en passant, un e-mail reçu quelques jours plus tôt. Un lecteur aveugle se plaignait de ne pas pouvoir accéder au site présentant la nouvelle collection de livres en braille de l’éditeur. Il ne pouvait même pas lire les titres des ouvrages qui lui étaient destinés.

Je n’ai pas eu besoin d’en entendre davantage. Je suis sorti de cette réunion avec un accord pour écrire le livre, et un projet concret pour rendre ce site accessible.

Vingt ans plus tard, j’ai rouvert ce livre. Pas pour le relire, cette fois : pour le réécrire.

La décision de recommencer

L’idée initiale était modeste : mettre à jour quelques références, intégrer les WCAG 2.2, ajouter des design patterns plus récents. Une révision, pas une réécriture. Mais en relisant les premiers chapitres, j’ai réalisé que le problème n’était pas l’ancienneté des données. C’était le cadre conceptuel lui-même.

En 2009, l’accessibilité web était présentée, dans mon livre comme dans la plupart des ressources de l’époque, comme une liste de recommandations à respecter. Un ensemble de critères techniques à cocher pour être « conforme ». La question implicite était : comment rendre un site accessible ? La question plus profonde, pourquoi tant de sites ne le sont toujours pas, restait sans réponse.

Alors j’ai recommencé. Pas une mise à jour. Une réécriture complète, en français cette fois, comme une façon de restituer ce que j’ai appris au Québec. Et en retournant aux sources, j’ai découvert quelque chose d’inconfortable.

Les chiffres qui ne bougent pas

Chaque année depuis 2019, l’organisation WebAIM publie le WebAIM Million : une analyse automatisée de l’accessibilité du million de pages d’accueil les plus visitées au monde. C’est l’un des baromètres les plus fiables du secteur.

En 2019, 97,8 % des pages présentaient des erreurs d’accessibilité détectables.

En 2026, ce chiffre est de 95,9 %. Avec une moyenne de 56,1 erreurs par page, en hausse de 10,1 % par rapport à l’année précédente.

Sept ans de rapports. Une amélioration de 2 points de pourcentage. Et une augmentation du nombre moyen d’erreurs par page.

Ce n’est pas un échec technique. Les outils existent. Les guidelines sont publiques, gratuites, bien documentées. Les six catégories d’erreurs qui représentent 96 % de toutes les défaillances détectées sont les mêmes depuis sept ans consécutifs : textes alternatifs absents, contrastes insuffisants, étiquettes de formulaires manquantes, liens sans intitulé descriptif. Des problèmes élémentaires. Des problèmes connus.

Alors pourquoi ?

Ce que j’ai compris en cherchant la réponse

En creusant la littérature récente, j’ai trouvé une donnée qui m’a arrêté net : 62 % des développeurs français ignorent les normes d’accessibilité. Pas seulement les détails techniques : les normes elles-mêmes.

Et même parmi ceux qui les connaissent, l’accessibilité est traitée comme une vérification de fin de projet. Un audit réalisé après coup. Une case à cocher avant la mise en ligne. Cette approche a un nom dans le secteur : le bolt-on accessibility, l’accessibilité vissée après coup, comme un accessoire ajouté à un produit fini.

C’est précisément ce que mon premier livre encourageait, sans le dire explicitement. En présentant l’accessibilité comme une liste de critères à valider, je reproduisais sans le savoir le cadre qui maintient le problème en place.

La question n’est donc pas : comment rendre un site accessible ? La question est : pourquoi continuons-nous à construire des sites inaccessibles malgré quinze ans de législation, d’outils et de guidelines ?

Une rupture de chaîne, pas une erreur de code

Ce qui m’a le plus frappé en reprenant ce sujet, c’est que l’inaccessibilité n’est presque jamais le résultat d’une erreur isolée. C’est le résultat d’une rupture dans une chaîne.

Le Web fonctionne comme un écosystème de composants interdépendants : les créateurs de contenu, les outils qu’ils utilisent, les navigateurs qui interprètent le code, et les technologies d’assistance qui le restituent à l’utilisateur. Quand un maillon de cette chaîne cède, l’expérience entière s’effondre, même si tous les autres maillons sont solides.

Un développeur peut produire une vidéo parfaitement sous-titrée. Si le lecteur vidéo intégré au site ne propose pas de bouton accessible au clavier pour activer ces sous-titres, l’effort est annulé. Un auteur peut structurer son contenu avec une hiérarchie de titres irréprochable. Si son CMS génère automatiquement un code qui écrase cette structure, le travail disparaît.

L’inaccessibilité, dans la grande majorité des cas, n’est pas un oubli. C’est une conséquence prévisible d’une conception qui n’a pas intégré l’accessibilité dès le départ.

Ce que ce livre essaie de faire différemment

La nouvelle édition que je suis en train d’écrire part de ce constat. Elle ne propose pas une liste de critères à respecter. Elle propose une approche d’ingénierie : des design patterns, des méthodes, des cadres de réflexion qui permettent d’intégrer l’accessibilité dans le processus de conception, pas après.

Les WCAG 2.2 y ont leur place, non pas comme une checklist bureaucratique, mais comme une base technique pour comprendre pourquoi certaines décisions de conception excluent des utilisateurs et comment les corriger structurellement.

Le livre s’adresse aux développeurs, aux designers, aux créateurs de contenu, aux chefs de projet, et à quiconque publie quelque chose sur le Web et veut comprendre à qui son contenu est réellement accessible.

Je vais documenter cette écriture ici, au fur et à mesure. Les recherches, les doutes, les décisions éditoriales, les surprises.

La première surprise, vous l’avez déjà lue : vingt ans après, le problème n’a presque pas bougé. Mais les raisons ont changé. Et c’est là que ça devient intéressant.