Allons plus loin

Le premier article de cette série montre que l’audit complet en fin de production n’est pas toujours la solution la plus pertinente ni la plus économique pour rendre un site internet accessible. Il définit quelques principes directeurs qui peuvent conduire à pratiquer l’accessibilité de manière un peu moins formelle et quelquefois plus efficace.

Il est maintenant nécessaire de descendre dans l’arène et de vérifier que ces principes directeurs peuvent se décliner de façon opérationnelle, dans la vraie vie, et dans des contextes industriels.

Alors, en pratique, comment faire en sorte que l’expert accessibilité n’intervienne pas « dans un bocal » sans lien avec le monde extérieur ? Comment faire en sorte qu’il soit l’une des composantes d’un processus linéaire, qui part de l’identification du besoin et qui va jusqu’à la production d’un site accessible ? Comment faire en sorte que la correction des points problématiques ne se fasse pas en bout de chaîne, mais tout au long du processus ?

Pour mieux répondre à ces questions, et appréhender les tenants et aboutissants de cette approche, nous allons partir de la notion théorique d’évaluation, notamment dans le domaine des sciences de l’éducation. Nous montrerons ensuite à partir de notre vécu dans une grande entreprise, comment les modes de développement agile peuvent servir pour optimiser et rentabiliser la démarche accessibilité.

Évaluation et théories de l’enseignement

Vous et moi, quand nous étions à l’école, faisions une différence nette entre deux types d’évaluations : « l’interro surprise » et « l’interrogation planifiée ».

Ces deux types d’interrogations répondent en réalité à un schéma d’évaluation en deux étapes, respectivement :

1. L’évaluation formative * , censée dépister le plus tôt possible les points mal acquis par un petit questionnaire, quelques petits exercices. Rapidement faite, si possible rapidement corrigée, elle permet à l’enseignant de ne pas laisser s’installer un décalage trop grand entre ce qu’il pense faire passer et ce qui est acquis par ses élèves et, le cas échéant, de corriger le tir, si possible à moindre frais.
2. L’évaluation sommative **, faite en fin d’un cycle d’apprentissage. Elle permet (comme son nom l’indique) de contrôler la somme de l’apprentissage d’un cycle donné (une phase d’apprentissage d’une notion complexe en Grammaire ou en Mathématiques, une période de temps en Histoire, etc.). Cette évaluation est sanctionnée par une note, et c’est cette note que porteront les bulletins trimestriels montrant l’évolution de l’élève.

Vous voyez où nous voulons en venir ? La plupart du temps, l’accessibilité se concentre sur la partie sommative, c’est-à-dire l’examen a posteriori qu’un ensemble de points ont été pris en compte.

Nous allons le voir, c’est là que nous devons nous inspirer de la démarche agile pour intégrer un genre d’évaluation formative, faire le travail au fur et à mesure, en s’insérant au cœur même du processus de développement.

Coder à quatre mains

Le développement agile recèle un certain nombre de méthodes qui espèrent rendre plus fluide, plus efficace, plus réactif (bref plus agile, d’où son nom) le développement informatique.

En particulier, intéressons-nous aux méthodes de codage à quatre mains.
Classiquement, un développeur produisait du code dans son coin, avant dans le meilleur des cas de le soumettre à un validateur qui à son tour produisait une revue de code, listant les points à améliorer. Le code retourne chez le développeur, qui doit intégrer les remarques du validateur avant mise en place pilote.

En développement agile, la revue de code se fait au fil de l’eau, le validateur et le développeur échangeant en permanence leurs rôles. Ils codent à quatre mains, et s’approprient le code de l’autre, veillant ainsi à ne pas laisser s’installer de défauts (puisque demain le code de l’autre développeur devient le vôtre).

Cette approche ne garantit pas une validation exhaustive des questions liées à l’accessibilité, mais elle s’assure au moment même de la création de l’interface web qu’aucun point bloquant ne restera au moment de la mise en production.

Un levier pour optimiser les ressources

Pour revenir à l’exposition de notre méthode : nous avons purement et simplement transposé au développement web la notion d’évaluation formative. Nous évaluons la compréhension de tel problème d’accessibilité précis par le développeur, et nous facilitons l’intégration des recommandations d’accessibilité dans sa production.

Nous pouvons immédiatement infléchir le travail du développeur pour le remettre sur le bon chemin, sans attendre de constater impuissants en fin de cycle de développement tout ce qui reste mal fait ou, pire, absolument bloquant du point de vue de l’accessibilité.

L’audit d’accessibilité tel qu’on le conçoit souvent, lourd, coûteux, exhaustif, sanctionné le cas échéant d’un label, pourra se faire à chaque fin de cycle, comme une évaluation sommative. Il permettra d’inscrire dans le temps la mesure de l’accessibilité comme un critère de qualité parmi d’autres, notamment grâce à l’obtention d’indicateurs.

Cette démarche en deux temps induit d’énormes bénéfices :

• La formation des développeurs est moins lourde à porter, puisque l’expert en accessibilité qui les accompagne se charge des notions complexes et filtre l’information à leur transmettre pour ne leur donner que ce qui est pertinent au développement en cours.
• Les cycles de validation de l’accessibilité se trouvent réduits. Dans la démarche classique, on estime à trois jours un audit pointu, auxquels il faut ajouter une restitution (quelques heures). Là, nous sommes assis l’un à côté de l’autre et chaque point est traité en temps réel après discussion de la meilleure approche pour le corriger.
• Les corrections ne coûtent presque rien, puisqu’elles sont intégrées suffisamment en amont, contre (dans la plupart des cas) plusieurs jours à la suite d’un audit classique, sans compter le temps de contrôle de non-régression de l’application web.

L’audit final aura déjà été amplement simplifié du fait de l’accompagnement du projet au jour le jour, mais il servira toujours d’évaluation sommative, si possible exhaustive, de l’évolution accomplie entre deux audits finaux.

Accessibilité agile : dans quel contexte ?

La méthode exposée ici ne peut pas s’appliquer à toutes les situations. Constituer un binôme développeur/expert ne sera pas toujours possible. Il y a en effet sur le marché beaucoup plus de développeurs que de véritables experts en accessibilité.

Le contexte spécifique d’expérimentation de cette méthode est celui d’une grande entreprise responsable, qui a choisi de constituer une véritable équipe d’experts qui peuvent accompagner au jour le jour les projets qui le nécessitent.

J’ai eu l’occasion de travailler plusieurs fois selon sensiblement le même principe sur des projets : je m’assois à côté de l’intégrateur HTML/CSS/JS ou du développeur Flash ou Flex, et je valide à la volée ses progrès. Si nous décelons des soucis, nous les corrigeons tout de suite. Je lui explique le problème, nous trouvons ensemble une solution, et la correction est intégrée directement.

A la lecture de cet article, vous pourriez penser qu’un mode de développement à quatre mains n’est pas pour vous, et vous vous trompez peut-être. Cette méthode reste une piste tout à fait envisageable dans un bien plus grand nombre de contextes si l’on réfléchit en termes de charge de travail : pour dix jours d’un développeur côté client, l’expert accessibilité ne sera sollicité qu’une journée.

En guise de conclusion

Nous n’avons pas encore parlé d’un avantage indirect de cette méthode d’accompagnement en mode agile : c’est l’intégration à long terme par le développeur des subtiles problématiques d’accessibilité ; cet apprentissage sera beaucoup plus profitable qu’une formation théorique (puisque appliqué), et plus marquant (puisque le développeur constatera de lui-même les progrès réalisés par son produit).

En accompagnant le développement au fur et à mesure au lieu de devoir tout reprendre en fin de course, en simplifiant les processus de production/correction, nous avons substantiellement réduit la charge liée à la qualité du produit et garanti une meilleure accessibilité des projets.
Reste à éprouver cette méthode dans d’autres structures, par exemple les petites agences, les institutions publiques, etc. Nous espérons au moins avoir fourni une piste de réflexion pour améliorer l’intégration de la contrainte d’accessibilité dans la vie des projets web.

Post-Scriptum

Cet article publié en 2010 a initialement été proposé à OpenWeb en
2008. Le mode de codage à quatre mains et le parallèle avec les
méthodes agiles étaient déjà pertinents et je les pratiquais au
quotidien dans mon activité professionnelle depuis un an ou deux. Deux
ans après, il est plus que jamais intéressant de faire évoluer les
pratiques de l’accessibilité. Un grand merci à Élie Sloïm pour avoir
grandement contribué au dépoussiérage de cet article.

Notes

« Evaluation continue des processus d’apprentissage, elle a pour but d’informer l’apprenant puis l’enseignant sur le degré d’atteinte des objectifs. » (Rieunier, Pédagogie, dictionnaire des concepts clés, 1978)
Source : http://wiki.univ-paris5.fr/wiki/Évaluation

« L’évaluation sommative attribue une note chiffrée à une performance jugée représentative de l’apprentissage terminé, et ceci aux fins de classer ou de sélectionner les élèves. La procédure ne poursuit donc plus, en théorie, aucun dessein pédagogique, mais répond à des exigences administratives, institutionnelles et sociales. » (M. Minder)
Source : http://wiki.univ-paris5.fr/wiki/Évaluation