a11y.css .[1]

Les références

Les projets reposant sur CSS

Le premier projet de ce type que j’ai rencontré est Holmes.css. L’idée m’a rapidement séduit. Des projets similaires ont fleuri, dont : 

La découverte d’OpQuast et des bonnes pratiques ayant accentué mon exigence, les outils précédemment cités m’ont semblé un peu légers.

Les checklists

Définir des « checklists qualités » est également une bonne idée, et les exemples lus dans « Intégration web, les bonnes pratiques » de Corinne Schillinger ou dans le projet Outline de Vincent Valentin m’ont persuadé de tenter cette solution. Cependant, c’est plus contraignant que les solutions de repérage en CSS, et légèrement différent puisqu’une solution CSS ne permettra pas d’évaluer la pertinence des textes ou solutions techniques. Les checklists sont également rapidement contextuelles à un projet, puisque les objectifs et contraintes peuvent varier — je cherchais plutôt un outil générique.

Les solutions en ligne

Les solutions automatisées en ligne sont également très utiles, mais ne permettent pas de faire un suivi au fil de l’eau. Je m’en sers lorsque je touche au but, à savoir en préambule à une recette complète. Voici une liste de ceux que j’affectionne particulièrement : 

Mais à moins que vous ne soyez fan des allers-retours, ces services ne sont pas adaptés à une utilisation intensive.

Une organisation lisible

J’ai donc travaillé sur ce fichier CSS pendant un moment, égrainant les règles à tester, les façons d’afficher le message, etc. Mon récent apprentissage de Sass m’a permis d’organiser beaucoup plus précisément ce fichier, en définissant quatre degrés de gravité : 

  • Les erreurs, dénoncées en rouge : principalement des attributs absents, vides ou très fortement déconseillés ;
  • Les alertes, signalées en jaune : notamment les éléments vides, les imbrications douteuses et les attributs sensibles ;
  • Les éléments & attributs obsolètes, marqués en gris et relevés d’après la liste maintenue par le W3C ;
  • Les conseils, mentionnés en vert. Il s’agit de simples suggestions d’utilisation de certains attributs, ou de bonnes pratiques méconnues.

L’organisation du projet est simple : la feuille de style « reine » contient un mixin, quelques explications et des placeholders pour chaque degré de gravité. Des fichiers partiels sont importés en deux groupes : un pour les sélecteurs — pour la maintenabilité, c’est bien plus lisible ainsi — et un pour les messages eux-mêmes.

Une cible précise

Comme vous vous en doutez, cet outil n’est destiné qu’aux intégrateurs soucieux de la qualité de leur production. C’est pourquoi la compatibilité des sélecteurs et de l’affichage des messages ne prend pas en compte IE8 :D.

De plus, les messages sont affichés via un pseudo-élément ::after — et vous le savez sûrement, mais les contenus générés via des pseudos-éléments ne sont pas du contenu.

Et pour que ça ne me gratte pas trop la rétine, j’ai également ajouté un effet de transition pour l’apparition du message.

La documentation

Reste une question à se poser : comment ai-je choisi les tests à effectuer, les formulations des messages et leur degré de gravité respectif ?

Pour faire simple, j’ai lu. Beaucoup. Les premières ressources ont été les projets similaires déjà cités, bien sûr. Puis je me suis inspiré des indications récurrentes obtenues sur Tanaguru ou OpQuast Reporting. La page du W3C listant les éléments obsolètes s’est imposée d’elle-même en tant que ressource complète pour un degré bien précis de vérification.

Et finalement, le forum de discussion du référentiel AccessiWeb pour sa version 2.2 ( sous-titré « Mesure de la conformité WCAG 2.0 via le référentiel AccessiWeb 2.2 avec HTML5/ARIA » ) que m’avait précédemment indiqué Johan Ramon m’a appris énormément.

Car oui : j’ai tout lu, tout détaillé. Pour chaque critère j’ai essayé d’en saisir le sens, les implications techniques et fonctionnelles, mais aussi ma capacité à les vérifier en CSS. C’est pourquoi les fichiers .scss sont plutôt bien documentés : chaque test indique, via un commentaire, le critère Accessiweb et/ou la bonne pratique OpQuast concerné(es).

Les tests susceptibles d’évoluer ou dont la vérification en CSS m’a semblé discutable ont été soit retirés, soit inclus aux conseils avec la mention utile concernant le contexte de rédaction du test en question.

Une capitalisation indispensable

Voilà, vous savez tout. J’estime ce projet suffisamment mûr pour être soumis aux regards de tous, en espérant que ceux-là me permettront d’enrichir encore cet outil qui m’aide déjà beaucoup.

J’ai peu détaillé l’origine concrète de ce projet et comment il est né d’un réel besoin. Il faut savoir que dans mon travail, je ne maîtrise pas toujours l’environnement de la phase d’intégration. Lorsqu’un nouveau projet est lancé, il peut parfois m’être imposé un thème ( sur WordPress ) ou une solution ( Prestashop, si tu nous regardes ) ; et lorsqu’il s’agit d’une maintenance ou d’une refonte partielle, je ne vous raconte pas ce que je déterre parfois…

C’est dans ce cadre qu’a11y.css prend tout son sens. Car si vous maîtrisez parfaitement la chaîne de production, il ne pourra vous servir que de pense-bête ( car vous aurez déjà appliqué toutes les bonnes pratiques, n’est-ce pas ? ), surtout si vous automatisez ce type de tâches grâce à Grunt ou d’autres outils du même acabit.

Alors, qu’en dites-vous ?

  1. a11y est la contraction de « Accessibility » : un « a » suivi de 11 caractères, et conclu par un « y ». ↩︎

Article rédigé par . Modifié le .