Colonnes désordonnées

Afficher la colonne 1 après la colonne 2, mais d’où vient cette curieuse idée ?

Exemple de mise en page avec des colonnes dont l'ordre est modifié dans l'HTML

Avant que les CSS ne fonctionnent correctement sur tous les navigateurs, c’est-à-dire au début des années 2000, la plupart des intégrateurs utilisaient encore les tableaux de mise en forme pour structurer l’information des pages web. Puis en 2003 et 2004 les navigateurs Safari et Firefox ont débarqué avec un support des CSS bien plus rigoureux que ce que proposaient Microsoft et Netscape.

Cette arrivée du CSS dans les pages web a fait le plus grand bien aux intégrateurs qui pouvaient enfin coder plus sémantique et donc d’une manière plus lisible pour les aides techniques. Cette évolution profitait aussi aux développeurs côté serveur. Une grande évolution a toujours ses revers et certains intégrateurs ont pris le parti de faire table rase des tableaux quitte à changer l’ordre du contenu pour qu’il puisse être structuré via des divisions plutôt que des tableaux de mise en forme…

Chaque époque a ses modes de mise en forme, ainsi dans ces années-là,  le nec-plus-ultra était le layout de 3 colonnes avec,  pourquoi pas, une colonne centrale fluide. Pourquoi  3 colonnes ? Peut-être pour faire plus portail, plus pro, plus riche, en tous cas on aimait bien en mettre partout !

Côté intégration, ce layout était ultra simple à réaliser avec un tableau de mise forme mais beaucoup plus complexe sans table, avec un CSS vraiment cross-browser et surtout flexible. Un vrai challenge technique d’où cet engouement de certains développeurs front-end qui ont relevé ce défi par plusieurs chemins. C’est là qu’on a vu émerger ces montages avec une colonne centrale positionnée dans le code HTML avant les 2 « indispensables » colonnes latérales. Les gourous du référencement cautionnant cette déviance, arguant que la méthode mettait le contenu central plus haut dans la page, la mode pour ces complications d’intégration à fait long feu ! Je ne citerai pas de sources, mais si vous y tenez il reste encore plein de tutoriels sur ce « magique » layout 3 colonnes : il vous suffit de demander « montage 3 colonnes fluide » à votre moteur de recherche préféré et vous serez comblé mais vous n’allez pas combler tous les internautes…

Pourquoi c’est mal ?

Vous vous dites que l’internaute s’en fiche du code source,  alors pourquoi cela le dérangerait-il que le contenu de la colonne 1 soit affiché après celui de la colonne 2 ?
Primo c’est une question de respect du sens de lecture :

  • Si vous travaillez sur une langue qui se lit de gauche à droite, c’est valable aussi pour l’ordre des colonnes dans votre code HTML. S’il s’agit de colonnes en float : left, vous êtes bien parti pour suivre un flux normal. Si vous avez par exemple une ligne avec au moins 2 colonnes en float : right, il faut à priori revoir le CSS.
  • Si vous travaillez sur une langue qui se lit de droite à gauche comme l’arabe ou l’hébreu il faudra faire l’opposé : vous positionnerez votre rangée de colonnes en float : right

Je donne ici l’exemple des flottants mais d’autres techniques permettent (hélas) de gérer ces permutations via les marges et les placements en absolu de ces colonnes.

Quels utilisateurs sont concernés ?

Cette permutation du contenu dans le flux peut impacter ceux qui utilisent les aides techniques et ceux qui naviguent au clavier de lien en lien et de champ en champ et qui essaient de suivre leur progression à l’écran.
Un cas pratique simple : imaginez que votre sidebar est placée dans un bloc après votre bloc de contenu dans le code mais visuellement à gauche du contenu dans le navigateur. Pour y saisir sa requête il va déjà se demander pourquoi il n’a pas pu y accéder avant d’avoir eu le focus sur des éléments du bloc de contenu et surtout il va devoir tabuler tout le contenu pour enfin l’atteindre.

Il y a un autre impact pour les internautes, c’est le cas d’un montage en responsive design où votre permutation est appliquée en desktop et lorsque la page est linéarisée pour le mobile, elle reprend l’ordre du code source. On en reparlera plus loin !

Quel critère Accessiweb risque-t-on d’invalider ?

Ici on cherche à valider le critère 10.3 (niveau bronze) :  « Dans chaque page Web, l’information reste-t-elle compréhensible lorsque les feuilles de styles sont désactivées ? » 

Quels sont les cas où ce désordre de contenu invalide ce critère ?

Essentiellement le cas où il y a une continuité de l’information entre les différentes colonnes permutées. Par exemple si la colonne gauche comporte un titre et une introduction et si sa colonne de droite comporte le corps de l’article alors que cette dernière est placée avant celle de gauche dans le DOM.
Les autres cas de figure comme le contenu secondaire ou le moteur de recherche en colonne latérale comme j’ai donné l’exemple plus haut,  valident à priori ce critère : le sens de lecture n’est pas affecté puisque différents ordres de lecture sont possibles sans dénaturer la compréhension de la page.

Finalement les WCAG 2.0 sont plutôt conciliant avec cette technique tordue de l’inversion de contenu : on invalide le critère si l’information de la page linéarisée est restituée dans un ordre qui la rend incompréhensible.
A mon sens, elle demeure souvent peu fréquentable car elle perturbe parfois l’expérience utilisateur de celui qui navigue exclusivement au clavier. Elle risque aussi de donner des nœuds au cerveau des développeurs qui vont reprendre le code vu l’incohérence visuel vs code.
Ce qui me gêne aussi dans cette technique c’est sa faible résistance au changement. Par exemple, dans le cas d’une refonte partielle, il est possible que le montage inversé soit conservé sur des colonnes dont le contenu se suit et du coup le critère sera invalidé après cette refonte.

Est-ce que ce désordre peut devenir un bien ?

L’exemple de la sidebar au contenu superflu pour le desktop que l’on veut faire apparaître après le contenu en mobile/tablette est le plus fréquent. C’est en effet mieux d’avoir le contenu plus haut dans la page en affichage mobile/tablette. Du coup pourquoi refourguer ce contenu superflu avant l’essentiel pour les internautes desktop ?
Systématiser cet usage des permutations risque de discriminer les usagers des ordinateurs de bureau par rapports aux usagers des mobiles et tablettes.

Si vous faites du responsive design vous avez peut-être entendu parler du « source ordering » ? Les frameworks CSS avec grille responsive comme Zurb Foundation l’ont intégré à leur librairie CSS.
Dans le cas d’une adaptation d’un site existant en responsive, cette fonctionnalité peut dépanner, mais si on part de zéro est-ce bien nécessaire d’y avoir recours ?

Si on prenait le problème à la source ?
Voyons les différents cas de figure :

  • Le contenu de cette colonne de gauche est secondaire mais elle permet de combler un vide. Pourquoi ne pas la mettre à droite directement sur le site desktop ?
  • Cette colonne de gauche sert de navigation supplémentaire mais elle est très encombrante sur la version mobile/tablette. Pourquoi ne pas la rendre escamotable dans ce cas ?
  • Cette colonne de gauche est essentielle à la compréhension de la colonne suivante mais le code source place son contenu après la colonne suivante. Donc il faudra le même ordre visuel sur les autres devices, alors pourquoi ne pas revoir le code HTML et CSS pour remettre tout cela dans l’ordre ?

Vous aussi vous avez des nœuds au cerveau ? Alors le meilleur moyen d’éviter cette dérive c’est de repenser intégralement la volumétrie et la structure de l’information de votre site en partant du mobile pour éviter les pages d’accueil hautes de plus de 10 écrans mobile une fois linéarisées !

A mon sens, la permutation ne devrait être utilisée qu’en correctif quand il n’est plus possible de repenser la structure de l’information.

Les solutions CSS pour structurer vos colonnes dans l’ordre du DOM :

Voici quelques exemples pour structure du contenu en colonnes. Ici on respecte l’ordre du DOM. J’ai ajouté une règle media query pour que vous puissiez vérifier la linéarisation correcte sur mobile.
J’ai rejeté les règles CSS spécifiques aux vieux navigateurs Explorer (IE6 et IE7) en bas du CSS pour ne pas polluer votre lecture mais il vaudra mieux les externaliser dans une feuille de style à part appelée en commentaire conditionnel et supprimer les préfixes de propriétés _ et * pour avoir un CSS standard.

Un layout 2 colonnes fluides :

Template 2 colonnes avec une barre latérale à gauche

Démo HTML/CSS du template 2 colonnes

C’est le plus simple : une colonne flottante à gauche, un contexte de formatage pour la colonne de droite. Sur mobile tout se linéarise sur une seule colonne et dans l’ordre.
Quel que soit la colonne la plus longue, elles ne chevaucheront jamais le pied de page, c’est pour cela qu’on ne définit pas de hauteur et qu’on ajoute un clearfix pour le cas où la colonne de gauche dépasse en hauteur celle de droite.

Si on souhaite la sidebar à droite, voici l’exemple de ce cas de figure :

Template 2 colonnes avec barre latérale à droite

Démo HTML/CSS du template 2 colonnes avec sidebar à droite

Avantages :

  • Ce layout offre vraiment la souplesse maximale surtout dans sa version avec la sidebar à gauche  où les 2 colonnes n’ont besoin d’aucun paramétrage de largeur (sauf sur IE7 et IE6).
  • Le contexte de formatage créé sur la colonne de droite permet une grande souplesse d’utilisation.

Désavantage :

  • Avec la sidebar à droite, il faudra spécifier des largeurs de colonnes en % ou en unité fixe via les pixels comme c’est le cas dans la démo ci-dessus.

Un layout 3 colonnes avec des flottants :

Template 3 colonnes avec des flottants

Démo HTML/CSS du template 3 colonnes avec flottants

Dès qu’on dépasse 2 colonnes, c’est la solution la plus simple à mettre en place. C’est cette technique qu’on utilise depuis longtemps pour les listes de blocs en mosaïque.

Avantages :

  • Très flexible et bien compatible sur les anciens browsers comme IE6 et IE7.
  • Il permet de gérer plusieurs rangées de colonnes sans balise HTML pour les envelopper.

Désavantage :

  • Ce layout ne crée pas de véritables colonnes : si vous avez besoin de délimiter une grille ou des fonds de colonnes il faudra gérer un fond sous la division englobante pour créer cette décoration.

Un layout de type tableau avec 3 vraies colonnes :

Capture d'écran du template 3 colonnes en mode table

Démo HTML/CSS du template 3 colonnes de type table

Tiens un revenant ! Mais c’est un tableau de mise en forme ce layout !!!?
Oui mais avec divisions (des balises div), donc pas de balises table, tr, th, tr et td car ici tout est dans les CSS.
On utilise rarement cette technique pour des colonnes entières de contenu mais plutôt pour des petits modules de barre d’outils avec des éléments positionnés dans le flux, car à l’intérieur des colonnes la mise en page avec des éléments hors flux risque de vous donner du fil retordre. On utilise beaucoup ce montage en mobile où il permet de distribuer des éléments avec des espacements réguliers sur des largeurs à 100%.

Si le design vous oblige à avoir des fonds de colonnes qui vont jusqu’au footer et que votre contenu à l’intérieur des colonnes est bien dans le flux normal (pas d’éléments en position absolue accrochés ici et là), c’est une option à envisager.

Avantages :

  • Ce layout crée des vraies colonnes.
  • Flexibilité des dimensions.
  • Les avantages des tableaux sans l’inconvénient d’une sémantique HTML détournée et lourde.

Désavantages :

  • Rétrocompatibilité IE6 et IE7 : si vous devez encore gérer ces vieux navigateurs, il faudra gérer un fallback qui nous ramène au montage avec les flottants.
  • Quelques complications pour gérer des éléments absolus, notamment si on souhaite accrocher des blocs en bas d’une colonne en display : table-cell.

Les bonnes pratiques en responsive design ont du bon !

Avec ces trois exemples de structures HTML/CSS, on se rend compte que certaines bonnes pratiques du responsive design convergent avec celles de l’accessibilité. Le besoin de linéariser dans le bon ordre nous pousse à utiliser des techniques CSS cohérentes et robustes et c’est tant mieux !

Téléchargez l’archive .zip des 4 templates (32Ko)

Le critère 10.3 Accessiweb

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *