La check-list du développeur web client

Les objectifs

Bien qu’en apparence très basique, le travail du développeur web client requiert de s’assurer d’une multitude de choses (non, nous ne nous occupons pas que du rendu visuel). Pour de ne rien oublier, j’utilise une check-list qui répond aux besoins habituels.

Ce document (à adapter à fonction des besoins du projet) permet une bonne vision d’ensemble sur l’avancement et les éventuels oublis lors de la phase d’intégration.

Je la fournis aussi au format « Markdown » pour plusieurs raisons :

  • ce format en texte brut est facilement compréhensible et modifiable par n’importe qui ;
  • il peut être aisément convertit au format HTML et être placé à la racine du projet ;
  • c’est un format que j’ai adopté dans mes processus avec lequel j’ai l’habitude de travailler.

En pratique, il s’agit au cours du développement d’annoter le document, et de compléter chaque ligne par un OK / NOK / N/A.

La première partie concernant des résultats attendus pour chaque page, elle servira aussi aisément d’index.

Comme précisé dans le document, je ne suis pas l’auteur de cette liste : je n’ai fait que reprendre et combiner plusieurs existants.

La checklist

Voici donc :

Si vous travaillez en PHP le code de transformation est simpliste :

<?php
    include_once('markdown.php');
    include_once('smartypants.php');
    echo(SmartyPants(Markdown(file_get_contents('checklist.markdown'))));
?>

Et vous trouverez les sources nécessaires dans le lien donné plus haut.

Checklist
=========

Conformité et affichage {#conformite}
-------------------------------------

Maquette                     | Validation XHTML                | Validation CSS                  | Safari | Fx   | IE 6 | IE 7 | IE 8 | Opera | Chrome | Lynx [^1] | Impression | iPhone | YSlow
-----------------------------|---------------------------------|---------------------------------|--------|------|------|------|------|-------|--------|-----------|------------|--------|-------
[Accueil](accueil.html)      |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |
[Contact](contact.html)      |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |
[Rechercher](recherche.html) |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |
[...](#)                     |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |


[^1]: L’affichage Lynx est proche de la restitution faite par un lecteur d'écran ou de ce qui est perçu par un moteur de recherche.

Sur l'ensemble des maquettes [^2]
---------------------------------

Contenu et style                                                                                                                             | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Vérifier la ponctuation : particulièrement les apostrophes, les guillemets, les marques de citations, les traits d’union et les tirets       |
Ne faire ni d'faute d'orthographe ni de grammaire                                                                                            |
La capitalisation doit être uniforme et traitée par CSS                                                                                      |
Proscrire les phrases passe-partout ou récurrentes ("En savoir plus...")                                                                     |
Éviter les variations dans les mots ("email" vs "e-mail" vs "courriel")                                                                      |
Traitement des listes (points, virgules, ou point-virgules à la chaque fin d’élément)                                                        |
S’assurer qu’aucun contenu de test ne subsiste ("lorem ipsum...")                                                                            |
Vérifier tous les textes cachés (les `alt`, retranscriptions, les textes dans les fonctions JS)                                              |

Visibilité moteur de recherche                                                                                                               | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Les titres (`title`) des pages sont importants, s’assurer qu’ils aient un sens et soient représentatifs des mots clefs présents dans la page |
Créer des `metadata description` pour les pages importantes                                                                                  |
S’assurer que le marquage du contenu respecte la sémantique HTML (`h1`, `p`,...)                                                             |
Vérifier le format des urls (urls simples à retenir pour les utilisateurs et les moteurs de recherche)                                       |

Conformité                                                                                                                                   | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Voir [tableau ci-dessus](#conformite)                                                                                                        |


Accessibilité                                                                                                                                | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Indiquer le langage humain principal du document en utilisant l'attribut lang au sein de la balise `<html>`                                  |
Indiquer les passages en langage secondaire dans d'autres balises encadrant le passage concerné                                              |
Proposer des liens de navigation dès le début du balisage lorsque les pages contiennent beaucoup de contenu avant le contenu principal       |
Indiquer des en-têtes dans les tableaux de données avec des balises `<th>`, et associer toutes les cellules de données à leurs en-têtes      |
S'assurer que l'ordre des tabulations est logique, en utilisant tabindex au besoin                                                           |
S'assurer que la page fonctionne toujours quand les images sont désactivées                                                                  |
S'assurer que les pages restent utilisables quand les utilisateurs agrandissent le texte au double de sa taille originale                    |
Vérifier que chaque élément de la page est accessible et manipulable au clavier                                                              |
Rédiger des textes d'appel de liens qui puissent être compris hors contexte (pas de liens titrés "cliquez ici")                              |
Pour les daltoniens ou les malvoyants, s'assurer de proposer un contraste suffisant entre le contenu et le fond de la page                   |
N'utiliser aucun contenu qui clignote plus de trois fois par seconde                                                                         |
Ne pas cacher l'indicateur de focus. Quand un utilisateur navigue au clavier, il doit toujours savoir où ces éléments se trouvent            |
Ne pas attendre des utilisateurs qu'ils perçoivent du sens grâce aux polices, aux couleurs ou à d'autres modifications de style              |
Être brefs dans les textes alternatifs, mais donner du détail dès lors qu'il y a du sens à transmettre                                       |
Fournir un script, des sous-titres, et/ou une traduction en langue des signes pour toutes les vidéos ou les sons contenant du discours       |
Fournir une version "descriptive" d'une vidéo lorsqu'il est essentiel d'en comprendre le contenu pour des utilisateurs non-voyants           |
S'assurer que toutes les vidéos, si elles ne se lancent pas automatiquement, offrent au minimum une touche de lecture accessible             |
Quand du texte peut être interprété visuellement par le navigateur aussi bien que s'il s'agissait d'une image, éviter d'utiliser des images  |
Éviter les CAPTCHAs (questionnaires de test visuels anti-robots)                                                                             |
Marquer tous les champs de formulaire avec la balise d'étiquetage `<label>`                                                                  |
Utiliser les regroupements de champs (`<fieldset>`) avec des balises de titrage (`<legend>`) pour associer des demandes de saisie            |
Recenser toutes les erreurs de saisie au format texte, et placer le message à côté du champ concerné ou à un emplacement bien repérable      |
Offrir des liens d'aide ou des instructions en ligne pour remplir les champs si nécessaire                                                   |
Ne pas laisser les utilisateurs effectuer des actions importantes sans leur proposer une confirmation ou un moyen d'annuler                  |

Tests fonctionnels                                                                                                                           | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Vérifier toutes les fonctionnalités complexes                                                                                                |
Tester avec différentes configurations de résolutions d’écran                                                                                |
Tester tous les formulaires, incluant les filtres anti-spam, les réponses aux formulaires et emails, etc.                                    |
Tester sans JS, Flash et tous les autres plugins                                                                                             |
Vérifier que tous les liens externes sont valides                                                                                            |

Performances                                                                                                                                 | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Vérifier l’optimisation des images                                                                                                           |
Vérifier et mettre en place le cache quand nécessaire                                                                                        |
Vérifier le temps de chargement et le poids des pages                                                                                        |
Minimiser/compresser les fichiers statiques une fois les développements terminés (JS/CSS)                                                    |
Optimiser votre CSS : utiliser des chemins courts vers les images, utiliser la nature du CSS c’est à dire l’héritage, etc.                   |

Touches finales                                                                                                                              | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Créer des pages d’erreur / 404                                                                                                               |
Créer un favicon                                                                                                                             |

[^2]: Fortement inspiré de
      "[The Ultimate Website Launch Checklist](http://www.boxuk.com/blog/the-ultimate-website-launch-checklist)" et de
      "[La checklist d’accessibilité que je m’étais juré de ne pas rédiger](http://www.pompage.net/pompe/checklistaccessibilite)".

*[vs]: Versus
*[IE]: Internet Explorer
*[Fx]: Firefox
*[JS]: JavaScript
*[etc]: Et cætera
*[NOK]: Non OK
*[N/A]: Non applicable
*[CSS]: Cascading Style Sheets
*[AJAX]: Asynchronous JavaScript and XML
*[ARIA]: Accessible Rich Internet Applications
*[XHTML]: eXtensible HyperText Markup Language

17 commentaires ↓

#1 Tweets that mention La check-list du développeur web client — HTML Zen Garden -- Topsy.com le 05.30.10 à 1:34

[…] This post was mentioned on Twitter by Hubert Souchaud, Hubert Souchaud. Hubert Souchaud said: RT La check-list du développeur web client http://bit.ly/aTmo5I […]

#2 Eric le 05.30.10 à 10:56

Ca mériterait de discuter avec opquast pour tenter d’homogénéiser le tout.

#3 STPo aux pépites de chocolat le 05.31.10 à 15:09

Voilà enfin dévoilée au public cette checklist ultra-secrète. Bientôt des colonnes de plus de 50px de large sur ce blog afin d’en profiter comme il se doit !

#4 Stéphane Deschamps le 05.31.10 à 18:05

STPo téfou.

Bravo pour avoir publié cette liste, bravo, bravo, bravo.

(c’était mon commentaire particulièrement inutile mais il faut que ça se sache que tu fais un boulot de dingue)

#5 Nicolas Hoizey le 05.31.10 à 19:09

Cooool !!! 😉 Faut faire tourner !

#6 awesome » Twitter Trends le 05.31.10 à 19:18

RT @notabene: la Checklist du développeur web #awesome…

#7 Frank Taillandier le 05.31.10 à 19:34

Tu tombes à pic, je suis justement en train de mettre en place une checklist pour notre agence avec les tests associés qui vont bien. Je t’envoie ça dès que j’ai finalisé le tout.

#8 Fabien Basmaison le 06.01.10 à 1:29

Bravo ! :)

Et on pourra voir les projets associés quand, alors ? (hin hin hin)

#9 Delphine M. le 06.01.10 à 10:35

La remarque d’Éric n’est pas bête : pourquoi ne pas avoir utiliser Opquast Reporting pour y créer la checklist et la lier ensuite à tes projets ? D’ailleurs, certains points se recoupent avec la liste des Bonnes Pratiques Opquast, tu pourrais tester l’ensemble dans Opquast Reporting…

#10 Elie le 06.05.10 à 16:50

Ici Elie. Pour faire suite aux remarques de Eric et Delphine, tu es le bienvenu pour mettre cette liste en place sous opquast reporting. Il y en a pour une heure, c’est pas méchant.

#11 Vincent le 06.05.10 à 17:06

Avec plaisir, l’idée est de partager ! Reste à trouver une heure maintenant. 😉

Pour l’instant, je suis bien content de gérer un bête fichier texte mais peut-être qu’en testant l’outil je vais me laisser convaincre.

#12 Elie le 06.05.10 à 17:34

Salut,

Le fichier texte, ça colle très bien quand tu veux juste faire une vérification rapide, que tu bosses seul, et que tu n’as pas besoin de générer un rapport d’audit. Et d’ailleurs, dans ce contexte, ça me semble très utile, mais ce contexte est de plus en plus rare.

Je peux facilement ajouter ta liste à Opquast reporting, à l’exception de la partie pages (accueil, contact, etc). Cette partie mérite selon moi des tests sur l’ensemble des autres règles que tu énonces (là, c’est la question à résoudre est conceptuelle, ta liste propose une partie liée à l’évaluation par page et une autre partie qui nécessite une évaluation transversale). Sur reporting, tu fais ta liste de pages si tu en as besoin et tu les évalues pour les critères que tu évalues.

Bon, sinon, attention, ce qui suit est un troll mâtiné d’autopromotion 😉

Tu as une autre solution, qui est de faire une requête suivante sur checklists.opquast.com, et là, tu obtiens une autre liste rigolote :

http://checklists.opquast.com/opquastv2?q=design+int%C3%A9gration+serveur

Et là, il n’y a pas beaucoup de règles que tu n’as pas dans ta liste. Et il y en a d’autres, plus détaillées et qui seraient parfaitement utiles dans ta liste. De notre côté, certes, on ne sait pas trop marketer ce qu’on propose comme la ultimate over funky checklist to create a wonderful Website (le titre The Ultimate Website Launch Checklist me fout la gerbe), mais notre liste représente des milliers d’heures de travail et environ 3000 commentaires d’un bon gros paquet de contributeurs. Il me semble que dans les ressources publiques (CC-BY-SA), il n’y en a pas des masses, des comme ça 😉

Lorsque d’autres listes formulent des points de contrôle similaires sans capitaliser sur le boulot fait sur Opquast (ce qui peut parfaitement se faire en dérivant nos bonnes pratiques ou les améliorant) c’est toujours pour nous un gros constat d’échec. En fait, si on arrive pas à faire utiliser cette liste à des gens aussi proches que toi, c’est sans doute qu’on est assez nuls. C’est pas nouveau.

Mais bon, on va continuer, et tu es le bienvenu 😉

#13 Vincent le 06.05.10 à 18:18

Alors pour expliquer rapidement ce qui me motive à utiliser cette liste, car oui :

  • je connais bien votre outil (j’y ai même contribué avec plaisir si tu te souviens bien) ;
  • je le trouve très pertinent et très bien foutu ;
  • je le pousse dans un contexte professionnel dès que possible.

J’ai cette petite liste dans ma besace parce-que :

  • je la trouve plus légère que la liste initiale (v1) des BP qui me semblait inatteignable dans un contexte courant en agence (à savoir quelques semaines sur un projet puis on passe à autre chose) ;
  • je l’ai forgée moi même (certes en piquant à droite à gauche les contenus), mais du coup, je connais parfaitement chaque point et je sais que je peux m’engager dessus (ou expliquer facilement l’objectif non-atteint) ;
  • je trouve le tableau en haut de page très pratique comme index de maquettes ;
  • je peux déployer ma page HTML facilement quelque soit le contexte de travail, sans passer par un tiers, et même le mettre rapidement en forme pour qu’il soit au couleurs du projet courant ;
  • et je n’avais pas réalisé qu’elle avait pris un petit coup dans l’aile à la sortie des BP v2.

En fait, mes problématiques sont en grande partie celles que tu tu évoques dans ton premier paragraphe.

Ce qui m’avait motivé également à l’époque c’était bien sûr de pouvoir rendre plus visibles tout ces parties (souvent oubliées) de mon travail.

Enfin, note bien (mais tu dois t’en douter) que je ne cherche en aucune manière à faire de l’ombre à Opquast, je pense au contraire que multiplier les canaux de diffusion ne peut qu’être bénéfique pour la qualité Web.

Ma technique bricolée maison devrait à terme, comme tu le soulignes bien, mener à des outils plus aboutis, comme celui que tu proposes.

#14 Vincent le 06.05.10 à 18:24

J’ai versé dans le troll ou la promotion moi aussi ?

#15 Elie le 06.05.10 à 19:20

Re, Pas de troll ou d’autopromo ;-), et je ne vois pas d’ombre à Opquast là-dedans. Comme certaines personnes ci-dessus, je me dis juste qu’il doit y avoir moyen de mutualiser le boulot sur la partie checklist. En ce qui concerne les outils, c’est une autre question, puisque nos outils ne sont pas ou pas encore en licence ou en accès complètement libre. Je comprends donc parfaitement qu’en termes d’outils, on utilise autre chose. Pour les règles en elles-mêmes, à nous de créer des checklists vraiment universelles, qui servent à tout le monde. Des standards, quoi 😉

Sinon, je me servirai peut-être de ton argumentaire à l’occasion, puisque en théorie, si on arrive à sortir quelque chose qui répond mieux à ton cahier des charges, on améliorera certainement la partie outil.

#16 STPo le 06.28.10 à 12:41

Au passage, une implémentation de check-list web joliment tournée : http://launchlist.net/

#17 souhka le 05.19.11 à 9:49

C’est bien de mettre une fonction de lecture en début de billet. Seul problème, elle n’est pas du tout efficace dans ce billet (lecture du fichier « checklist »). Résultat, ça fait plus gadget (utile ?).

PS: j’ai voulu t’envoyer un e-mail mais je n’ai pas trouvé le lien de contact sur ce blog


Laisser un commentaire

Mise en forme : vous pouvez utiliser la syntaxe Markdown. Vous verrez, c’est chouette !