Ainsi depuis la toute première mouture (en CSS) de cette feuille de style de diagnostic, beaucoup de choses ont changé. Voyons ça en détail 🙂

Corrections multiples

Comme vous pourrez le voir sur Github, pas moins de 97 issues ont été résolues. Cela a été possible grâce aux retours de quelques personnes, que je tiens à citer et remercier à nouveau :

Entre les bugs et les découvertes diverses, la qualité et la pertinence d’a11y.css ont considérablement progressé.

Compteurs CSS

Les compteurs sont au nombre des améliorations simples mais utiles — ces choses parfois qualifiées de quick win. Même si l’idée cheminait dans mon esprit depuis longtemps, c’est l’implémentation dans le DebugCSS de Yahoo qui a produit le déclic.

Les fonctions CSS de compteurs font partie des outils qui trouvent rarement un contexte d’utilisation pertinent. Pour une fois, c’est le cas !

Personnalisation

Après la fastidieuse relecture de mes différentes sources, ce qui n’était qu’un simple fichier CSS de diagnostic est devenu un système complexe basé sur Sass — dont le fichier de sortie final compressé pèse 80kb !

Il devenait indispensable de permettre aux utilisateurs le désirant de charger seulement les portions qui leur sont utiles. Avec l’aide de Kitty Giraudel, deux mécanismes ont été mis en place.

Générateur de bookmarklet

Il était déjà possible aux utilisateurs de Sass de ne compiler que les niveaux de critères qui les intéressaient. Désormais, ces fichiers nivelés sont mis à disposition dans le projet.

Le bookmarklet existait depuis quelques temps déjà, mais désormais un petit formulaire sur le site de présentation permet de le paramétrer en définissant le niveau minimum nécessaire.

Désactivation de tests

Pour que les utilisateurs de Sass aient toujours un intérêt à disposer du projet sur leur poste, mais aussi afin que les utilisateurs les plus avertis puissent personnaliser cet outil, Kitty a également conçu une fonction pour désactiver les tests au cas par cas. Par exemple, si vous voulez désactiver les erreurs à propos des mauvais tabindex et du href manquant, voici comment faire :


@include disable-errors("tab-order, no-href");

Et ça, c’est plutôt pratique 😀 !

Traduction

Pour celle-ci, je vais applaudir discrètement et vous renvoyer vers l’article écrit par Kitty (en anglais) qui détaille le fonctionnement de son système de traduction en Sass.

Oui, vous avez bien lu :désormais a11y.css est multilingue en demeurant écrit uniquement en Sass. Outre la portée accrue de façon incroyable suite au passage en anglais, l’exploit technique de Kitty est incroyable. J’en profite pour signaler la parution de son premier livre « CSS3 : pratique du design web » en vente aux éditions Eyrolles, que je vous recommande chaudement.[1]

Documentation & test

Vous vous en doutez, le projet est devenu relativement complexe. Les solutions apportées par les différents contributeurs on tellement enrichi ce projet que même moi, je ne m’y retrouvais plus.

J’avais déjà mentionné lors de mon atelier au WP Tech mon intérêt pour la documentation ; c’est donc tout naturellement que j’ai cherché à documenter plus précisément a11y.css. Et de mon point de vue, il y a deux aspects très différents à documenter :

  • le contenu des tests : pourquoi ces critères, comment ont-ils été défini, quel est leur intérêt.[2]
  • la structure du projet Sass, ou pour parler le technicien : l’API.

Premier chantier : trouver les outils adaptés !

Hologram

Ayant démarré ce projet seul et n’ayant pas imaginé le partager, les recherches qui m’avaient permis d’aboutir à certains tests n’étaient pas suffisamment documentées. J’ai donc étoffé les références de chaque test en indiquant, autant que faire se peut :

  • Les bonnes pratiques Opquast ;
  • Les critères et tests Accessiweb HTML5 et ARIA ;
  • Les succès WCAG 2.0 ;
  • Les sources dans des projets équivalents.

Ces ressources étant réunies, je souhaitais mettre à l’épreuve cet outil en mettant en place une page de démonstration qui servirait aussi à suivre les éventuelles régressions. Et parce qu’il ne s’agit pas seulement de pouvoir tester, mais également d’expliquer et de partager ces bonnes pratiques, un court descriptif du test était nécessaire.

Pour résumer, je cherchais donc un outil capable :

  1. D’afficher la description et les liens associés au test ;
  2. Un exemple de code HTML lisible ciblé par le test, et une version interprétée par le navigateur 
  3. La capacité d’organiser les nombreux tests présents.

C’est là qu’intervient Hologram, une gem Ruby créée par Trulia. Elle m’a semblé parfaite puisqu’elle repose sur des commentaires CSS formatés pour générer la documentation. Son objectif premier est la création et la maintenance de guides de style, ce qui n’est pas si loin du sens premier d’a11y.css : gérer et maintenir un ensemble de pratiques à vérifier.

Hologram est incroyablement simple à manipuler, puisqu’une fois la gem installée il suffit de commenter son CSS de la façon suivante :


/*doc
---
title: "[tabindex] > 0"
name: tab-order
category: Errors
---
The `[tabindex]` attribute should never be greater than 0.
* <https://github.com/Heydon/REVENGE.CSS/blob/master/revenge.css#L337>
```html_example
<button tabindex="1">Positive tabindex is bad</button>
```
*/

La syntaxe est intelligible, et reste utile sans Hologram pour générer la documentation. Un point que j’apprécie ! Pour générer la documentation, c’est très simple :


hologram

Et voilà ! Hologram génère un mini-site statique grâce à un jeu de ressources très simple. Il est ainsi possible de personnaliser l’entête, le pied-de-page et les ressources statiques pour aménager sa documentation à volonté. Magique 🙂

Et puisque j’avais déjà créé une branche pour servir de présentation en ligne sur Github, j’ai ajouté ces nouveaux fichiers HTML afin d’en faire un véritable site de démonstration.

Jetez un œil au site de démonstration d’a11y.css !

SassDoc

Pour finir, l’architecture du projet s’étant alourdie d’options et de fonctionnalités, il fallait permettre aux utilisateurs de Sass de s’approprier plus facilement l’outil.

Par chance, la majorité de ces enrichissements étaient l’œuvre de Kitty Giraudel, qui s’avère aussi être le créateur de SassDoc. La personne a tendance à faire des trucs un peu fou en Sass, et cet outil de documentation correspond à la perfection aux besoins d’une API Sass.

Ni une ni deux, Kitty a mis en place SassDoc !

Et voilà un projet complètement documenté.

Ce n’est pas fini !

Il reste quelques sujets à avancer :

  • Mettre à niveau SassDoc pour utiliser la V2 ;
  • Créer un thème SassDoc pour l’intégrer au site ;
  • Essayer d’ajouter une version française de cette documentation — ce qui semble complexe ;
  • Trouver une façon de cibler les éléments auto-fermants dans les tests génériques ;
  • Chercher de nouveaux tests à ajouter :D.

Et, bien sûr, maintenir tout ça dans le temps !

Je ne sais pas si ça se sent mais ce projet me passionne et je suis enchanté d’avoir pu partager mes réflexions, mes pratiques et mes idées avec toutes les personnes qui sont intervenues. J’ai énormément progressé grâce à ces échanges, et ma plus grande fierté est de voir a11y.css cité dans la section debug de la méthode Daisy, créé par une personne que j’admire : Romy Duhem-Verdière.

  1. Sans rire, le mec est un génie alors achetez son livre et lisez son blog. ↩︎

  2. Je ne l’ai pas encore dit mais un des objectifs du projet est clairement devenu l’apprentissage et l’accès aux savoirs. Asséner un message sans l’expliquer me parait inutile, tout comme appliquer religieusement le contenu du message n’est pas pertinent. ↩︎

Article rédigé par . Modifié le .