Faire un site avec Kirby CMS

Après vous avoir parlé de la genèse du projet Design Accessible, voici plus de détails sur la partie technique.

Le choix du moteur

J’ai envisagé plusieurs options pour concevoir Design Accessible :

• Le no-code. Par exemple avec Airtable. J’ai écarté cette solution très vite, par peur de ne pas pouvoir proposer une expérience accessible.
• WordPress. Plus de 40 % du web tourne sur WordPress, alors pourquoi pas un site de plus ? C’est puissant et on peut toujours trouver un plugin pour faire ce qui n’est pas natif. Mais justement, c’est trop puissant à mon goût. J’avais envie de quelque chose de léger et maîtrisable, notamment pour m’assurer de l’accessibilité du projet. (Attention, je ne dis pas que WordPress ne permet pas de faire des sites accessibles ; seulement que je ne suis pas assez familière avec son écosystème pour le faire).
• un CMS léger, comme Kirby CMS : j’en avais entendu parlé grâce à l’étude de cas de Julien. Je l’avais déjà testé vite fait pour mon site perso. Je savais qu’il pourrait donc convenir. Et je suis encore plus tombée en amour ! Je vous raconte dans la suite.

Kirby, mon amour

Kirby est un gestionnaire de contenu, léger, hautement personnalisable et sans base de données.

Le contenu d’abord

👉 Kirby CMS est idéal pour travailler avec une approche « content first ». Que dire ? Comment le structurer ?

Kirby, c’est avant tout des dossiers et des fichiers textes. Simple et efficace. Tout le contenu du site se trouve dans le répertoire content. Chaque sous-dossier contient au moins un fichier texte.

Par exemple, le contenu de la page Découvrir consiste en :

• un fichier default.txt
• plusieurs images illustratives utilisées dans la page.

Les fichiers txt sont écrit en Markdown. La page À propos contient par exemple un titre et un champ texte rédigé en markdown :

Title: À propos
----
Text: 
## À propos de ce site

(highlight: **Design Accessible** rassemble des ressources sur l'accessibilité pour les designers.)

Ce qui est intéressant, c’est qu’on peut ajouter autant de sections que l’on veut. Sur la page d’accueil, j’ai ainsi rajouté plusieurs champs de contenus : titre, baseline, menu…

Title: Design Accessible
----
Menu:
- decouvrir
- checklist
- ressources
----
Heading: Designer un web **accessible et inclusif**
----
Baseline: Ressources pour concevoir des services utiles et utilisables pour toutes et tous.

On peut aussi modéliser des données plus complexes. Pour Design Accessible, les ressources ressemblent à une succession de liens associés à des métadonnées personnalisées :

- 
  url: https://adamsilver.io/blog/form-design-from-zero-to-hero-all-in-one-blog-post/
  title: 'Form design: from zero to hero all in one blog post'
  source: Adam Silver
  description: 'Liste de ressources et recherches utilisateurs pour concevoir des formulaires accessibles : conception, libellés, rédaction des questions, wording, validation...'
  lang: en
  phase: Conception
  type: Article
  thematique: Formulaires
  date: 2021-06-01

Et pour ne rien gâcher, ces fichiers structurés rendent l’import de l’existant plutôt facile. Dans mon cas, j’avais déjà sélectionné une centaine de ressources dans un tableur Airtable. En écrivant un script Python, j’ai pu générer un fichier texte au bon format à partir de l’API Airtable.

Des templates personnalisés

👉 Kirby est idéal pour une approche d’amélioration progressive. Après avoir modélisé le contenu, on peut se concentrer sur la sémantique HTML des pages.

Bon, c’est chouette le contenu, mais c’est encore mieux s’il est visible aux utilisateurs.

Avec Kirby, ça se passe via un système de template en PHP où l’on accède aux données de la page via leur nom : $page->title(), $page->baseline()…

# site/templates/default.php

<?php snippet('header') ?>
<h1><?= $page->title() ?></h1>
<div id="content">
	<?= $page->text() ?>
</div>

<?php snippet('footer') ?>

On peut aussi manipuler les données plus finement :

• $page->ressources()->toStructure() permet d’afficher toutes les ressources ;
• $page->ressources()->toStructure()->sortBy('date')->limit(4) permet d’afficher uniquement afficher les 4 dernières.

Pendant la 2ème phase de développement, j’ai donc uniquement travaillé sur le markup HTML.

C’est une étape clé pour concevoir un site accessible :

• Le HTML porte le sens : qu’est-ce qui est un titre ? Une liste ? Une citation ? Une navigation ?
• Le CSS ne sera qu’une amélioration progressive qui vient dans second temps.

Du style pour mon site

👉 Kirby ne propose pas de thèmes officiels. Il faut donc forcément mettre un peu la main à la pâte.

Plusieurs semaines de travail ont passé. Et vient enfin l’heure de transformer ce HTML sobre en quelque chose de plus… stylisé !

Pour cette phase là, Kirby n’est pas d’une grande aide : on a carte blanche avec un répertoire assets/ désespérément vide 😅.

Pour mon portfolio, j’avais utilisé un template html5up. Mais pour le projet Design Accessible, j’avais envie de contrôler de A à Z le code, pour proposer une expérience simple et low-tech (le moins de JS possible par exemple).

Mes connaissances en CSS étant un peu vieillotte (je faisais pourtant du dev front) (il y a 10 ans 👵), j’avais un peu peur de me lancer sans framework. J’ai donc utilisé KNACKCSS un framework CSS très léger qui :

• harmonise l’apparence des éléments HTML sur l’ensemble des navigateurs,
• propose des styles dédiés aux outils d’assistances techniques (lecteurs vocaux par exemple),
• définit des gammes d’unités fluides (em, rem, vw).

Pour le reste, Jimmy m’a fortement aidé en mettant une base toute propre que je me suis empressée de saccager compléter au fur et à mesure des développements de nouvelles pages.

Globalement, l’intégration était plutôt simple (dit celle qui s’est copieusement fait aider 😅). Le composant qui m’a donné le plus de fil à retordre est sur la page Checklist. Je voulais :

• des checkboxs personnalisées (Le saviez-vous ? Ce n’est pas natif 😭) ;
• qui fassent « accordéon » sur le contenu d’aide, si possible sans usage de JS ;
• actionnable au clavier.

Je m’y suis reprise à 23 reprises environ, avec l’insertion d’un peu de JS même à un moment, avant de trouver de la solution (merci Jimmy, Luce et Éric pour cette section qui m’aura fait suer ! 😅)

Une administration aux petits oignons

👉 Kirby permet de construire un panneau d’administration sur mesure. Et c’est trop bien !

Jusque là, je modifiais le contenu directement dans les fichiers du répertoire content/. Mais quand il commence à être bien défini, un panel d’administration est bien plus confortable.

Kirby permet de le personnaliser sur mesure, sans grosses compétences techniques, en éditant des fichiers yml.

J’avais préalablement défini la structure d’une ressource. J’ai ensuite réfléchi à comment me permettre de les éditer facilement :

• titre : champ texte
• lien : champ URL
• description : champ texte long
• thématiques : tags
• type de ressource : liste déroulante
• …

J’ai ainsi pu construire le fichier blueprint des ressources :

# site/blueprints/pages/ressources.yml
fields:
	title:
		label: Titre
		type: text
	url:
		label: Lien
		type: url
	description:
		label: Description
		type: textarea
	lang:
		label: Langue
		type: select
		width: 1/4
		options:
			en: Anglais
			fr: Français
	...

J’ai donc pensé chaque page d’administration pour me permettre d’éditer facilement le site. Et, coquetterie finale : puisque j’administre plusieurs sites Kirby, j’ai customisé le CSS du panel d’administration aux couleurs de Design Accessible pour m’y retrouver plus facilement :

# config/config.php

'panel' => [
    'css' => 'assets/css/panel.css'
]

Léger et facile à mettre en place

👉 Kirby est écrit en PHP. Il peut se déployer facilement chez la plupart des hébergeurs.

Avec Kirby, pas de base de données, pas de techno compliqué type React, VueJS, NPM, Glup, Slurp, Bloup et autres machins auxquels je ne comprends rien 😅. Ça tourne en local (php -S localhost:8000) ou sur la plupart des serveurs sans installations de trucs et de machin.

Comme tout n’est que fichier, le backup et le déploiement sont facilités. J’utilise tout simplement git 😇.

Pour cela j’ai dû configurer mon serveur :

# Configure remote 
git remote add prod ssh://annso@monserveur.fr:/www/

# Configure server
ssh annso@monserveur.fr:/www/
cd /www/
git init
git config receive.denyCurrentBranch ignore

Et y installer un hook :

#!/bin/sh
cd ..
GIT_DIR='.git'
umask 002 && git reset --hard

Je peux alors déployer en ligne de commande : git push prod

⚠️ Actuellement, je modifie donc le site en local, avant de pousser les modifications sur le serveur. À terme, j’aimerais creuser du côté des plugins Kirby pour pouvoir commiter automatiquement les modifications que je fais via le panel.

Quelques morceaux choisis

Avant d’en finir avec cet article déjà trop long, voici quelques petites choses supplémentaires que j’ai mis en place avec Kirby :

De nouveaux attributs pour un site plus accessible

Kirby propose des Kirbytags qui permettent de générer du code facilement. J’ai dû en surcharger certaines pour garantir l’accessibilité du site.

Par exemple, nativement, les attributs hreflang et lang d’un lien ne sont pas gérés. Ils permettent de prévenir les lecteurs d’écrans en quelle langue le texte est affiché.

Puisque Design Accessible propose beaucoup de titres de liens en anglais, il était important de le marquer dans le code. J’ai donc surchargé le KirbyTag link pour gérer cela :

(link: https://www.plainlanguage.gov/guidelines/design text: Design for reading hreflang: en)

Des Kirbytags personnalisés pour séparer contenu du balisage

Kirby permet aussi de définir des Kirbytag personnalisés. Cela est particulièrement utile pour séparer contenu et balisage HTML.

Ainsi, ma galerie de personas est écrite ainsi :

(card: Solène est aveugle de naissance. desc: Elle est habituée des technologies et maîtrise les lecteurs d'écrans de son ordinateur et de son smartphone.)
(card: Philippe est atteint d’arthrose. desc: Il utilise beaucoup les commandes vocales pour naviguer ; et parfois le clavier, qui lui est moins douloureux que la souris.)
(card: Brigitte est mal voyante. desc: Grâce à la loupe d'écran, elle peut naviguer sur Internet, à condition que l'interface ne soit pas trop complexe.)

J’ai aussi créé un Kirbytag emoji. Il faut dire que j’use (et j’abuse) des émojis. Ils apportent une touche colorée, je les aime beaucoup. Mais ils polluent beaucoup les lecteurs d’écrans. Une solution : les encapsuler dans un span qui ne les lira pas.

# (emoji: ✨) La checklist du designer

génère le code suivant :

<h2><span aria-hidden="true">✨</span> La checklist du designer</h2>

Je pourrais d’ailleurs aller plus loin en permettant d’ajouter du texte alternatif quand c’est nécessaire. Par exemple « Merci aux contributeurs ❤️ » pourrait être lu par un lecteur d’écran comme « Merci aux contributeurs, et cœur sur eux ».

Et bien d’autres

Le code source de Design Accessible est public. Vous pouvez donc voir comment j’ai :

• ajouté un flux RSS
• créé un menu pour les réseaux sociaux (côté contenu, côté vue et côté admin)
• géré les attributs aria-current dans la navigation
• …

Les limites de Kirby

Kirby n’est pas parfait pour toutes les circonstances, hélas.

• Je l’ai mentionné un peu plus tôt : l’écosystème des thèmes est très pauvre. Ça veut dire carte blanche pour faire comme on veut. Mais ça rend la création d’un site difficile d’accès pour qui n’a pas de compétence en CSS.
• Dès qu’on veut faire des trucs un peu complexe, il faut écrire du PHP. La documentation de Kirby propose de nombreux cookbooks qui aident. Grâce à ça, j’ai pu mettre en place un mécanisme de filtres, mais il reste encore limité. À terme, j’aimerais pouvoir filtrer plusieurs tags en même temps par exemple (pour afficher toutes les ressources pour du « mobile » en « français »). Pour cela, j’aurais besoin d’écrire du code côté controller. Pour le moment, je manque de temps pour le faire.

Le mémo de la fin

Quand on commence avec Kirby, ça va vite de se perdre au début. On a envie de toucher à tout en même temps :

• avoir un panel aux petits oignons ;
• y rentrer ses données ;
• les afficher sur le site.

Voici donc mon petit pense bête personnel pour mettre en place un site avec Kirby :

1. Choisir une version :
   • Pour mon premier projet (mon site personnel), j’avais utilisé le Starterkit. Il y a déjà du contenu en place, ça m’a permis de comprendre les bases. Pour Design Accessible, je me sentais plus à l’aise : je suis partie du Plainkit. Il est vierge de tout contenu.
2. Configurer le nom du site dans content/site.txt
3. Écrire du contenu dans content/ : un dossier par page ; et un fichier texte par dossier (default.txt pour une page standard, <nom-du-template>.txt pour utiliser un template dédié)
4. Afficher ce contenu dans site/template
   • Éditer le fichier default.php
   • Créer les templates spécifiques nécessaires.
5. Configurer le panel
   • Installer le panel en visitant localhost:8000/panel
   • Configurer les fichiers site/blueprints/pages/

Enjoy !