Lecteurs d'écran et structure du site : ce que la LAPHO de l'Ontario et les WCAG exigent pour que les clients aveugles puissent naviguer (2026)

Un visiteur voyant balaie votre page d'un coup d'œil — il voit le titre, le menu, le bouton « Ajouter au panier » et le pied de page tous en même temps, et son regard saute vers ce qui compte. Un client aveugle qui utilise un lecteur d'écran n'obtient aucune de cette carte d'ensemble. Il avance dans votre page en ligne, de haut en bas, ou il saute par structure : de titre en titre, de repère en repère, de lien en lien. Si cette structure n'est pas réellement présente — si vos titres ne sont que du gros texte en gras, si vos boutons n'ont pas de nom, si chaque lien dit « cliquez ici » — le lecteur d'écran n'a rien vers quoi sauter, et le client se retrouve à ramper dans votre page mot à mot. La plupart du temps, il s'en va. Et comme il s'agit de sens plutôt que d'une page brisée, un analyseur automatisé n'en voit qu'une partie.

Faits essentiels

• Le critère WCAG 1.3.1 Information et relations est de niveau A (Web Content Accessibility Guidelines, ou Règles pour l'accessibilité des contenus Web) : la structure transmise visuellement — titres, listes, étiquettes, tableaux — doit aussi être disponible pour les technologies d'assistance dans le code, et non simulée par le style (W3C).
• Le critère WCAG 4.1.2 Nom, rôle et valeur est de niveau A : chaque commande interactive (bouton, lien, champ de formulaire) doit exposer un nom et un rôle qu'un lecteur d'écran peut annoncer — un bouton-icône sans étiquette est muet (W3C).
• Le critère WCAG 2.4.6 En-têtes et étiquettes est de niveau AA, et 2.4.4 Fonction du lien (selon le contexte) est de niveau A : les titres et le texte des liens doivent décrire ce vers quoi ils pointent, raison pour laquelle une page remplie de liens « cliquez ici » échoue (W3C).
• Les critères WCAG 2.4.2 Titre de page et 3.1.1 Langue de la page sont tous deux de niveau A : chaque page a besoin d'un <title> descriptif, et la langue de la page doit être définie dans le code pour que le lecteur d'écran utilise la bonne voix et la bonne prononciation (W3C).
• L'art. 14 du RNAI (Règlement sur les normes d'accessibilité intégrées, Règl. de l'Ont. 191/11) de l'Ontario exige des organisations comptant 50 employés ou plus que leurs sites Web publics soient conformes à WCAG 2.0 niveau AA — chacun des critères ci-dessus se trouve à l'intérieur de ce plancher (ontario.ca, Règl. de l'Ont. 191/11).
• La prochaine échéance du RCL (Rapport de conformité en matière d'accessibilité) pour les organisations ontariennes comptant 20 employés ou plus est le 31 décembre 2026 (ontario.ca). L'analyse 2024 de WebAIM portant sur un million de pages d'accueil a relevé des manquements WCAG détectables sur 95,9 % d'entre elles, les plus courants étant structurels — étiquettes de formulaire manquantes, liens et boutons vides, et langue du document absente (WebAIM, 2024 WebAIM Million).

Que la LAPHO de l'Ontario exige-t-elle en matière d'accessibilité aux lecteurs d'écran ?

La LAPHO (Loi sur l'accessibilité pour les personnes handicapées de l'Ontario) établit la politique ; le RNAI fixe la barre technique. L'article 14 exige des organisations comptant 50 employés ou plus que leur contenu Web public soit conforme à WCAG 2.0 niveau AA. Il n'existe pas de « règle des lecteurs d'écran » distincte dans la loi — l'accès par lecteur d'écran est plutôt le résultat du respect d'un ensemble de critères WCAG portant sur la structure : Information et relations, Nom/rôle/valeur, En-têtes et étiquettes, Fonction du lien, Titre de page et Langue de la page. Respectez-les, et un lecteur d'écran peut naviguer votre site. Manquez-les, et il ne le peut pas — peu importe l'apparence de la page pour un utilisateur voyant.

C'est aussi pourquoi l'accès par lecteur d'écran constitue un test plus clair de conformité réelle que presque tout le reste. Vous pouvez avoir un site séduisant et moderne qu'un lecteur d'écran ne parvient toujours pas à parcourir, parce que le vernis visuel réside dans le CSS tandis que la structure sous-jacente est absente du HTML. Les deux sont distincts, et la loi se soucie de la structure.

Comment un lecteur d'écran avance-t-il réellement dans votre page ?

Les utilisateurs de lecteurs d'écran lisent rarement une page de haut en bas — c'est lent. Ils naviguent plutôt par structure, et trois structures font l'essentiel du travail :

• Les titres. Les utilisateurs affichent la liste de tous les titres pour survoler la page comme une table des matières et sauter à une section. Cela ne fonctionne que si vos titres sont de vrais éléments <h1>–<h6> dans un ordre logique, et non du texte simplement gros et gras. Sauter d'un <h1> directement à un <h4>, ou envelopper tout un paragraphe dans une balise de titre pour le style, brise la carte.
• Les repères. Des régions comme l'en-tête, la navigation, le contenu principal et le pied de page permettent à un utilisateur de sauter directement au contenu principal ou de revenir au menu. Sans eux, il n'y a pas de chemin « aller au contenu » et chaque visite commence par traverser la même navigation.
• Les liens et les commandes. Les utilisateurs affichent aussi la liste des seuls liens, lus hors contexte. « Lire la suite », « cliquez ici » et « en savoir plus » sont inutiles dans cette liste — dix entrées identiques qui ne pointent nulle part d'évident. Le texte du lien doit avoir un sens en lui-même (2.4.4), et chaque bouton et champ de formulaire a besoin d'un nom réel et annoncé (4.1.2). C'est la même lacune que derrière les formulaires et le paiement accessibles : un champ sans étiquette programmatique n'est qu'« édition de texte » pour un lecteur d'écran.

C'est précisément ce qu'une surcouche ne peut pas régler. Un script superposé ne peut pas inventer la hiérarchie de titres, les repères et les étiquettes que votre HTML n'a jamais eus — cette structure doit exister dans la source. C'est la même raison pour laquelle une analyse n'est pas un audit : un robot d'exploration peut signaler une image sans texte de remplacement ou un bouton sans nom, mais il ne peut pas dire si l'ordre de vos titres a réellement du sens ni si le texte d'un lien est significatif pour un humain. Ce jugement exige une personne munie d'un lecteur d'écran.

Comment vérifier si un lecteur d'écran peut utiliser votre site — et quel est le risque si vous ne le faites pas ?

Vous pouvez effectuer une première vérification utile vous-même en quelques minutes. Chaque Mac est livré avec VoiceOver (Cmd-F5) et chaque PC Windows avec Narrateur (Ctrl-Win-Entrée) ; le lecteur d'écran gratuit NVDA est largement utilisé sous Windows. Activez-en un et :

1. Affichez la liste des titres et lisez-la comme un plan. Décrit-elle la page dans l'ordre, avec un seul <h1>, sans niveau sauté et sans texte décoratif déguisé en titre ?
2. Parcourez chaque commande à la touche Tab et écoutez. Chaque bouton, lien et champ annonce-t-il un nom et sa fonction (4.1.2) ? Les commandes muettes ou « sans étiquette » sont des manquements — surtout les boutons-icônes.
3. Affichez la liste des liens. Chaque lien a-t-il du sens hors contexte, ou est-ce un mur de « cliquez ici » (2.4.4) ?
4. Réalisez une vraie tâche — trouver un produit, l'ajouter au panier, remplir le formulaire, atteindre le paiement — au clavier et au lecteur d'écran seuls. Cela recoupe l'accessibilité au clavier : si vous ne pouvez pas y accéder à la touche Tab, un utilisateur de lecteur d'écran ne peut pas l'atteindre non plus.

En Ontario, la LAPHO ne prévoit pas de droit d'action privé — les particuliers ne peuvent pas la plaider directement. La voie d'application pour un particulier est le TDPO (Tribunal des droits de la personne de l'Ontario), qui instruit les plaintes pour discrimination en vertu du Code des droits de la personne de l'Ontario. Un client aveugle qui ne peut pas naviguer votre site pour acheter ce qu'un client voyant peut acheter dispose d'un motif plausible de plainte pour accès inégal aux biens et services. Et si vous vendez aux États-Unis, les défaillances structurelles qui excluent les lecteurs d'écran comptent parmi les problèmes les plus invoqués dans les litiges au titre de la LAA (Americans with Disabilities Act) — faisant partie des 5 114 poursuites en accessibilité numérique déposées devant les tribunaux américains en 2025 (UsableNet). Comme pour toute lacune, la position durable est une remédiation documentée : les problèmes structurels repérés, les correctifs déployés et leurs dates — ce qu'un RCL honnête devrait également refléter d'ici le 31 décembre 2026. Bâtir selon WCAG 2.2, la norme actuelle, ne fait que renforcer cette position.

Vérifiez si votre site signale des problèmes de structure, d'étiquetage ou d'autres problèmes d'accessibilité — rapport Vayle gratuit, en environ 30 secondes : vayle.art. Il détecte les surcouches, signale les manquements WCAG réels et vous indique précisément ce qui s'applique légalement à votre organisation en Ontario. Sans engagement.

Vayle est un studio d'ingénierie en accessibilité à distance desservant l'Ontario. Information générale, non un avis juridique.