RGAA et pagination : comment rendre la navigation paginée accessible ?

Sur beaucoup de sites, la pagination semble n’être qu’un détail de mise en page : quelques chiffres, un bouton « suivant », parfois des flèches. Pour un utilisateur qui se repère uniquement à la vue et à la souris, ce bricolage peut passer. Pour une personne qui dépend de la navigation au clavier ou d’un lecteur d’écran, ces mêmes boutons deviennent souvent un mur invisible. Respecter le RGAA sur ce type de composant ne se résume pas à coller quelques attributs ARIA : une navigation paginée accessible repose sur une structure sémantique propre, des contrôles clavier prévisibles et des indicateurs de position explicites. Autrement dit, sur une vraie réflexion de conception et pas uniquement sur la couche technique.

Les équipes qui pilotent des refontes le constatent vite : une pagination bricolée en fin de projet crée des dettes côté accessibilité, mais aussi côté SEO, performance et analytics. Le RGAA ne traite pas la pagination comme un gadget ; elle s’inscrit dans les exigences globales de navigation cohérente, d’éléments interactifs atteignables au clavier et de compatibilité avec les technologies d’assistance. Une pagination bien conçue renforce l’inclusion numérique : elle permet aux personnes aveugles, malvoyantes, avec troubles moteurs ou cognitifs de se déplacer dans une liste de résultats aussi vite que les autres. Elle améliore aussi l’usabilité pour tout le monde, parce qu’un composant clair, stable et explicite réduit la charge mentale. Ce texte propose une lecture très opérationnelle du sujet : comprendre ce que demande réellement le RGAA, éviter les pièges fréquents et disposer de modèles concrets à adapter à vos projets.

En bref

• Une pagination non accessible bloque les utilisateurs de lecteur d’écran et rend la navigation au clavier pénible, même si le site est « joli ».
• Le RGAA impose une navigation cohérente, des zones évitables, des liens explicites et des composants contrôlables au clavier.
• Une bonne navigation paginée combine balises sémantiques, texte visible, indicateurs de position et gestion fine du focus.
• Les patterns classiques « … » et icônes seules créent souvent des obstacles de compatibilité lecteurs d’écran.
• Tester la pagination au clavier et avec un lecteur d’écran reste le moyen le plus fiable de vérifier l’accessibilité réelle.

RGAA et pagination accessible : replacer le composant dans la navigation globale

Pour comprendre ce que le RGAA attend d’une navigation paginée, il faut la replacer dans le fonctionnement global du site. Une pagination intervient rarement seule : elle se combine avec un menu, un moteur de recherche interne, parfois un fil d’Ariane. Le référentiel impose d’ailleurs au moins deux systèmes de navigation par ensemble de pages. Autrement dit, une liste de résultats avec pagination doit s’intégrer dans une architecture où les utilisateurs disposent déjà d’autres repères clairs.

Sur le terrain, beaucoup d’équipes traitent encore ce composant comme un simple « widget front ». On colle un plugin de thème, on laisse les libellés par défaut (« » », « « », trois petits points) et on passe à autre chose. Lors d’un test d’accessibilité, ce type de pagination révèle rapidement ses limites : ordre de focus incohérent, absence de rôle pour les lecteurs d’écran, boutons inactifs qui semblent cliquables. Le RGAA, tout comme les WCAG, ne « nomme » pas la pagination dans un critère unique, mais elle se trouve au croisement de plusieurs exigences sur la navigation, les liens, les composants interactifs et la cohérence entre pages.

Un exemple concret aide à visualiser le problème. Sur le site fictif « Bibliothèque Claire », les résultats de recherche s’étalent sur 15 pages. La pagination originale affichait uniquement des chevrons gauche/droite, sans texte visible. En synthèse vocale, l’utilisateur obtenait une succession de « lien, lien, lien » sans autre indication. Impossible de comprendre sur quelle page il se trouvait ni où dirigeait chaque action. En retravaillant la structure sémantique (liste ordonnée, rôles explicites, texte « Page 1 », « Page suivante ») et en ajoutant un état marqué pour la page active, la navigation est devenue compréhensible, y compris pour les personnes qui n’utilisent pas la vue.

Autre dimension souvent oubliée : la cohérence d’un ensemble de pages. Le RGAA attend que les éléments de navigation apparaissent au même endroit, dans le même ordre, y compris dans le code source. Une pagination qui change de position visuelle ou de structure selon les gabarits (listing produit, listing article, moteur de recherche interne) oblige l’utilisateur à réapprendre à chaque fois. Pour des personnes avec troubles de l’attention ou de la mémoire, cette variabilité rend l’usage impraticable. La pagination doit donc s’inscrire dans des patrons de page partagés, avec un fonctionnement stable.

Enfin, ce composant n’est pas neutre pour le référencement. Une pagination accessible, qui repose sur de « vrais » liens avec des libellés clairs, aide aussi les moteurs à comprendre l’architecture des contenus. Vouloir contourner les liens au profit de boutons purement JavaScript « pour faire moderne » crée des complications à la fois pour les robots, pour les lecteurs d’écran et pour la maintenance. L’accessibilité et le SEO ne sont pas en concurrence sur ce sujet, au contraire. Les équipes qui s’appuient sur des ressources de type référentiel RGAA expliqué l’observent rapidement : un design robuste sert tout le monde.

Retenir la pagination comme un élément à part entière de la stratégie de navigation, et pas seulement comme un habillage, permet déjà d’aborder la suite avec de meilleurs réflexes.

Structure sémantique et indicateurs de position pour une pagination vraiment compréhensible

Quand une pagination reste muette pour un lecteur d’écran, ce n’est pas une question de cosmétique, mais de structure sémantique. Un enchaînement de div sans rôles ni texte ne dit rien de son sens. Le RGAA s’appuie ici sur des règles simples : identifier les zones, nommer les liens, signaler l’état courant. Beaucoup de composants « design system » publics l’appliquent déjà, à commencer par les modèles du Système de Design de l’État.

Une pagination cohérente adopte en général quatre choix structurants. D’abord, grouper les liens dans une liste, souvent une liste ordonnée, afin que les technologies d’assistance puissent annoncer le nombre total d’éléments. Ensuite, envelopper ce groupe dans un bloc de navigation, avec une balise nav et éventuellement un libellé explicite via aria-label, du type « Pagination des résultats ». Enfin, veiller à ce que chaque lien contienne un texte ou un label parlant, plutôt qu’une simple icône ou signe typographique.

Les indicateurs de position jouent un rôle central dans la compréhension. Une personne qui n’a pas la vue doit savoir sur quelle page de la série elle se trouve et quel sera l’effet de son action. Dans un audit, une astuce récurrente consiste à faire annoncer à la synthèse vocale des messages du type « Page 3 sur 12, actuelle » pour l’élément sélectionné, et « Aller à la page 4 sur 12 » pour un lien adjacent. Ce type de retour respecte à la fois le RGAA (état compréhensible, changement prévisible) et le bon sens.

Le tableau suivant illustre quelques pratiques contrastées.

Aspect	Pratique à éviter	Pratique recommandée (RGAA, usabilité)
Texte des liens	Icônes seules, « » », « … » sans texte	Texte visible « Page suivante », « Page 2 » ou aria-label explicite
Page courante	Lien cliquable identique aux autres	Élément non cliquable avec indication « page actuelle »
Groupement	Suite de span ou div sans liste	Liste ol/ul avec rôle navigation et libellé
Compatibilité lecteurs d’écran	Informations portées uniquement par la couleur ou la forme	États annoncés vocalement via texte ou attribut ARIA cohérent

Dans la pratique, la plupart des problèmes repérés dans les audits viennent d’un manque de hiérarchisation : les développeurs concentrent leurs efforts sur la logique de calcul (combien de pages, affichage des ellipses, gestion des filtres) et reportent la sémantique à plus tard. Résultat, la compatibilité lecteurs d’écran reste partielle. Une bonne habitude consiste à prototyper la pagination en HTML simple, sans JavaScript, en se basant sur des ressources comme la définition pédagogique du RGAA, puis à intégrer la mécanique dynamique ensuite.

Les liens « premier » et « dernier » posent aussi question. Faut-il toujours les afficher ? Pour certaines audiences, notamment des personnes qui parcourent de gros catalogues, ces raccourcis restent utiles. Mais leur libellé doit être limpide. Des intitulés cryptiques comme « << » et « >> » ne renseignent ni la destination, ni la position dans la série. Une formulation « Aller à la première page » / « Aller à la dernière page » lève l’ambiguïté sans ajouter de complexité pour les profils expérimentés.

Un dernier point touche à la langue utilisée. Des traductions approximatives de plugins de pagination perturbent la compréhension pour tous les publics, pas seulement pour les personnes en situation de handicap. L’accessibilité passe aussi par un vocabulaire familier, cohérent avec le reste du site et validé par les équipes éditoriales. Croiser cet aspect linguistique avec les critères du guide d’accessibilité RGAA permet de stabiliser un composant durable.

Une pagination qui parle clairement, dans le code comme à l’écran, pose des bases solides. Reste à la rendre vraiment praticable au clavier.

Contrôles clavier, focus et pièges à éviter dans une navigation paginée

Une pagination peut être parfaitement décrite dans le code, tout en restant inutilisable au clavier. C’est l’un des paradoxes fréquemment observés dans les audits : les attributs ARIA sont en place, mais l’utilisateur naviguant avec Tab se perd dans un labyrinthe de focus. Le RGAA est très explicite sur ce point : aucun composant, y compris la navigation paginée, ne doit piéger l’utilisateur ni casser l’ordre logique de tabulation.

Le premier réflexe consiste à vérifier que tous les éléments interactifs de la pagination sont atteignables avec Tab et Tab + Maj, sans saut étrange vers le haut ou le bas de la page. L’emploi intempestif de tabindex positifs (tabindex= »1″, « 2 », etc.) reste une source classique de non-conformité. Mieux vaut laisser l’ordre naturel du DOM guider la navigation, ou se limiter à tabindex= »0″ pour rendre un élément focusable lorsqu’il joue réellement un rôle de contrôle.

Pour les personnes qui utilisent un lecteur d’écran, la gestion du focus pendant le changement de page compte tout autant. Faut-il replacer le focus en haut de la page, sur le titre h1 du listing, ou le laisser sur le bouton de pagination cliqué ? Beaucoup d’outils se contentent de recharger la page sans repositionnement clair, ce qui oblige l’utilisateur à explorer à nouveau tout le contenu pour retrouver le contexte. Une pratique courante en usabilité consiste à renvoyer le focus sur le début des résultats (« Résultats, page 3 ») afin de signaler immédiatement le changement.

Certains projets vont plus loin et transforment la pagination en composant dynamique type « charger plus » via AJAX. Là encore, les exigences du RGAA ne disparaissent pas : il faut annoncer l’ajout de nouveaux éléments, veiller à ne pas piéger le focus dans un bloc et laisser à l’utilisateur la possibilité de continuer à naviguer normalement. Un bouton « Charger plus de résultats » reste, dans bien des cas, plus accessible et plus simple à maintenir qu’une pagination complexe avec sauts, ellipses et filtres croisés.

Pour visualiser les erreurs les plus fréquentes, un petit inventaire s’impose.

• Utiliser des boutons non focusables pour la page active, sans alternative pour l’atteindre ou l’annoncer.
• Mettre en place des raccourcis clavier à une touche (par exemple « n » pour « next ») sans possibilité de désactivation ni combinaison avec une autre touche.
• Ouvrir des contenus additionnels au focus (info-bulles, aperçus) sans permettre de s’en échapper facilement.
• Déclencher un changement de page dès la prise de focus, sans action explicite de la part de l’utilisateur.

Pour limiter ces dérapages, le plus efficace reste de tester la pagination comme un utilisateur concerné le ferait : uniquement au clavier, sans souris, et en se donnant une tâche simple à accomplir (atteindre la page 5, revenir à la page 2, repérer la page en cours). Ce type de test heuristique, complété par un contrôle plus formel à partir d’une ressource comme la checklist RGAA complète, évite bien des corrections tardives.

Les raccourcis clavier méritent un focus particulier. Certains frameworks activent des navigations à la lettre ou à la touche simple. Pour les personnes qui utilisent des claviers virtuels, des commandes vocales ou des dispositifs alternatifs, ces déclencheurs peuvent entrer en conflit avec leurs propres commandes. Le RGAA propose trois portes de sortie : désactiver le raccourci, l’associer à une touche de modification (Ctrl, Alt, etc.), ou ne l’activer que lorsque le focus est sur le composant concerné. Une pagination accessible n’a en général pas besoin de ces raccourcis exotiques.

Une fois la mécanique clavier fiabilisée, la question du ressenti utilisateur se pose. Une navigation fluide, sans surprise et sans « accroche » du focus, contribue autant à l’inclusion numérique qu’un long discours réglementaire. C’est souvent dans ce détail que les personnes concernées sentent si un site a réellement été pensé pour elles.

Compatibilité lecteurs d’écran et retours d’expérience sur le terrain

Les personnes qui utilisent un lecteur d’écran n’interagissent pas avec un site comme un utilisateur voyant. Pour elles, la page se présente comme un flux d’éléments parcouru ligne à ligne, ou section par section via des raccourcis. Une pagination mal étiquetée se résume alors à une série de « lien, lien, lien » sans signification. C’est ce qui ressort régulièrement des tests utilisateurs réalisés dans les missions d’audit.

Les critères du RGAA visent justement à rendre ces composants narrables. Les rôles de type landmark (role= »navigation », « main », « contentinfo ») transforment une page en zones atteignables directement. Associer la pagination à une région de navigation clairement nommée permet à l’utilisateur de dire à son lecteur d’écran : « amène-moi à la navigation des pages ». Ce n’est pas un simple raffinement, mais une condition d’usabilité pour parcourir de longues listes.

Un cas souvent observé concerne les ellipses. Beaucoup de paginations affichent quelque chose comme « 1 2 3 … 10 11 ». Visuellement, un utilisateur comprend que les pages intermédiaires existent sans être listées. Vocalement, un lecteur d’écran peut annoncer « lien, points de suspension » ou, pire, ignorer l’élément s’il n’a pas de texte. La recommandation la plus raisonnable consiste à rendre ces ellipses non focusables, tout en s’assurant qu’elles ne perturbent pas la compréhension. L’utilisateur n’a pas besoin d’y accéder, puisqu’elles ne mènent à rien.

Autre écueil : les doubles annonces. Certains frameworks appliquent à la fois un aria-label générique et la lecture du texte intérieur, ce qui donne des résultats du style « Page suivante, bouton, Page suivante, lien ». Ces redondances alourdissent l’écoute et saturent l’attention. Elles ne créent pas une non-conformité formelle, mais détériorent l’expérience. Travailler avec de vraies personnes utilisatrices, au moins ponctuellement, aide à épurer les annonces pour garder uniquement ce qui est utile.

On peut se demander quel niveau de sophistication viser. Faut-il annoncer systématiquement « Page 5 sur 12 » dans le libellé, au risque de rallonger chaque lecture, ou se contenter d’un « Aller à la page 5 » complété par un résumé global ailleurs sur la page ? Pour des sites très volumineux, certaines équipes retiennent une approche mixte : un résumé en amont (« 250 résultats sur 12 pages ») et des libellés de page plus concis. Les deux approches restent compatibles avec le RGAA, à condition que l’utilisateur puisse, à un moment donné, connaître le volume global sans effort.

Pour les équipes qui veulent aller au-delà de l’auto-évaluation, s’appuyer sur un audit RGAA complet apporte souvent un regard extérieur utile, notamment sur ces détails d’ergonomie fine. Les experts de l’accessibilité, mais aussi les testeurs handicapés, repèrent des obstacles que les équipes internes, trop habituées à leurs propres écrans, ne voient plus.

On voit alors que la compatibilité avec les lecteurs d’écran n’est pas un supplément d’âme ajouté à une pagination déjà finie. Elle influence les choix de conception eux-mêmes : nombre de liens affichés, présence ou non de textes longs, stratégie de masquage visuel de certains labels. Traiter cette dimension dès les premiers prototypes évite de devoir tout reconstruire en fin de projet.

Une pagination qui respecte la logique des lecteurs d’écran rend aussi service aux utilisateurs voyants qui aiment naviguer au clavier ou qui utilisent des outils comme les recherches de liens. Toutes ces convergences renforcent la navigation paginée comme un composant clé de l’interface, pas comme un détail mineur oublié dans un coin du footer.

RGAA, design système et gouvernance : intégrer la pagination accessible dans les projets

Traiter la pagination comme une simple tâche technique isolée conduit rarement à une mise en conformité durable. Les équipes qui réussissent à stabiliser une pagination accessible l’intègrent plutôt dans un design système, avec des règles partagées pour les menus, les fils d’Ariane, les plans de site et les blocs de résultats. Cette approche rejoint les logiques de conception défendues dans les ressources comme les guides pour site conforme RGAA.

Concrètement, cela passe par une fiche de composant dédiée. On y documente la structure HTML de base, les options possibles (présence ou non de liens « premier/dernier », ellipses, bouton « charger plus »), les comportements au clavier, les textes par défaut et les cas limites. On précise aussi quels critères du RGAA sont directement concernés, afin que les développeurs et les PO puissent vérifier rapidement la conformité sans relire tout le référentiel.

Dans l’entreprise fictive « Mobilité Douce France », qui gère un portail de location de vélos, la pagination apparaissait sur le catalogue, les pages d’événements et l’historique de commandes. Chacun de ces modules avait développé sa propre version, avec parfois des styles et comportements différents. L’équipe a décidé de tout refondre autour d’un composant unique, aligné sur le RGAA et validé avec des utilisateurs en situation de handicap. Résultat : moins de bugs, une maintenance simplifiée, et une accessibilité plus homogène.

La formation joue aussi un rôle. Les intégrateurs et développeurs qui n’ont jamais manipulé un lecteur d’écran ont du mal à anticiper les effets de certaines décisions. Des parcours de montée en compétence, comme ceux présentés dans une formation RGAA orientée pratique, aident à ancrer les bons réflexes. Une simple séance de prise en main de la navigation au clavier sur son propre site suffit souvent à déclencher des prises de conscience.

Sur le plan de la gouvernance, la pagination révèle la maturité du projet en matière d’inclusion numérique. Lorsque les arbitrages délais/budget conduisent systématiquement à sacrifier les composants communs, c’est souvent la pagination qui trinque en premier. Pourtant, ce sont précisément ces éléments transverses (menus, fils d’Ariane, paginations) qui conditionnent la capacité d’un utilisateur handicapé à accéder au contenu. Un projet qui se veut vraiment inclusif doit donc placer ces chantiers communs en haut de la pile, plutôt qu’en bas.

Enfin, la dimension réglementaire ne doit pas être sous-estimée. Une déclaration de conformité qui ignore des composants aussi visibles que la pagination perd vite en crédibilité, surtout en cas de signalement. Les ressources sur la déclaration de conformité RGAA insistent d’ailleurs sur la nécessité de décrire honnêtement les modules non conformes, pagination comprise. Mieux vaut reconnaître une dette identifiée avec un plan d’action que prétendre à une conformité fictive.

À ce stade, la pagination devient un bon révélateur de la façon dont l’organisation traite l’accessibilité : contrainte de dernière minute ou axe structurant du design. Lorsque ce composant est propre, lisible et robuste, il y a de fortes chances que le reste du site suive la même exigence.

Quels critères RGAA impactent directement une pagination ?

Plusieurs exigences du RGAA concernent la pagination, même si elle n’est pas citée comme telle. Les critères sur la cohérence de la navigation imposent que les zones de pagination soient présentes au même endroit et dans le même ordre dans le code sur un ensemble de pages. Ceux qui portent sur les liens exigent des intitulés explicites et non ambigus pour chaque action (page suivante, page précédente, numéro de page). Les critères liés à la navigation au clavier imposent que tous les contrôles soient focusables, dans un ordre logique, sans piéger l’utilisateur. Enfin, les règles sur les technologies d’assistance demandent une structure sémantique claire (listes, landmarks) et des états annoncés (page courante, pages inactives).

Une pagination avec seulement « Précédent/Suivant » peut-elle être considérée comme accessible ?

Sur de petits ensembles de résultats, un simple couple de liens « Précédent » et « Suivant » peut rester utilisable, mais il présente des limites claires. L’utilisateur ne sait pas combien de pages existent ni où il se trouve dans la série, ce qui augmente la charge mentale, surtout pour les personnes ayant des troubles cognitifs. Pour se rapprocher de l’esprit du RGAA et améliorer l’usabilité, il est préférable d’ajouter un indicateur de position, au minimum un texte du type « Page 2 sur 5 » visible ou annoncé par un lecteur d’écran. Sur des volumes importants, une pagination chiffrée reste plus adaptée.

Comment tester rapidement la pagination de son site ?

Un premier contrôle simple consiste à désactiver la souris et à naviguer uniquement au clavier : la touche Tab doit permettre d’atteindre chaque lien de pagination dans un ordre cohérent, sans blocage. Ensuite, il est utile de lancer un lecteur d’écran (NVDA ou VoiceOver par exemple) et d’écouter ce qui est annoncé pour chaque élément : les intitulés sont-ils clairs ? La page en cours est-elle identifiée ? Enfin, un passage méthodique par une grille de type checklist, comme celle proposée dans certaines ressources RGAA, permet de vérifier la structure du code et les états de focus.

Faut-il toujours suivre à la lettre les exemples de pagination des design systems publics ?

Les exemples fournis par les design systems publics, comme ceux de l’État, constituent d’excellentes bases, car ils intègrent généralement les exigences d’accessibilité. Ils ne doivent cependant pas être appliqués sans réflexion. Chaque projet a ses contraintes de contenu, de volumétrie et de publics. L’enjeu est de conserver les principes forts (structure sémantique, lisibilité, compatibilité lecteurs d’écran, commandes au clavier) tout en adaptant le niveau de détail, le nombre de liens affichés ou la présence de raccourcis. L’important est de rester fidèle à l’esprit du RGAA tout en collant au contexte réel du site.