{"partition": "head_middle", "source_domain": "openweb.eu.org", "digest": "sha1:YKNIQQ7LGKGZNEERFBYHX4B6CTX7WTSZ", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00013.parquet"}
Voir ailleurs
See this site in English
Débutant
Décideur
Industrialisation
Mise en page
Pages dynamiques
Accessibilité agile : de la théorie à la pratique
Openweb.eu.org > Articles > Accessibilité agile : de la théorie à la pratique
La démarche d’accessibilité ne pourra bientôt plus se passer d’une refonte en profondeur. Nous allons exposer ici une méthode innovante qui, loin de fonctionner comme la classique évaluation-sanction en fin de processus, propose une amélioration progressive tout au long de la vie d’un projet.
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 :
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. 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 cod