Ce billet est un compte-rendu de la conférence de Élie Sloïm et Laurent Denis à Paris-Web 2011. Les slides sont déjà disponibles en ligne.
Dans cette présentation, on va suivre un projet web sur ses différentes étapes. On fait une refonte donc les différentes étapes sont :
- audit de l'existant
- une question: quel niveau d'accessibilité ?
- l'intégration
- estimer la charge
- constats
1 - audit de l'existant
En fait, faire un audit n'est pas une bonne idée. Les conférenciers nous mettent en garde contre des audits lourds (avec plusieurs centaines de pages). EN effet, un audit, c'est un constat d'échec. C'est vu par le client comme un véritable mur à escalader pour corriger tous les défauts.
Ce n'est donc pas une bonne méthode.
Néanmoins, comme nous le verrons plus tard, un audit total doit servi en fin de projet comme constat de succès, de validation de l'accessibilité.
2 - question: quel niveau d'accessibilité ?
Les conférenciers nous enseignent que les niveaux d'accessiblité ne doivent pas être les objectifs d'un projet.
Pour rappel, 3 niveaux d'accessibilité sont généralement définis: A, AA, AAA (qu'on appelle de vive voix: simple A, double A, triple A). On trouve aussi les dénominations Bronze, Argent, Or, qui ne recouvrent pas exactement les mêmes règles, mais c'est le même principe.
En pratique, le niveau triple A est un idéal, et un rêve. Au contraire, le niveau simple A ne garantit pas une bonne accessibilité. Le seul niveau utilisable en pratique est donc le niveau double A.
Cependant, il ne faut pas viser un niveau particulier. Il faut le choisir adapté au contexte, et surtout, il faut tâcher de tendre vers ce niveau, il ne doit pas être un objectif en soi. Il faut s'en servir comme point de repère pour s'en approcher par amélioration continue.
3 - l'intégration
L'idée à retenir pour l'intégration, c'est qu'il faut travailler en amont. Il faut tâcher de prévenir les risques au lieu de les gérer une fois qu'il sont avérés.
Comment ? En montant en compétrnces les équipes, à petit pas, doucement. On peut avoir un peu de formalisme (mais pas trop), par exemple envoyer un mail qui expliquerait les points importants concernant l'accessibilité (mais pas tout tout de suite !): utiliser des titres, des listes, des alt sur les images, etc.
4 - estimer la charge
Il éviter les tâches de type "gros bloc". En utiisant des micro-tâches, on arrive à mieux répartir la charge. Évidemment, on peut (il faut !) aussi mutualiser des choses si on a un parc de sites.
Rappelons-nous tout de même qu'un site web, c'est avant tout du contenu (ou des fonctions pour une application). C'est pas de l'accessibilité. C'est donc une erreur que de repousser la sortie d'un site ou d'une appli web à cause de l'accessibilité.
Il faut découpler les plannings de la vie du site. La sortie d'un site n'est qu'un jalon parmi d'autres.
5 - constat de succès
La mise en production n'est pas la fin, il ne faut pas s'arrêter là. Il faut faire de l'amélioration continue.
récapitulatif
- prévention des risques
- juste formalisme
- interventions en amont
- formation au fil de l'eau
- adaptation au contexte
- décisions factuelles: contenus et services doivent passer avant l'accessibilté
- les contenus d'abord !
- L'amélioration continue fonctionne aussi pour les personnes :-)
Enfin, n'oublions pas que dans un projet, c'est la personne qui est dans le projet qui est la mieux placée pour prendre les décisions, c'est lui le vrai expert sur son projet.
