Masonry CSS (Grid Lanes) : l'ordre de tabulation RGAA en péril

Les grilles façon « mur de briques », popularisées par des bibliothèques comme Masonry.js ou Isotope, arrivent nativement en CSS. Plus besoin de JavaScript pour empiler des cartes de blog, des vignettes de portfolio ou des résultats de recherche en comblant intelligemment les espaces vides : l'algorithme fait le travail tout seul, en plaçant chaque élément dans la colonne la plus courte du moment.

Le problème, c'est que cet algorithme d'équilibrage ne touche jamais à l'ordre du DOM. Il réordonne l'affichage, pas le code source. Et le clavier, lui, continue scrupuleusement de suivre le DOM. Résultat : un décalage entre ce qu'un utilisateur voit et l'endroit où son focus atterrit réellement, un terrain typiquement glissant pour les critères RGAA 12.8 et 10.3, et pour WCAG 2.4.3. Cet article détaille pourquoi ce décalage casse concrètement la conformité, les trois stratégies d'atténuation disponibles avec leurs limites respectives, et comment le tester à la main, car un scan automatisé seul ne suffira pas ici.

Grid Lanes (ex-Masonry) : un algorithme qui réordonne sans toucher au DOM

Le nom « Masonry » a été abandonné en cours de standardisation au profit de « Grid Lanes », une extension de CSS Grid Level 3. Le principe reste le même : au lieu de figer des lignes de hauteur uniforme comme le fait display: grid classique, l'algorithme laisse chaque colonne (chaque « lane ») avancer à son propre rythme et y insère l'élément suivant du flux dès qu'elle devient la plus courte.

En pratique, ce type de grille équipe surtout des collections d'éléments visuellement indépendants les uns des autres : cartes d'articles sur une page de blog, vignettes de produits sur une page catégorie e-commerce, galeries de portfolio, tuiles de tableau de bord. C'est justement parce que ces cartes n'ont pas d'ordre de lecture narratif strict (contrairement à une suite d'étapes numérotées ou à un formulaire) que la tentation de laisser l'algorithme réordonner l'affichage librement est forte. Le risque au clavier existe malgré tout, y compris pour du contenu sans hiérarchie de lecture apparente : un utilisateur qui tabule doit encore pouvoir prédire, ne serait-ce qu'approximativement, où portera son prochain arrêt.

Voici, à titre illustratif (la syntaxe est encore expérimentale mi-2026, cf. plus bas), à quoi ressemble une déclaration Grid Lanes d'après la documentation de Manuel Matuzović :

.grille {
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr);
}

Dans son article « Your Grid Lanes will likely fail WCAG 2.4.3 », Matuzović construit une démonstration simple : six éléments numérotés de 1 à 6 dans le DOM, disposés sur trois colonnes. Le rendu visuel place les trois premiers dans la première ligne (1, 2, 3), puis, pour équilibrer les colonnes, positionne l'élément 6 avant les éléments 4 et 5 sur la deuxième ligne. Visuellement, l'ordre de lecture devient donc 1, 2, 3, 6, 4, 5.

Suivez maintenant ce que fait un utilisateur clavier. Il tabule dans l'ordre du DOM : 1, puis 2, puis 3. Jusque-là, le focus visuel avance de gauche à droite, cohérent avec la lecture. Mais le tabulateur suivant amène le focus sur l'élément 4, qui occupe la deuxième position de la ligne 2, pas la première : le rectangle de focus saute par-dessus la position qu'occupe visuellement l'élément 6. Puis il avance vers l'élément 5 (troisième position). Et le dernier tab, sur l'élément 6, ramène brutalement le focus tout à gauche de la ligne 2, à la position que l'utilisateur avait déjà visuellement dépassée trois tabulations plus tôt. Ce mouvement de va-et-vient est précisément ce qu'un utilisateur clavier ne peut pas anticiper en regardant seulement la page.

Pourquoi ça casse concrètement les critères RGAA 12.8 et 10.3

Le RGAA 4.1.2 encadre exactement ce cas de figure avec deux critères, tous deux classés « Manuel » dans le référentiel (aucune détection automatique fiable) :

Le critère 12.8 pose la question dans les termes suivants : « Dans chaque page web, l'ordre de tabulation est-il cohérent ? ». Le glossaire officiel du RGAA précise ce que recouvre « cohérent » : un contenu compréhensible est à la fois lisible (l'ordre des éléments est logique) et cohérent (l'enchaînement de la lecture l'est aussi). Une grille Masonry qui fait sauter le focus en avant puis en arrière, comme dans l'exemple ci-dessus, échoue sur ce deuxième point : rien dans l'enchaînement visuel ne permet de prédire le prochain arrêt du focus.

Le critère 10.3 pose une question voisine mais complémentaire : « L'information reste-t-elle compréhensible lorsque les feuilles de styles sont désactivées ? ». Il est directement mappé sur WCAG 1.3.2 (Meaningful Sequence) en plus de 2.4.3. Une grille Masonry sans CSS retombe généralement dans l'ordre naturel du DOM, ce qui est en soi une bonne nouvelle : le test 10.3 vérifie justement que cet ordre du DOM, seul, reste porteur de sens. Mais cela ne dispense pas de vérifier le 12.8 : un ordre de DOM cohérent hors CSS n'empêche pas que la mise en page Grid Lanes le fasse paraître incohérent une fois stylée, exactement le scénario décrit plus haut.

Deux profils d'utilisateurs sont directement pénalisés par ce décalage. D'abord, les utilisateurs clavier voyants (mobilité réduite, notamment), qui suivent l'indicateur de focus à l'écran pour savoir où ils se trouvent : un saut en avant puis en arrière casse leur repère visuel et les oblige à rechercher le rectangle de focus à chaque tabulation. Ensuite, les utilisateurs malvoyants qui combinent une loupe d'agrandissement (zoom 200 % et plus) avec la navigation clavier : ils ne voient qu'une fenêtre réduite de la page à la fois, et un focus qui « disparaît » d'un côté de l'écran pour réapparaître ailleurs, sans lien visuel apparent avec la portion visible, est particulièrement désorientant.

Le référentiel prévoit d'ailleurs explicitement le cas du contenu qui évolue après le chargement initial. Le test 12.8.2 pose la question suivante : « Pour chaque script qui met à jour ou insère un contenu, l'ordre de tabulation reste-t-il cohérent ? ». C'est précisément le scénario d'une grille Masonry alimentée par défilement infini ou par un chargement différé : chaque nouvel élément inséré peut redéclencher l'algorithme d'équilibrage des colonnes et redistribuer des cartes déjà affichées, avec le même risque de saut de focus imprévisible que dans l'exemple statique ci-dessus, mais à chaque insertion.

Les trois stratégies d'atténuation, et leurs limites

Trois approches circulent pour limiter les dégâts. Aucune ne règle le problème à 100 %, ce qui est justement la raison pour laquelle ce point reste d'appréciation humaine.

1. Réduire le réordonnancement avec flow-tolerance

La propriété flow-tolerance permet de limiter l'écart de hauteur toléré entre colonnes avant que l'algorithme ne déplace un élément pour rééquilibrer la grille.

.grille {
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr);
  flow-tolerance: 4; /* valeur illustrative, à ajuster au cas par cas */
}

Augmenter cette tolérance réduit mécaniquement le nombre d'éléments déplacés loin de leur position naturelle dans le flux, donc le nombre de sauts de focus imprévisibles. Mais l'équilibrage visuel des colonnes en pâtit : plus la tolérance est haute, plus des espaces vides ou des colonnes de hauteurs très inégales peuvent réapparaître, ce qui est précisément ce que Grid Lanes est censé éviter. Manuel Matuzović résume la limite sans détour : « Flow Tolerance is not a silver bullet » (ce n'est pas une solution miracle), et l'ordre du DOM n'est pas le seul facteur en jeu : un fort écart de hauteur entre les éléments de la grille peut, à lui seul, dégrader l'accessibilité au clavier même à tolérance ajustée.

Concrètement, si vous optez pour cette voie, partez d'une tolérance basse et augmentez-la progressivement jusqu'à ce que le test clavier décrit plus loin dans cet article redevienne acceptable, plutôt que d'accepter une valeur par défaut sans vérification. Gardez à l'esprit qu'aucune valeur ne garantit un ordre parfaitement cohérent : elle réduit la fréquence des sauts de focus, elle ne les élimine pas.

2. Aligner l'ordre de lecture avec reading-flow

Une deuxième propriété, reading-flow, agit à un niveau différent : plutôt que de limiter le réordonnancement visuel, elle force l'ordre de tabulation (et l'ordre de lecture pour les technologies d'assistance) à suivre l'ordre visuel réel, ligne par ligne.

.grille {
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr);
  reading-flow: grid-rows;
}

Sur le papier, c'est la solution la plus directe au problème posé par le 12.8 : le focus suit ce que l'œil voit, plus de saut en arrière. En pratique, le support est aujourd'hui restreint aux navigateurs à moteur Chromium, et selon Matuzović, reading-flow ne fonctionne pas encore de façon combinée avec grid-lanes dans les implémentations disponibles mi-2026. Les positions de WebKit et de Mozilla sur cette propriété ne sont, à ce stade, pas connues.

3. Amélioration progressive : n'activer Grid Lanes que si Reading Flow suit

La troisième stratégie, documentée par Matuzović dans un second article (« Progressively enhancing Grid Lanes »), consiste à ne basculer vers Grid Lanes que lorsque le navigateur supporte à la fois grid-lanes et reading-flow. Le code ci-dessous, illustratif et daté de fin juin 2026, combine une feature query @supports avec un repli explicite sur une grille classique :

.grid-lanes {
  display: grid;
  grid-template-columns: repeat(3, 1fr);

  @supports (display: grid-lanes) and (reading-flow: grid-rows) {
    display: grid-lanes;
    reading-flow: grid-rows;
  }
}

La grille de base (display: grid) garantit un ordre de tabulation qui suit le DOM en toute circonstance, ce qui reste conforme au 12.8 dès lors que le DOM lui-même est structuré logiquement. La bascule vers Grid Lanes ne s'active que si les deux API sont disponibles ensemble, ce qui, selon l'auteur, exclut aujourd'hui les navigateurs qui supportent Grid Lanes sans reading-flow, comme Safari. Une limite demeure : reading-flow est aujourd'hui cantonnée aux conteneurs Grid et Flex, ce qui restreint la portée générale de cette technique de repli.

Une tentation existe, face à ce genre de décalage, de forcer l'ordre de tabulation avec des valeurs positives de tabindex. Ne cédez pas à cette solution : elle introduit un second ordre parallèle à maintenir manuellement, qui se désynchronise dès la moindre évolution du contenu. Notre guide sur les bonnes pratiques de tabindex détaille pourquoi les valeurs positives sont à proscrire, masonry ou pas.

Comment tester ce point avant de livrer

Puisque les trois stratégies ci-dessus ont chacune leurs limites, la vérification humaine reste incontournable. Deux protocoles concrets, à mener à chaque changement de nombre de colonnes (la plupart des grilles Masonry passent d'une colonne en mobile à deux ou trois en desktop, précisément le point de bascule où l'algorithme entre en jeu) :

Test clavier seul. Tabulez dans la grille du premier au dernier élément, à chaque largeur de fenêtre où le nombre de colonnes change. À chaque tabulation, demandez-vous si vous pouviez prédire la position suivante du focus rien qu'en regardant la page. Un indicateur de focus bien visible est indispensable ici : sans lui, impossible de repérer les sauts en premier lieu. Notre testeur de focus aide à visualiser l'ordre de tabulation réel d'une page.

Test au zoom. Grossissez la page à 200 % ou plus, de façon à ne voir qu'une fraction de la grille à la fois, puis reprenez le test clavier. C'est dans cette configuration que le décalage se fait le plus sentir : un saut de focus qui sortait du champ de vision à l'échelle 100 % devient un focus qui disparaît purement et simplement de l'écran visible, obligeant l'utilisateur à chercher où il est passé.

Une checklist minimale pour documenter ce contrôle manuel, à refaire à chaque évolution notable du composant :

• Tabuler du premier au dernier élément à chaque largeur de fenêtre où le nombre de colonnes change
• Vérifier qu'un indicateur de focus visible accompagne chaque arrêt, y compris en marge de la grille
• Zoomer à 200 % minimum et refaire le test clavier en ne voyant qu'une fraction de la grille
• Réitérer le test après tout ajout dynamique de contenu (défilement infini, chargement différé)
• Consigner le résultat comme un contrôle manuel du critère 12.8, pas comme un résultat de scan automatisé

Ce n'est pas un détail cosmétique. Sur un ensemble de pages qui utilise la même grille, un seul contrôle manuel bien mené suffit à couvrir tous les gabarits qui la réutilisent, à condition de le refaire à chaque changement notable du nombre de colonnes ou du contenu affiché. Pour une remise à niveau plus large sur la navigation clavier, notre guide pratique de la navigation clavier reprend les fondamentaux qui s'appliquent aussi bien à une grille Masonry qu'à n'importe quel autre composant interactif.

Conclusion

Le CSS Masonry natif, sous le nom de Grid Lanes, résout un vrai problème de mise en page sans une ligne de JavaScript, mais il déplace visuellement des éléments sans jamais toucher à l'ordre du DOM que suit le clavier. Ce décalage engage directement les critères RGAA 12.8 et 10.3, et WCAG 2.4.3. Ni flow-tolerance, ni reading-flow, ni l'amélioration progressive ne suppriment le besoin d'un contrôle humain : chacune réduit le risque, aucune ne le ferme. Retenez surtout ceci : tant que l'API n'est pas stabilisée, la prudence consiste à tester au clavier avant de généraliser Grid Lanes à l'ensemble d'un gabarit, plutôt que de découvrir le problème une fois le composant déployé partout.

Si votre site utilise déjà des grilles Masonry ou envisage de migrer vers Grid Lanes, un scan RGAA Checker permet de vérifier automatiquement l'essentiel du reste de vos pages pendant que vous validez ce point précis à la main, au clavier et au zoom.