Accessibilité web : comment on lit une page sans la voir

Un lecteur d’écran, le logiciel qui lit la page à voix haute pour un non-voyant, ne regarde pas votre site : il lit l’arbre d’accessibilité, une version de la page réduite aux rôles et aux noms de ses éléments ; Microsoft expose ce même arbre aux agents IA avec Playwright MCP, et OpenAI dit s’appuyer sur les mêmes rôles et libellés pour son navigateur Atlas. Qu’un site accessible soit mieux compris par ces agents est une déduction, pas une mesure ; ce qui est mesuré, c’est que 95,9 % des pages d’accueil du premier million de sites échouent à au moins un test automatique (WebAIM, février 2026), et qu’un défaut comme un contraste trop faible ne laisse aucune trace dans cet arbre. Aucune source consultée ne mesure l’effet de l’accessibilité sur le taux de réussite d’un agent IA, ni sur le classement dans Google.

Trois façons de lire une page sans la voir

Une personne aveugle navigue avec un lecteur d’écran : JAWS ou NVDA sur ordinateur, VoiceOver ou TalkBack sur téléphone. Le logiciel annonce chaque élément par la voix, ou l’affiche sur une plage braille, une barre de picots qui forme les lettres sous les doigts. Dans l’enquête WebAIM de 2024 auprès de 1 539 utilisateurs de lecteurs d’écran, 91,3 % en utilisent aussi un sur mobile.

Une personne malvoyante, elle, regarde encore la page, mais autrement : agrandie à 200 ou 400 %, en contraste renforcé, avec une loupe logicielle. Elle ne passe pas forcément par l’arbre. Ce qui la bloque, ce sont les pixels : un texte gris clair, une mise en page qui déborde quand on zoome. La frontière est poreuse : 19,9 % des répondants de l’enquête WebAIM se déclarent malvoyants, et 16,7 % déclarent plusieurs handicaps.

Les agents IA, ces programmes qui naviguent et agissent sur un site à la place de l’utilisateur, se rangent dans les deux mêmes familles. Le premier canal passe par l’arbre d’accessibilité, que le navigateur construit à partir du HTML, le code de la page.

Côté arbre : le README de Playwright MCP, le serveur d’automatisation de navigateur de Microsoft destiné aux modèles d’IA, résume son principe en une ligne, « Uses Playwright’s accessibility tree, not pixel-based input » (il utilise l’arbre d’accessibilité de Playwright, pas une entrée en pixels). OpenAI écrit dans sa FAQ pour les éditeurs qu’Atlas s’appuie sur les rôles et libellés ARIA (des attributs ajoutés au HTML pour décrire un élément aux technologies d’assistance) — les mêmes que ceux des lecteurs d’écran.

Côté pixels : le même OpenAI décrivait en janvier 2025 son agent Operator ainsi : « CUA processes raw pixel data to understand what’s happening on the screen » (l’agent traite les pixels bruts pour comprendre ce qui se passe à l’écran). Par déduction, un agent qui lit l’arbre bute sur les mêmes manques qu’un lecteur d’écran, puisqu’il lit la même structure ; un agent qui lit l’écran buterait plutôt sur ceux d’un malvoyant. La mesure publiée plus bas vérifie la première moitié du raisonnement sur l’arbre lui-même, pas sur un agent. Pour la seconde, aucune source consultée ne mesure qu’un contraste faible gêne un agent à pixels.

Les titres, la table des matières d’un non-voyant

Un voyant parcourt une page d’un coup d’œil. Un non-voyant la parcourt par ses titres, les balises <h1> à <h6>, sautant de l’un à l’autre avec une touche. Dans l’enquête WebAIM, face à une longue page, 71,6 % des répondants commencent par naviguer de titre en titre ; 13,6 % utilisent la recherche, 6,4 % lisent tout. Et 88,8 % jugent les niveaux de titres (titre 1, titre 2…) très ou assez utiles.

Or le relevé WebAIM Million 2026, qui passe chaque année les pages d’accueil du premier million de sites au moteur de tests automatiques WAVE, trouve des niveaux sautés — un <h2> suivi d’un <h4> — sur 41,8 % des pages, plus d’un <h1> sur 18,1 %, et aucun titre du tout sur 7,5 %.

Trois règles suffisent :

• Un seul <h1> par page, qui dit de quoi parle la page.
• Des niveaux qui s’emboîtent comme un sommaire : un <h3> vit sous un <h2>. Un titre choisi pour sa taille de police ment sur la structure.
• Des régions balisées : <header>, <nav>, <main>, <footer>. Ce sont les repères (landmarks) vers lesquels le lecteur d’écran saute. WebAIM ne trouve un <main> que sur 46,1 % des pages, et un lien d’évitement (« aller au contenu ») que sur 17,1 % — dont un sur dix cassé.

Images : un texte alternatif qui dit ce qui compte

Le texte alternatif, l’attribut alt d’une image, est ce que le lecteur d’écran prononce à sa place. WebAIM trouve des images sans alt sur 53,1 % des pages d’accueil. Sur 66,6 images par page en moyenne, 16,2 % n’en ont pas, et 10,8 % des images qui en ont un portent un texte inutile : « image », un nom de fichier, ou la répétition du texte voisin.

La règle tient en une question : que perdrait un lecteur qui ne voit pas l’image ?

• Image informative (un graphique, une photo produit) : décrire l’information, pas l’objet. « Graphique » ne dit rien ; « ventes en hausse de 12 % en mars » dit tout.
• Image décorative : alt="", vide mais présent. Le lecteur d’écran l’ignore. Sans l’attribut, certains lecteurs d’écran annoncent à la place le nom du fichier.
• Image-lien : décrire la destination. WebAIM note que 45 % des images sans alt sont des liens — le lien devient muet.

Le texte alternatif est le point où accessibilité et référencement se recoupent le plus nettement. La documentation de Google explique que le moteur combine l’alt, la vision par ordinateur et le contenu de la page pour comprendre une image. Elle met aussi en garde contre le bourrage de mots-clés dans cet attribut, qui « may cause your site to be seen as spam » (peut faire percevoir votre site comme du spam). Un alt écrit pour le non-voyant est donc aussi le bon alt pour Google ; l’inverse n’est pas vrai.

Liens, boutons, champs : nommer ce que fait chaque élément

Un lecteur d’écran permet de lister tous les liens d’une page, hors contexte. Dix fois « cliquez ici », c’est une liste inutilisable. WebAIM relève des liens vides — sans aucun texte, souvent une icône seule — sur 46,3 % des pages, des boutons vides sur 30,6 %, et des champs de formulaire sans étiquette sur 51 % des pages. Un tiers des champs relevés n’ont pas d’étiquette.

Pour voir ce que l’arbre d’accessibilité retient réellement, six paires de fragments HTML ont été passées à l’API d’accessibilité de Playwright 1.56, la bibliothèque sur laquelle repose Playwright MCP. Chaque paire oppose un défaut courant à sa correction :

Défaut testé	Ce que l’arbre retient du défaut	Ce qu’il retient de la correction
<div onclick> au lieu de <button>	le texte « Payer », sans rôle	button "Payer"
image sans alt	img, sans nom	img "Graphique : ventes en hausse de 12 % en mars"
lien « cliquez ici »	link "cliquez ici"	link "Voir nos tarifs"
champ sans <label>	textbox, sans nom	textbox "Adresse e-mail"
<div> en gros caractères au lieu de <h2>	le texte « Livraison », sans rôle	heading "Livraison" [level=2]
texte gris #e8e8e8 sur blanc (contraste 1,23:1)	paragraph: Offre valable jusqu'au 30 juin	identique, octet pour octet

Mesure de l’article, septembre 2026, script publié plus bas. Le « bouton » en <div> n’existe pas dans l’arbre : un non-voyant l’entend comme du texte, et un agent qui cherche un élément de rôle bouton ne le trouve pas. La dernière ligne est la plus instructive : un contraste de 1,23:1, illisible pour un malvoyant, donne un arbre identique à celui d’un contraste de 17,74:1. L’arbre ne porte pas la couleur. Un agent à arbre ne voit donc pas ce défaut, et ne peut pas le signaler.

La règle : chaque élément interactif porte un nom qui dit ce qu’il fait, lisible hors contexte. Un bouton-icône reçoit un texte, visible ou non. Un champ a son <label> relié par l’attribut for ; le texte d’exemple grisé dans le champ (placeholder) disparaît dès qu’on tape et ne remplace pas l’étiquette.

"""mesure.py — ce que l'arbre d'accessibilité retient de 6 paires de fragments.
Python 3, playwright 1.56 : pip install playwright"""
import hashlib
from playwright.sync_api import sync_playwright

PAIRES = [
 ("Bouton", '<div class="btn" onclick="payer()">Payer</div>',
            '<button type="button" onclick="payer()">Payer</button>'),
 ("Image", '<img src="data:image/gif;base64,R0lGODlhAQABAAAAACw=" width="40" height="40">',
           '<img src="data:image/gif;base64,R0lGODlhAQABAAAAACw=" width="40" height="40" '
           'alt="Graphique : ventes en hausse de 12 % en mars">'),
 ("Lien", '<p>Nos tarifs : <a href="/tarifs">cliquez ici</a></p>',
          '<p><a href="/tarifs">Voir nos tarifs</a></p>'),
 ("Champ", '<input type="email" placeholder="">',
           '<label for="m">Adresse e-mail</label><input id="m" type="email">'),
 ("Titre", '<div style="font-size:28px;font-weight:700">Livraison</div>',
           '<h2>Livraison</h2>'),
 ("Contraste", '<p style="color:#e8e8e8;background:#fff">Offre valable jusqu\'au 30 juin</p>',
               '<p style="color:#111827;background:#fff">Offre valable jusqu\'au 30 juin</p>'),
]

def snap(pg, html):
    pg.set_content(f'<html lang="fr"><body><main>{html}</main></body></html>')
    return pg.locator('main').aria_snapshot()

with sync_playwright() as p:
    b = p.chromium.launch(); pg = b.new_page()
    for nom, mauvais, bon in PAIRES:
        a, c = snap(pg, mauvais), snap(pg, bon)
        same = hashlib.sha256(a.encode()).digest() == hashlib.sha256(c.encode()).digest()
        print(f"=== {nom} | identiques : {same}")
        print("  défaut  :", a.replace('\n', ' / '))
        print("  corrigé :", c.replace('\n', ' / '))
    b.close()

Limite déclarée : cette mesure lit l’arbre tel que Playwright l’expose. Elle ne dit rien de la façon dont un modèle d’IA exploite ensuite cet arbre, ni de ce qu’annonce un lecteur d’écran précis, dont le comportement varie d’un logiciel à l’autre.

Clavier et focus : tout doit marcher sans souris

Un non-voyant n’utilise pas de souris : il ne voit pas le pointeur. Il avance avec la touche Tab, active avec Entrée ou Espace, ferme avec Échap. Tout ce qui se clique doit donc s’atteindre et s’activer au clavier, dans un ordre qui suit la lecture.

Le focus, c’est l’élément qui reçoit la frappe au clavier à un instant donné. Les WCAG, les règles d’accessibilité du W3C dont la version 2.1 est reprise par le droit européen et le RGAA français, exigent qu’il soit visible ; la version 2.2 ajoute qu’il ne doit pas être entièrement caché par un bandeau fixe. Supprimer le contour de focus par outline: none pour une raison esthétique est l’erreur type : le malvoyant qui navigue au clavier perd sa position.

Dans l’enquête WebAIM, les utilisateurs de lecteurs d’écran placent en tête de leurs difficultés le CAPTCHA (le test « prouvez que vous êtes humain », souvent une image de texte déformé), puis les menus, onglets et fenêtres qui ne se comportent pas comme prévu. Ce classement n’a presque pas bougé en quatorze ans.

Le test de base prend cinq minutes : débrancher la souris, parcourir la page à la touche Tab, et vérifier trois choses. Voit-on toujours où l’on est ? Atteint-on chaque bouton, chaque champ, chaque menu ? Peut-on sortir d’une fenêtre surgissante sans la souris ?

Malvoyants : contraste, zoom et mise en page qui se replie

Le premier défaut du web, et de loin, ne concerne pas l’arbre mais les pixels. WebAIM trouve du texte à contraste insuffisant sur 83,9 % des pages d’accueil, avec 34 occurrences par page en moyenne, en hausse de 15 % sur un an.

Le contraste se mesure par un rapport entre la luminosité du texte et celle du fond, de 1:1 (texte invisible) à 21:1 (noir sur blanc). Les WCAG fixent le seuil minimal à 4,5:1 pour le texte courant, et 3:1 pour le grand texte. Un vérificateur de contraste gratuit donne le rapport en deux secondes.

Deux autres règles concernent le zoom :

• Le texte doit pouvoir être agrandi à 200 % sans perte de contenu.
• La page doit se replier en une colonne quand on zoome à 400 % une fenêtre de 1 280 pixels — soit 320 pixels CSS de large, l’unité de mesure des feuilles de style. Aucun défilement horizontal ne doit être nécessaire pour lire le texte, sauf pour les tableaux, cartes et schémas.

Comme l’a montré la mesure plus haut, ce défaut ne laisse aucune trace dans l’arbre d’accessibilité : seul un contrôle sur le rendu visuel l’attrape.

ARIA et overlays : quand la rustine remplace le HTML

ARIA, pour Accessible Rich Internet Applications, est un jeu d’attributs (role, aria-label, aria-expanded…) qui décrit un élément aux technologies d’assistance quand le HTML seul n’y suffit pas : des onglets, un menu déroulant complexe, une zone qui se met à jour seule. C’est ici que documentation et mesure divergent.

Ce que dit OpenAI. Sa FAQ pour les développeurs affirme que « Making your website more accessible helps ChatGPT Agent in Atlas understand it better » (rendre votre site plus accessible aide l’agent de ChatGPT dans Atlas à mieux le comprendre), puis recommande d’ajouter rôles, libellés et états ARIA aux boutons, menus et formulaires.

Ce que dit le W3C. La première règle de son guide d’usage d’ARIA va dans l’autre sens : si un élément HTML natif fait déjà le travail, avec la sémantique et le comportement voulus, l’utiliser plutôt que de détourner un autre élément et lui ajouter de l’ARIA. Un <button> apporte d’office son rôle, le focus clavier et l’activation par Entrée et Espace. Un <div role="button"> n’apporte que le rôle, son nom venant de son texte : le reste est à programmer, et c’est ce reste qui manque.

Ce que mesure WebAIM. Les pages d’accueil qui utilisent ARIA comptent en moyenne 59,1 erreurs détectées, contre 42 pour celles qui n’en utilisent pas. WebAIM précise que cette corrélation ne prouve pas qu’ARIA cause les erreurs : ces pages sont aussi plus complexes. Mais le volume d’ARIA a été multiplié par plus de six depuis 2019, à 133 attributs par page, sans que les erreurs baissent.

Le désaccord tient à l’ordre des opérations. L’action qui vaut dans les deux lectures : HTML natif d’abord, ARIA seulement pour ce que le HTML ne sait pas dire, et toujours vérifié au clavier. Plusieurs spécialistes de l’accessibilité, dont Steve Faulkner, ancien éditeur (jusqu’en 2023) de la spécification ARIA in HTML au W3C, ont reproché à la FAQ d’OpenAI de pousser l’ARIA avant la sémantique native.

Les overlays : une ligne de code ne rend pas un site conforme

Les overlays sont des scripts ajoutés à un site, souvent avec un bouton flottant, qui promettent de le rendre accessible automatiquement. En avril 2025, la FTC, l’autorité américaine de protection des consommateurs, a approuvé un accord avec l’éditeur accessiBe : 1 million de dollars et l’interdiction de prétendre sans preuve que son outil accessWidget rend un site conforme aux WCAG. La plainte de la FTC soutenait que l’outil ne rendait pas conformes tous les sites de ses clients, et que des avis présentés comme indépendants ne l’étaient pas. Il s’agit d’un accord transactionnel sur des allégations, pas d’un jugement. Un script ne peut pas deviner ce que dit un graphique, ni à quoi sert un bouton sans nom : les corrections qui comptent se font dans le code source.

Ce que la loi impose en France

Deux régimes coexistent, et c’est de leur confusion que naissent la plupart des contresens en ligne.

Le régime de 2005. L’article 47 de la loi du 11 février 2005 impose l’accessibilité des sites publics, des délégataires de service public et des entreprises dont le chiffre d’affaires dépasse 250 millions d’euros. La référence technique est le RGAA, le référentiel général d’amélioration de l’accessibilité, qui décline les WCAG en 106 critères. Depuis l’ordonnance du 6 septembre 2023, l’Arcom, le régulateur de l’audiovisuel et du numérique, contrôle ce régime, et le défaut d’accessibilité des sites publics est passible d’une sanction de 50 000 euros au maximum. Selon Maire-info, la Cour des comptes constatait en juin 2026 que seules 16 démarches administratives essentielles sur 244 étaient totalement conformes.

Le régime de 2025. La directive européenne sur l’accessibilité (dite EAA) s’applique en France depuis le 28 juin 2025. Elle ne vise pas tous les sites : elle vise des services précis, dont le commerce électronique, les services bancaires aux consommateurs, les transports, la téléphonie et les livres numériques, contrôlés par la DGCCRF, l’administration de la répression des fraudes, avec l’ARCOM, l’ARCEP et la Banque de France. Les microentreprises, moins de 10 salariés et moins de 2 millions d’euros de chiffre d’affaires, en sont exemptées. Depuis janvier 2026, la DGCCRF mène une enquête sur les sites et applications de commerce en ligne, et sur la loyauté des prestataires qui réalisent des audits d’accessibilité.

L’affirmation « toute entreprise de plus de 10 salariés doit être conforme au RGAA », répétée par de nombreux sites, est donc fausse : le seuil exempte les microentreprises des services visés par la directive, il n’étend pas le RGAA à toutes les entreprises. Un site vitrine sans vente en ligne, édité par une PME, ne relève d’aucun des deux régimes, sauf s’il fournit l’un des services listés.

Le pied de page du ministère de l’Économie, dont dépend la DGCCRF, affichait au relevé du 29 septembre 2026 : « Accessibilité : partiellement conforme ». La mention est obligatoire, et elle dit la difficulté mieux qu’un discours.

Ce qui est documenté, ce qui est déduit, ce qui reste inconnu

Affirmation	Statut	Source
Face à une longue page, 71,6 % des utilisateurs de lecteurs d’écran interrogés naviguent d’abord par les titres	Documenté	WebAIM, enquête n° 10, 2024
95,9 % des pages d’accueil du premier million de sites présentent un échec WCAG détectable automatiquement	Documenté	WebAIM Million, février 2026
Aucune erreur détectée ne signifie pas qu’une page est accessible	Documenté	WebAIM Million, méthodologie
Playwright MCP donne aux modèles d’IA l’arbre d’accessibilité, pas des pixels	Documenté	README de Playwright MCP, Microsoft
Atlas s’appuie sur les rôles et libellés ARIA pour comprendre une page	Documenté	FAQ éditeurs et développeurs d’OpenAI
L’agent CUA d’OpenAI, derrière Operator, lit les pixels de l’écran	Documenté	OpenAI, 23 janvier 2025
Un site accessible augmente le taux de réussite des agents IA	Déduit, non mesuré dans les sources consultées	—
Un agent qui lit les pixels est gêné par un contraste faible, comme un malvoyant	Déduit, non mesuré dans les sources consultées	—
Un contraste de 1,23:1 et un contraste de 17,74:1 donnent un arbre d’accessibilité identique	Observé	mesure de l’article, script publié
Un <div> cliquable n’apparaît pas comme bouton dans l’arbre	Observé	mesure de l’article, script publié
Les pages avec ARIA comptent plus d’erreurs (59,1 contre 42) ; corrélation, pas causalité	Documenté	WebAIM Million, février 2026
Préférer un élément HTML natif à un élément détourné avec de l’ARIA	Documenté	W3C, Using ARIA, première règle
Le bourrage de mots-clés dans l’alt peut faire percevoir un site comme du spam	Documenté	Google, bonnes pratiques pour les images
L’accessibilité est un facteur de classement Google	Non documenté dans les pages Google consultées	—
Un overlay rend un site conforme aux WCAG	Faux, selon la plainte de la FTC, close par un accord à 1 M$	FTC, avril 2025
Toute entreprise de plus de 10 salariés doit être conforme au RGAA	Faux	DGCCRF, fiches directive « Accessibilité »
Les microentreprises des services visés par la directive sont exemptées	Documenté	DGCCRF, bilan du 25 juin 2026
Montant plafond des sanctions du régime de la directive, pour les entreprises	Non documenté dans les fiches DGCCRF consultées	—

Questions fréquentes

Un site accessible est-il mieux classé dans Google ?

Aucune page Google consultée pour cet article ne présente l’accessibilité comme un signal de classement. Le bénéfice passe par les recoupements : hiérarchie de titres, texte alternatif — que Google dit utiliser pour comprendre les images — et liens explicites.

Comment tester son site avec un lecteur d’écran ?

NVDA est gratuit sous Windows, VoiceOver est intégré aux Mac et aux iPhone, TalkBack à Android. Dix minutes suffisent pour un premier constat : écouter la page, passer de titre en titre, lister les liens, remplir un formulaire. Un outil automatique comme WAVE complète le test, sans le remplacer : il ne détecte qu’une partie des problèmes.

Mon site vitrine est-il soumis à l’obligation d’accessibilité ?

Pas nécessairement. Le régime de 2005 vise le secteur public et les entreprises au-delà de 250 millions d’euros de chiffre d’affaires ; celui de 2025 vise des services listés, comme le commerce en ligne ou la banque, hors microentreprises. Le site vitrine d’une PME sans vente en ligne échappe en principe aux deux.

Par quoi commencer quand on n’a qu’une journée ?

Par les six défauts qui représentent, selon WebAIM, 96 % des erreurs détectées : contraste insuffisant, images sans alt, champs sans étiquette, liens vides, boutons vides, langue de la page non déclarée (<html lang="fr">). Ils se corrigent sans compétence spécialisée. Puis la hiérarchie des titres, puis le test au clavier.

Sources

• WebAIM, The WebAIM Million, rapport 2026, relevé de février 2026 — webaim.org
• WebAIM, Screen Reader User Survey #10 Results, février 2024 — webaim.org
• Microsoft, README de Playwright MCP — github.com
• OpenAI, Publishers and Developers – FAQ — help.openai.com
• OpenAI, Computer-Using Agent, 23 janvier 2025 — openai.com
• W3C, Using ARIA — w3c.github.io
• W3C, Understanding SC 1.4.10 Reflow, WCAG 2.2 — w3.org
• Steve Faulkner, ChatGPT sez Build with semantics first, 28 octobre 2025 — html5accessibility.com
• Google, bonnes pratiques de référencement pour les images — support.google.com
• FTC, ordonnance définitive contre accessiBe, avril 2025 — ftc.gov
• DGCCRF, Professionnels : vos produits et services doivent être conformes à la directive « Accessibilité » — economie.gouv.fr
• DGCCRF, Accessibilité : un an après l’entrée en vigueur de la directive européenne, 25 juin 2026 — economie.gouv.fr
• Gouvernement, communiqué sur l’ordonnance du 6 septembre 2023 — numerique.gouv.fr
• Maire-info, Accessibilité des services publics en ligne : la Cour des comptes tire la sonnette d’alarme, 19 juin 2026 — maire-info.com

Pour aller plus loin sur ce blog : comment un site peut déclarer ses actions aux agents IA avec WebMCP, ce que fait un agent de deep research quand il ouvre vos pages, et le guide du maillage interne, dont les liens explicites servent aussi les lecteurs d’écran.