# Un tableau transformé en cartes sur mobile casse l’ordre de lecture (RGAA 5.3, WCAG 1.3.2) > Un tableau de données réorganisé en cartes empilées sur petit écran restitue un ordre de lecture différent de celui attendu par un lecteur d'écran. Symptôme, cause, correctif. - Auteur : Clément Hadrot - Publié le : 2025-02-20 - Mis à jour le : 2025-02-20 - Catégorie : Accessibilité - URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/tableau-cartes-mobile-casse-ordre-lecture/ ## L’essentiel - display grid ne réordonne jamais la structure DOM sous-jacente - Un lecteur d'écran suit le DOM, pas l'ordre visuel CSS - Vérifier l'ordre de restitution avec le mode navigation par tableau du lecteur d'écran Symptôme : sur un tableau tarifaire de six colonnes (formule, prix mensuel, engagement, options incluses, support, disponibilité), affiché sous forme de cartes empilées en dessous de 600 pixels de large, la navigation par tableau de NVDA restitue les cellules dans un ordre qui ne correspond plus à l'ordre visuel des cartes affichées. Le prix apparaît avant le nom de la formule dans l'annonce vocale, alors que visuellement la carte affiche d'abord le nom, puis le prix. Un utilisateur voyant qui partage son écran avec un utilisateur non-voyant, ou qui vérifie simplement l'annonce produite, remarque immédiatement le décalage. ## Diagnostic : ce que fait réellement la technique CSS employée La transformation visuelle repose sur `display: grid` associé à la propriété `order` sur certaines cellules, une technique fréquente pour réorganiser l'affichage d'un tableau sans dupliquer son balisage HTML pour chaque taille d'écran : ``` @media (max-width: 600px) { table, thead, tbody, tr { display: block; } td { display: grid; grid-template-columns: 40% 60%; } td.prix { order: -1; } } ``` La propriété `order` modifie l'ordre de rendu visuel des éléments dans un contexte de grille ou de flexbox, sans jamais modifier l'ordre des nœuds dans le DOM. C'est précisément cette dissociation qui casse la restitution : les technologies d'assistance construisent leur arbre d'accessibilité et leur ordre de restitution à partir du DOM source, pas à partir du rendu visuel final produit par le moteur CSS. ## Pourquoi ce n'est pas un problème de responsive design en général > L'essentiel à retenir : display grid ne réordonne jamais la structure DOM sous-jacente ; Un lecteur d'écran suit le DOM, pas l'ordre visuel CSS ; Vérifier l'ordre de restitution avec le mode navigation par tableau du lecteur d'écran Le critère WCAG 1.3.2 « Ordre significatif » (Meaningful Sequence), niveau A, exige que la séquence de lecture programmatique d'un contenu corresponde à une séquence significative, y compris lorsque la présentation visuelle change. Un tableau de données linéarisé pour un lecteur d'écran doit rester compréhensible dans l'ordre où ses cellules sont énoncées, exactement comme l'exige, pour les tableaux de mise en forme, le critère RGAA 5.3 sur la cohérence du contenu linéarisé ; pour un tableau de données comme celui-ci, la même exigence de cohérence de l'ordre se retrouve au titre du critère RGAA 9.2 sur la cohérence de la structure du document, puisque la technique employée modifie l'ordre perçu sans toucher à l'ordre réel du contenu. Il ne s'agit donc pas d'un défaut propre au responsive design en général : de nombreuses techniques de recomposition visuelle (flexbox avec `order`, grid avec zones nommées réordonnées) sont parfaitement compatibles avec l'accessibilité, tant que l'ordre visuel final reste identique à l'ordre du DOM. Le problème apparaît spécifiquement quand la réorganisation visuelle diverge de l'ordre source, ce qui est exactement ce que fait `order: -1` sur la cellule de prix dans cet exemple. ## Vérifier la correspondance ordre visuel / ordre DOM 1. Activer le mode de navigation par tableau du lecteur d'écran (NVDA : Ctrl+Alt+flèches à l'intérieur d'un tableau) et noter l'ordre des cellules annoncées 2. Comparer cet ordre à l'ordre visuel affiché à l'écran dans la même largeur de viewport 3. En cas de divergence, rechercher dans le CSS toute propriété `order`, tout `grid-template-areas` réordonné, ou tout positionnement absolu qui modifierait l'apparence sans toucher au DOM ## Le correctif : réordonner le DOM, pas seulement le rendu La correction la plus fiable consiste à faire correspondre l'ordre visuel souhaité à l'ordre réel des cellules dans le balisage, en modifiant l'ordre des colonnes à la source plutôt qu'en le compensant par CSS : ``` 19 € / mois Essentiel Sans engagement ``` Lorsque l'ordre visuel doit réellement différer entre desktop et mobile pour des raisons de hiérarchie visuelle, la solution la plus robuste consiste à générer deux structures distinctes côté serveur (une table classique pour les grands écrans, une liste de cartes à l'ordre DOM déjà correct pour les petits écrans), plutôt que de faire porter la réorganisation entièrement au CSS. > Notre règle de recette pour tout tableau responsive : l'ordre annoncé par le lecteur d'écran doit être relu à voix haute par quelqu'un qui ne regarde pas l'écran, en dessous et au-dessus du point de rupture responsive. ## En résumé La propriété CSS `order`, comme toute technique de réorganisation purement visuelle, ne modifie jamais l'ordre programmatique d'un contenu. Un tableau de données transformé en cartes empilées sur mobile doit conserver, dans son DOM, l'ordre exact que l'on souhaite voir restitué par un lecteur d'écran. Vérifier cette correspondance fait partie des contrôles trop souvent oubliés d'une recette responsive, alors qu'il se détecte en quelques minutes avec le mode de navigation par tableau d'un lecteur d'écran.