Curieux, j’ai été voir le site des JO Paris 2024 et comme toujours, comme la plupart des sites, il n’est pas accessible. J’ai regardé le code, la structure du machin. Quel désastre. J’ai toujours l’espoir de trouver des sites bien conçus (et éco-conçus), bien réalisés, accessibles. C’est assez étrange, car c’est très (trop) rarement le cas. Mais, je garde espoir.
Je trouve plus souvent des sites conçus et réalisés pour “faire beau”, peu importe ce que l’on trouve sous la peinture, sous la décoration, des sites qui ne passent pas sur tous les navigateurs, des sites qui ont été testés et validés en comparaison avec une belle maquette graphique.
Le bien n’est pas l’ennemi du beau, le fonctionnel est le meilleur ami du beau
Mais pourquoi le beau, le graphique est-il si souvent montré comme antinomique avec la moindre notion de qualité ou d’accessibilité ?
Sans doute, parce qu’un principe fondamental des interfaces numériques a été oublié, la séparation des couches. Petit rappel, nous devrions avoir la couche technique, la couche fonctionnelle et la couche graphique. Mais trop souvent, nous avons une grosse couche graphique qui sert de cache misère à une couche technique qui fait porter le fonctionnel par le graphique. Tout se passe comme si tout était étroitement lié.
Mais pourquoi ? Pour rien, par facilité, par ignorance. Ou, peut-être parce que les tests et la recette sont faits au travers de la couche graphique. Ainsi, la confusion s’est installée durablement chez des intervenants inconscients de la réalité.
Les fondamentaux même de la séparation stricte de la couche graphique des autres couches sont de pouvoir habiller comme on veut et autant de fois que l’on souhaite les interfaces sans jamais impacter la couche technique et la couche fonctionnelle. Et pour être précis, la recette graphique devrait se faire sur la couche graphique et la recette fonctionnelle sur la couche fonctionnelle (sans la couche graphique, et oui).
C’est, par exemple, ce qui permet de respecter la règle qui stipule qu’une information / fonction n’est pas uniquement portée par sa couleur, sa forme ou sa position. C’est simple, l’information, le contenu sont présents, structurés, sémantisés puis décorés, habillés.
Mais, comme tous les intervenants (ou presque) ne voient, vérifient et valident uniquement des ensembles habillés et décorés, peu se posent la question de savoir si tout le monde voit bien l’information, le bouton ou le numéro de téléphone. Et, c’est comme cela que l’on retrouve un bouton trop souvent vide, mais parfaitement décoré (son contenu est soit une image avec une alternative vide ou absente, soit un élément uniquement défini par CSS – Cascading Style Sheets, contenu compris). Un numéro de téléphone n’est alors qu’une suite de chiffres perdus au milieu d’autres caractères.
Bref, rien de bien compréhensible ou utilisable spécialement dans le cadre de l’accessibilité numérique.
Changer, d’abord, nos (mauvaises) habitudes
Et si nous changions d’habitudes ? Oui, nous tous, les concepteurs fonctionnels, graphiques, les développeurs, les testeurs, les conseilleurs, les payeurs.
Comment ? C’est simple, travaillons et testons des composants, des fonctions, des pages non habillées. Une fois cette validation technique et fonctionnelle pure réalisée, il ne reste plus qu’à intégrer les CSS afin de profiter de toute la qualité graphique et visuelle des interfaces.
Il est évident qu’en travaillant ainsi, une grande majorité des erreurs flagrantes de qualité et d’accessibilité vont naturellement disparaître, comment peut-on accepter de regarder et de valider des interfaces avec :
- des boutons et des liens vides ;
- des tas de SVG (Scalable Vector Graphic) énormes au milieu des pages ;
- une navigation au clavier incohérente ;
- des navigations qui se chevauchent et ne permettent pas de lire les contenus ;
- des navigations doublées (une pour la version desktop et l’autre pour la version mobile) ;
- des “date pickers” posés à la fin de la page pour un formulaire en début ou même l’ordre des contenus et des fonctions mélangées?;
- des boites de sélection ou des interrupteurs qui ne sont qu’un gros tas de code inutile et pas des composants standards simples et efficients?;
- etc.
Et, cela pour ne citer que les grands classiques.
Gagnions en qualité et donc en efficience
J’entends déjà l’argument primaire “Bon, pourquoi pas, mais cela va prendre du temps, plus de temps, trop de temps”.
Alors oui cela peut prendre un peu plus de temps, mais pas du temps de production (au contraire). Le temps supplémentaire pourrait être dû au fait que l’on devrait avoir une validation fonctionnelle / technique puis une validation graphique (mais normalement, on devrait déjà avoir cela).
Donc, potentiellement, pas vraiment de perte de temps puisque nous allons avoir un résultat de qualité, génial, quasi-parfait !
Ah si, j’entends quelques développeurs râler, car ils devront reprendre leur code afin d’y ajouter quelques classes ou id pour identifier les éléments sur lesquels venir fixer les CSS.
Mais en fait pas du tout. Reprenons pour ceux qui n’auraient pas suivi.
Nous produisons des composants, des contenus, des pages structurées et sémantisées. Ainsi, les pages possèdent des “landmarks” et elles sont composées d’articles et de sections, chaque élément contient son niveau de titraille. Les éléments remarquables ou structurants possèdent un identifiant (id) et les éléments de type bloc fonctionnel, une classe spécifique si pas d’identifiant.
Si l’on descend au niveau du composant, il va posséder un identifiant qui va permettre de cibler un de ses composants. Donc, au-delà des classes génériques sur des éléments de structure (nav, liste, hn, liens, listes, boutons, etc.), il est assez facile, voire évident de repérer et de surcharger un style transverse. Trop facile !
J’en conviens, cette méthode possède un gros défaut, elle va obliger certains “agilistes” à arrêter de mettre tout et n’importe quoi dans leurs critères d’acceptance d’US (User Stories). Non, les critères (spécifiques ou non) d’accessibilité ne vont pas là, ils sont des éléments transverses de qualité (et du droit à l’accessibilité) de nos travaux.
La conformité doit donc être vérifiée et validée sur tous les livrables et à chaque étape. Cela n’a donc rien à faire ici, c’est un élément de la définition structurelle du projet. Facile !
Voilà, c’est fait, alors pourquoi attendre pour adopter cette approche, cette méthode qui privilégie par définition la qualité globale à une précipitation dictée par l’apparence.
En résumé
On arrête de rendre fonctionnel une création graphique avec des bouts d’élastiques, mais on habille graphiquement des interfaces fonctionnelles pérennes et robustes.
- Il ne peut pas y avoir de contenus, de composants ou de pages sans structure sémantique ;
- On développe et on recette sans l’habillage (sans CSS) ;
- On ajoute des CSS et on opère la recette graphique et finale.
Avec ce type d’approche, on doit arriver par défaut à plus de 90 % de respect des normes, des standards et d’une accessibilité de base (RGAA ou niveau des WCAG). Simple et efficace.
PS: arrêtez avec l’utilisation systématique tous ces frameworks Javascript ou CSS qui n’apportent rien, alourdissent et complexifient le tout.
Retrouvez la simplicité et la qualité du travail bien fait !
