Résoudre les problèmes de déconnexion de la mise en page CSS et de l'ordre des sources

Nous aimerions avoir votre avis sur une solution proposée pour résoudre le problème des méthodes de mise en page qui organisent les éléments dans un ordre déconnecté de la source du document.

Rachel Andrew Technical Writer

Le groupe de travail CSS travaille sur une solution pour les cas où une méthode de mise en page peut organiser les éléments dans un ordre qui n'est pas lié à la source, et donc à l'ordre de lecture et de focus du document. Cet article explique le problème et la solution proposée. N'hésitez pas à nous faire part de vos commentaires.

Problème

L'ordre de lecture d'un document HTML suit l'ordre de la source. Cela signifie qu'un lecteur d'écran lira le document tel qu'il est présenté dans la source, et qu'une personne utilisant le clavier pour parcourir le document suivra également cet ordre source. C'est généralement logique, et un ordre de source judicieux pour le document est essentiel pour les présentations de contenu en mode lecture, les lecteurs d'écran et tout appareil avec un CSS limité. Toutefois, le CSS, et plus particulièrement flexbox et grid, peuvent créer des mises en page où la mise en page définit un ordre de lecture visuel différent de la source sous-jacente.

Par exemple, l'utilisation de la propriété order sur des éléments flexibles modifie l'ordre de mise en page, mais pas l'ordre dans la source.

Avec la mise en page en grille, il est possible que la méthode de mise en page choisie mélange l'ordre des onglets, par exemple en utilisant grid-auto-flow: dense, qui crée un ordre de mise en page aléatoire des éléments.

Un développeur peut également provoquer cette déconnexion en plaçant les éléments sur la grille dans un ordre différent de celui dicté dans la source.

Solution proposée

Le CSS Working Group propose une solution à ce problème et aimerait recueillir l'avis des développeurs et de la communauté de l'accessibilité sur cette approche.

Suivre des mises en page aléatoires avec reading-order: auto

Dans les situations qui créent un ordre de mise en page aléatoire, par exemple lorsque vous utilisez un empaquetage dense dans une disposition en grille, vous souhaitez probablement que le navigateur suive la mise en page plutôt que l'ordre source. Pour ce faire, les éléments flex ou de grille doivent avoir une propriété reading-order avec une valeur de auto.

Le code CSS suivant entraînerait un ordre de lecture qui suivrait l'emplacement des éléments qui ont été regroupés en raison de grid-auto-flow: dense.

.cards {
  display: grid;
  grid-auto-flow: dense;
}

.cards li {
  grid-column: auto / span 2;
  reading-order: auto;
}

Suivre des mises en page non aléatoires avec reading-order-items

Dans certaines mises en page en grille et flexibles, l'ordre de mise en page est facile à comprendre. Par exemple, dans une mise en page flexible qui utilise la propriété order pour réorganiser les éléments, il existe un ordre de mise en page évident dicté par la propriété order. Dans d'autres mises en page, l'ordre idéal est moins évident et il peut y avoir plusieurs choix possibles. Par conséquent, lorsque vous suivez des mises en page non aléatoires, vous devez ajouter la propriété grid-order-items au conteneur, avec des valeurs de mots clés expliquant votre intention concernant l'ordre de la mise en page.

L'exemple suivant montre une mise en page flexible utilisant row-reverse. Les éléments Flex ont reading-order: auto et le conteneur Flex a reading-order-items: flex flow pour indiquer que nous voulons également que l'ordre de lecture suive la direction flex-flow plutôt qu'un ordre visuel (que nous pourrions indiquer avec flex visual).

.cards {
  display: flex;
  flex-flow: row-reverse;
  reading-order-items: flex flow;
}

.cards li {
  reading-order: auto;
}

Dans l'exemple suivant, une mise en page en grille est créée à l'aide de grid-template-areas et les éléments sont placés dans un ordre de mise en page différent de l'ordre source. La propriété reading-order-items permet d'indiquer que nous devons suivre l'ordre de la mise en page, en parcourant chaque ligne avant de passer à la suivante. (grid column indiquerait la direction opposée).

.wrapper {
  display: grid;
  grid-template-columns: repeat(6, minmax(0, 1fr));
  grid-template-areas:
    "a a b b b b"
    "c c d d e e"
    "f f g g h h";
  reading-order-items: grid rows;
}

.a {
  grid-area: a;
  reading-order: auto;
}

Cela signifie-t-il que l'ordre des sources n'a pas d'importance ?

Non, l'ordre des sources est toujours important. Cette fonctionnalité ne doit être utilisée que dans des situations spécifiques où l'ordre de lecture peut différer de celui de la source. Par exemple, lorsque vous utilisez des méthodes de mise en page qui peuvent entraîner cette déconnexion, comme l'empilement dense en grille, ou lorsqu'un ordre de mise en page différent est judicieux à un certain point d'arrêt.

Lorsque vous utilisez ces propriétés, créez un document source en utilisant un ordre qui aurait du sens si la page était affichée sans CSS. Ajoutez ces propriétés uniquement aux emplacements et aux points d'arrêt qui en ont besoin.

Les outils de création doivent-ils appliquer ces propriétés ?

Les outils de création qui permettent aux utilisateurs de créer une mise en page en grille en faisant glisser et en déposant des éléments doivent toujours les encourager à créer un document source pertinent. Par conséquent, dans la plupart des cas, il serait plus approprié de réorganiser la source en fonction de l'ordre de mise en page, plutôt que d'utiliser ces propriétés comme moyen simple de gérer la déconnexion.

Veuillez nous faire part de vos commentaires sur cette proposition.

Nous sommes très intéressés par vos commentaires à ce sujet. En particulier, si vous avez un cas d'utilisation qui, selon vous, ne sera pas résolu par cette approche, ou si vous avez un problème d'accessibilité avec cette approche, veuillez en informer le groupe de travail CSS.

Un fil de discussion est en cours. Il contient de nombreux cas d'utilisation et des réflexions sur l'approche. Vous pouvez y ajouter des commentaires et signaler les problèmes potentiels liés à cette proposition. Notez que la proposition actuelle est très différente de ma proposition initiale qui a lancé le fil de discussion. Les personnes intéressées apprécieront peut-être toute la conversation qui nous a menés là où nous en sommes aujourd'hui, car elle illustre bien la façon dont les propositions sont traitées dans le groupe de travail CSS pour devenir quelque chose qui peut être implémenté dans les navigateurs.

Vignette par Patrick Tomasso. Merci à Chris Harrelson, Tab Atkins et Ian Kilpatrick pour leurs commentaires et leur examen.