Bonjour,
*Olivier a écrit : "Deux lignes? Peut-être, si tu as déjà une librairie chargée qui permet de condenser le code nécessaire pour parcourir le DOM, lister les éléments IMG, comparer @src et @alt (en n'oubliant pas de traiter les chaines pour éviter les blagues liées aux caractères spéciaux et autres scories de nommage de fichiers dans différents OS), remplacer l'un par l'autre. En ne se plantant pas sur le moment où on le fait, pour être sûr que l'image modifiée soit bien celle consultée par la TA via l'API d'access du client. Mais sinon, oui...Ah, attends, si des images sont insérées dynamiquement dans le DOM, genre sur un flux d'actus?Ou si on a plusieurs versions de l'image dans un contexte de RWD? Faut détecter l'événement et relancer la routine, non? Si tu sais faire ça en deux lignes, sans tester, je veux bien le code."* Les 2 lignes c'est une façon de parler, je remplace par "une fonction de quelques lignes" ça te convient mieux ? Et sans librairie (derrière au final ça fait la même chose que sans hein... donc pour ton histoire du chargement c'est encore pire). Et je ne comprends rien à ce que tu m'expliques là : que vient faire la source de l'image là dedans ? que vient faire le moment de l'exécution (événementiel ou autre) ? quel rapport avec le responsive ? quel rapport avec la TA ? Le problème est identifié, non ? Si tu cherches à me faire dire que ça demande des compétences de développeur, je te le confirme si tu avais un doute. Et enfin, la remarque sur le test, là encore je ne vois pas le rapport : un test n'est pas dépendant d'un nombre de lignes. Donc oui, l'accessibilité ce n'est pas que de l'orthographe et ça a donc un coût et si pas de budget, on peut compter sur autre chose pour que ce soit fait (ce que j'ai appelé convictions, le terme peut être différent si on veut : sérieux, l'implication ou autres, bref). On peut se cacher les yeux mais c'est comme ça (et ça ne veut pas dire que je suis un partisan de ces modes de prod, très loin de là). *Olivier : "Et, oui, bien sûr, ne documentons pas cela. Cela n'arrive jamais qu'un bout de code, au rôle mystérieux pour quiconque sauf celui qui l'a écrit, traine des années dans le code sans que personne n'ose jamais le supprimer, y compris lorsqu'il est rendu obsolète par une autre évol. Et d'ailleurs, ne documentons rien, jouons-la hard core, c'est nettement plus fun."* Je ne me rappelle pas avoir écrit qu'il ne fallait pas documenter (comme je n'ai jamais dit que 2 lignes de code ça ne se teste pas). Je n'ai rien écrit de la sorte mais bon (j'adore le fait de faire reposer ce genre de problèmes sur le développeur ermite et asocial qui veut garder son code mystérieux). Olivier a écrit : "Pure conjecture, on ne sait pas comment est monté ce projet. Si chaque page (ou groupe de pages) charge la même quantité de JS quelque soit le contenu, et les fonctionnalités, il y a sans doute aussi un problème..." Certes, on a pas toutes les infos mais là encore je ne vois pas le problème avec ce qui nous intéresse (tu parles perfs là ça reste intéressant mais bon). *Olivier a écrit : "C'est pas ça qui va faire tomber le serveur, sûr... mais on n'a pas non plus d'indication sur le volume traité, ni sur la politique de cache. Mais je parlais surtout du fait que l'on va boucler sur le DOM à chaque page (pour *RIEN*, dans 100-epsilon% des cas). On n'a pas d'indication sur la taille des pages, ni sur la profondeur du DOM, ni sur le nombre d'images par page. Si on refait une passe à chaque màj du DOM, en plus... Surfant sur une machine trop courte en mémoire, je peux te dire que je sens la différence entre une page codée avec les pieds et une autre."* Même chose qu'au-dessus (et je n'ai pas parlé de code mal foutu). Après, le gros taff se fait côté du navigateur. Je ne suis pas un spécialiste de la perf mais du traitement d'attributs il doit falloir y aller très fort pour sentir quelque chose sur le client. *Olivier a écrit : "Mon propos n'est pas que ce type de modif n'est pas à faire, mais que c'est une solution à comparer (coût, impact utilisateur, contribution aux emmerdes futures) à celle qui consiste à corriger le bug à la source; et à celle consistant à ne rien faire. Pas sûr que la JS gagne.Ah j'oubliais: évidemment, si la page est consultée via une extraction du contenu, par un agrégateur ou autre, ben ça va être coton pour avoir le bon alt."* L'avantage de la solution JS est d'être indépendante de la base même de l'outil. Bon après faut peut être aussi faire confiance aux techniciens pour savoir juger de ça... Concernant, l'extraction ou l'agrégateur ça peut se baser sur une source générée aussi. *Olivier a écrit : "J'ai lu un article où un développeur de Yammer expliquait qu'il avait codé une feature en une heure; et qu'il avait passé environ 20h à la documenter et l'expliquer à ses collègues pour qu'ils l'utilisent dans leur code. Avec en conclusion: la simplicité n'est jamais qu'apparente, dès que l'on ajoute quelque chose il faut être conscient que l'on ajoute des couches et des couches de complexité."* Faut remettre dans le contexte : comparé une feature à un patch temporaire... *Olivier a écrit : "Je me rappelle aussi cet audit où lorsque j'ai fait une préco toute simple sur les alt, le client m'a dit qu'avec 6000 images dans la médiathèque, j'allais le rendre fou. Qu'adviendra-t-il sur ce projet lorsque, ben, finalement l'accessibilité devient une exigence, et qu'il faudra se recogner l'ensemble des images déjà contribuées pour mettre le bon alt? On a le droit de s'en foutre... ou pas."* Oui, même sur une minuscule implémentation, ça peut arriver (je ne connais personne se disant heureux d'avoir à corriger des choses chiantes) donc je ne comprends pas la démonstration par rapport à ce cas : c'est chiant c'est tout. Tu transformes le problème, il s'agit d'images de décoration avec alt=" ", la question de la pertinence ne pourra se poser que si un changement fonctionnel de ces images intervient. Romain Le 23 avril 2015 15:31, Olivier Nourry <[email protected]> a écrit : > Bonjour Romain, > > > > *Romain a écrit:"Ce qui est recherché c'est du mesurable, mettre des > tâches dans des cases ("acte technique" ou autre peu importe) et > pouvoir les estimer pour les facturer et gérer des budgets ; ça ne va pas > plus loin que ça. Aller plus loin c'est avoir des convictions."* > > Justement, mon propos est que l'accessibilité dans un développement n'est > *pas* mesurable. Si ça l'était, on serait capable de sortir des métriques > fiables, depuis le temps qu'on essaye... Mon parallèle avec l'orthographe > sert à illustrer cela: l'orthographe a un coût (celui investi - et c'est > colossal - pour apprendre la langue; le temps passé à relire et corriger; > mais aussi l'argent investi pour développer des outils genre correcteurs > orthographiques, que nous payons via les logiciels). Pourtant on est bien > en peine de budgéter cet aspect d'un projet. > Ta conclusion "aller plus loin c'est avoir des convictions", c'est joli, > ça claque; mais pour être honnête je n'ai pas compris où tu veux en venir. > > > *Romain a écrit: "**La coder c'est deux lignes. La documenter ? La tester > ? Bon soyons fous, on le fait c'est pas bien long sur un tel truc."* > > Deux lignes? Peut-être, si tu as déjà une librairie chargée qui permet de > condenser le code nécessaire pour parcourir le DOM, lister les éléments > IMG, comparer @src et @alt (en n'oubliant pas de traiter les chaines pour > éviter les blagues liées aux caractères spéciaux et autres scories de > nommage de fichiers dans différents OS), remplacer l'un par l'autre. En ne > se plantant pas sur le moment où on le fait, pour être sûr que l'image > modifiée soit bien celle consultée par la TA via l'API d'access du client. > Mais sinon, oui... > Ah, attends, si des images sont insérées dynamiquement dans le DOM, genre > sur un flux d'actus? Ou si on a plusieurs versions de l'image dans un > contexte de RWD? Faut détecter l'événement et relancer la routine, non? > Si tu sais faire ça en deux lignes, sans tester, je veux bien le code. > > Et, oui, bien sûr, ne documentons pas cela. Cela n'arrive jamais qu'un > bout de code, au rôle mystérieux pour quiconque sauf celui qui l'a écrit, > traine des années dans le code sans que personne n'ose jamais le supprimer, > y compris lorsqu'il est rendu obsolète par une autre évol. Et d'ailleurs, > ne documentons rien, jouons-la hard core, c'est nettement plus fun. > > > > *Romain a écrit: "**Concernant le déploiement sur toutes les pages, les > systèmes de templates facilitent grandement le travail."* > Pure conjecture, on ne sait pas comment est monté ce projet. Si chaque > page (ou groupe de pages) charge la même quantité de JS quelque soit le > contenu, et les fonctionnalités, il y a sans doute aussi un problème... > > *Romain a écrit: "**En ce qui concerne le téléchargement, on parle d'un > script de deux lignes mis en cache au premier appel. Quand on commencera à > s'intéresser aux perfs sur des scripts aussi ridicules c'est qu'on aura > fait un bon de géant dans nos productions."* > C'est pas ça qui va faire tomber le serveur, sûr... mais on n'a pas non > plus d'indication sur le volume traité, ni sur la politique de cache. Mais > je parlais surtout du fait que l'on va boucler sur le DOM à chaque page > (pour *RIEN*, dans 100-epsilon% des cas). On n'a pas d'indication sur la > taille des pages, ni sur la profondeur du DOM, ni sur le nombre d'images > par page. Si on refait une passe à chaque màj du DOM, en plus... Surfant > sur une machine trop courte en mémoire, je peux te dire que je sens la > différence entre une page codée avec les pieds et une autre. > > > Mon propos n'est pas que ce type de modif n'est pas à faire, mais que > c'est une solution à comparer (coût, impact utilisateur, contribution aux > emmerdes futures) à celle qui consiste à corriger le bug à la source; et à > celle consistant à ne rien faire. Pas sûr que la JS gagne. > Ah j'oubliais: évidemment, si la page est consultée via une extraction du > contenu, par un agrégateur ou autre, ben ça va être coton pour avoir le bon > alt. > > > *Romain a écrit: "**Enfin, j'ai beau retourné la chose dans tous les > sens, je ne vois pas comment un truc non fonctionnel (remplacer un " " par > "") peut impacter quoi que ce soit dans le fonctionnement d'un module (sauf > si il fait des choses en se basant sur un attribut alt " ").* > Non, utiliser un espace pour signaler un champ vide puis compter sur le > script pour rattraper le coup, ça c'est totalement à éviter (la solution > d'Aurélien me parait préférable, à tout prendre). Parce que ça veut dire > qu'on impose une règle (absurde) aux contributeurs, donc qu'on la... > documente (ha ha), l'explique et qu'on fait le pari que tous les > utilisateurs vont l'appliquer. Et revenir en arrière, et oublier tout ça > quand on finit par faire évoluer le module. 100% de chances que ça génère > moult problèmes. > > J'ai lu un article où un développeur de Yammer expliquait qu'il avait codé > une feature en une heure; et qu'il avait passé environ 20h à la documenter > et l'expliquer à ses collègues pour qu'ils l'utilisent dans leur code. Avec > en conclusion: la simplicité n'est jamais qu'apparente, dès que l'on ajoute > quelque chose il faut être conscient que l'on ajoute des couches et des > couches de complexité. > > Je me rappelle aussi cet audit où lorsque j'ai fait une préco toute simple > sur les alt, le client m'a dit qu'avec 6000 images dans la médiathèque, > j'allais le rendre fou. Qu'adviendra-t-il sur ce projet lorsque, ben, > finalement l'accessibilité devient une exigence, et qu'il faudra se > recogner l'ensemble des images déjà contribuées pour mettre le bon alt? On > a le droit de s'en foutre... ou pas. > > > > Cordialement, > > [image: --] > Olivier Nourry > [image: http://]about.me/oliviernourry > <http://about.me/oliviernourry> > > > Le 23 avril 2015 12:00, Romain Gervois <[email protected]> a écrit > : > >> Bonjour, >> >> "Pardon, mais j'ai un peu de mal avec cet argument ... Isoler >> l'accessibilité en tant qu'acte technique revient à en faire un élément >> optionnable, ce qui est le meilleur moyen d'en faire un élément optionné. >> Ce qui distingue l'accessibilité du reste, c'est qu'il y a des situations >> où elle n'est pas négociable..." >> >> Ce qui est recherché c'est du mesurable, mettre des tâches dans des cases >> ("acte technique" ou autre peu importe) et pouvoir >> les estimer pour les facturer et gérer des budgets ; ça ne va pas plus >> loin que ça. Aller plus loin c'est avoir des convictions. >> >> "Je ne suis pas fan de la solution JS. Déjà, il faudrait la coder, la >> documenter, la tester (on prend sur le "budget rustines" pour cela?), >> l'implémenter sur toutes les pages... Plus l'imposer à chaque >> téléchargement de page, et la faire tourner sur chaque page, pour tous les >> utilisateurs. Tout ça pour? De plus, que se passera-t-il lorsque le module >> évoluera? Qu'il aura un autre comportement qui mettra en échec le bout de >> JS bricolé? AMHA, il faut soit faire la correction dans les règles (donc à >> la racine), soit ne rien faire." >> >> La coder c'est deux lignes. La documenter ? La tester ? Bon soyons fous, >> on le fait c'est pas bien long sur un tel truc. >> >> Concernant le déploiement sur toutes les pages, les systèmes de templates >> facilitent grandement le travail. >> >> En ce qui concerne le téléchargement, on parle d'un script de deux lignes >> mis en cache au premier appel. Quand on commencera à s'intéresser aux perfs >> sur des scripts aussi ridicules c'est qu'on aura fait un bon de géant dans >> nos productions. >> >> Enfin, j'ai beau retourné la chose dans tous les sens, je ne vois pas >> comment un truc non fonctionnel (remplacer un " " par "") peut impacter >> quoi que ce soit dans le fonctionnement d'un module (sauf si il fait des >> choses en se basant sur un attribut alt " "). >> >> Bref, la solution JS me semble tout à fait pertinente dans ce cas (tout >> en remontant et en attendant des retours côté éditeur). >> Le tout ou rien, bof bof (on ne parle quand même pas d'un patch >> monstrueux d'une webapp là). >> >> Romain >> >> Le 23 avril 2015 11:00, Olivier Nourry <[email protected]> a écrit : >> >>> Bonjour Nathalie, >>> >>> *"Il n'y a pas de ligne budgétaire pour l'accessibilité."* >>> Pardon, mais j'ai un peu de mal avec cet argument. Le module est buggé; >>> il faut donc traiter le bug, c'est-à-dire évaluer son impact (=le coût de >>> l'inaction), son coût de correction, et prendre une décision en fonction de >>> ces éléments. Point. Si l'impact est plus important que le coût, c'est à >>> corriger, sinon, on laisse en l'état. Personnellement je n'ai pas de >>> scrupule à laisser un bug qui ne dérange personne (*se couvre la tête avec >>> les bras pour se protéger des projectiles lancés par les >>> jusqu'au-boutistes*). Car l'argent dépensé ici pour rien aurait pu être >>> investi de manière plus utile sur un problème plus impactant. Le fait >>> d'avoir budgété ou non l'accessibilité (on va en reparler plus bas) n'a pas >>> grand chose à voir là-dedans. Note: dans les impacts, ne pas oublier tout >>> ce qui n'est pas accessibilité, genre SEO, dette technique et connexions >>> bas débit. >>> >>> Je n'ignore pas les contraintes du terrain et la difficulté qu'il y a à >>> faire le job de CP (je l'ai été), où l'on est redevable des remises >>> accordées par un commercial qui empoche sa prime tandis que l'équipe se >>> fait engueuler pour avoir dépassé la charge qu'elle avait évaluée comme >>> insuffisante. Mais cette excuse du "budget accessibilité" est fumeuse, pour >>> rester poli. Y a-t-il un budget "orthographe"? Un budget "commentaires >>> du code"? Un budget "réduction de la dette technique"? J'en doute. Pourtant >>> tout designer/CP/contributeur/développeur conscient de sa responsabilité va >>> agir dans le bon sens. Pas de raison qu'il en soit autrement pour >>> l'accessibilité. Nous sommes tous bien placés sur cette liste pour savoir >>> que l'accessibilité requiert une compétence spécifique, acquise via de la >>> formation et l'expérience... Mais il en va de même de toute composante de >>> ce que l'on appelle, pour faire simple, un travail de qualité. Isoler >>> l'accessibilité en tant qu'acte technique revient à en faire un élément >>> optionnable, ce qui est le meilleur moyen d'en faire un élément optionné. >>> Ce qui distingue l'accessibilité du reste, c'est qu'il y a des situations >>> où elle n'est pas négociable... >>> >>> Et comment budgète-t-on l'accessibilité dans un développement? Je fais >>> ce métier depuis 8 ou 9 ans. J'ai accompagné 15 ou 20 projets, je forme des >>> chefs de projets à l'accompagnement, j'ai obtenu ou contribué à obtenir 6 >>> labels AccessiWeb. Mais je suis toujours bien incapable de dire ce que >>> coûte l'accessibilité, réellement... Tout comme je ne sais pas ce que coûte >>> une bonne orthographe. Je peux isoler des interventions dont le coût est >>> directement et uniquement imputable à l'accessibilité... mais c'est tout. >>> Pour moi cette notion de "ligne budgétaire pour l'accessibilité" est >>> artificielle, et dangereuse. >>> >>> >>> >>> Je ne suis pas fan de la solution JS. Déjà, il faudrait la coder, la >>> documenter, la tester (on prend sur le "budget rustines" pour cela?), >>> l'implémenter sur toutes les pages... Plus l'imposer à chaque >>> téléchargement de page, et la faire tourner sur chaque page, pour tous les >>> utilisateurs. Tout ça pour? De plus, que se passera-t-il lorsque le module >>> évoluera? Qu'il aura un autre comportement qui mettra en échec le bout de >>> JS bricolé? AMHA, il faut soit faire la correction dans les règles (donc à >>> la racine), soit ne rien faire. >>> >>> >>> Cordialement, >>> >>> [image: --] >>> Olivier Nourry >>> [image: http://]about.me/oliviernourry >>> <http://about.me/oliviernourry> >>> >>> >>> Le 22 avril 2015 13:31, Nathalie Le Pontois - AE < >>> [email protected]> a écrit : >>> >>>> Je suis le prestataire. Nous installons un module communautaire. Le >>>> modifier implique que les mises a jour ne sont plus possibles sauf si la >>>> modification est impactée sur le module dans sa version communautaire. >>>> Il n'y a pas de ligne budgétaire pour l'accessibilité. >>>> >>>> Nathalie Le Pontois >>>> >>>> Le 22 avr. 2015 à 13:28, Ariane Pro <[email protected]> a >>>> écrit : >>>> >>>> Surtout que le prestataire gagnerait à l'implémenter sur son composant >>>> pour améliorer son produit... >>>> >>>> -- >>>> Ariane Pro >>>> Envoyé avec Sparrow <http://www.sparrowmailapp.com/?sig> >>>> >>>> Le mercredi 22 avril 2015 à 12:19, Antoine Bouet a écrit : >>>> >>>> A ce que je vois, tous les prestataires ne sont pas généreux avec >>>> leurs clients, c'est dommage car ca ne me parait pas être de grosses >>>> modifications ... >>>> >>>> Cordialement, >>>> >>>> Antoine Bouet >>>> Ingénieur Développement >>>> Expert AccessiWeb en Evaluation >>>> >>>> CIMEOS >>>> Montbéliard - Besançon - Paris >>>> >>>> e-mail : [email protected] >>>> tel. : +33(0)9 72 30 72 42 >>>> >>>> www.cimeos.com >>>> >>>> COORDONNEES DU SUPPORT : >>>> Hébergement et Nom de Domaine : [email protected] / 0899 49 42 00 >>>> (1.34€/appel puis 0.34/min) >>>> Maintenance des sites : [email protected] >>>> Le 22/04/2015 12:16, Nathalie Le Pontois - AE a écrit : >>>> >>>> Je ne serai pas contre si mon budget me le permettait.. Ce n'est >>>> malheureusement pas le cas. >>>> >>>> Nathalie Le Pontois >>>> >>>> Le 22 avr. 2015 à 11:49, Antoine Bouet <[email protected]> a >>>> écrit : >>>> >>>> Bonjour à tous, >>>> >>>> En même temps, quitte à intervenir autant modifier l'extension générant >>>> cette "absurdité" plutôt que de rajouter une couche supplémentaire en JS >>>> qui peut avoir des dommages collatéraux non prévus. >>>> >>>> Après ce n'est que mon point de vue :) >>>> >>>> >>>> Cordialement, >>>> >>>> Antoine Bouet >>>> Ingénieur Développement >>>> Expert AccessiWeb en Evaluation >>>> >>>> CIMEOS >>>> Montbéliard - Besançon - Paris >>>> >>>> e-mail : [email protected] >>>> tel. : +33(0)9 72 30 72 42 >>>> >>>> www.cimeos.com >>>> >>>> COORDONNEES DU SUPPORT : >>>> Hébergement et Nom de Domaine : [email protected] / 0899 49 42 00 >>>> (1.34€/appel puis 0.34/min) >>>> Maintenance des sites : [email protected] >>>> Le 22/04/2015 11:35, Philippe Vayssière a écrit : >>>> >>>> Bonjour, >>>> >>>> étant donné les contraintes côté serveur, peut-être un correctif >>>> JavaScript destiné à cacher l'image aux lecteurs d'écran ferait-il tout de >>>> même l'affaire ? >>>> Pour toutes les images ayant un alt=" " (ou espace insécable ou >>>> apparenté ou mieux un test "*n'est composé que d'espace(s)*" via un >>>> trim() >>>> <http://stackoverflow.com/questions/498970/trim-string-in-javascript> >>>> ), attribuer un alt="" et/ou peut-être aria-hidden="true" >>>> >>>> >>>> Bonne journée, >>>> Ph. Vayssière >>>> -- >>>> alsacreations.fr - alsacreations.com >>>> >>>> Le 22/04/2015 11:25, Nathalie Le Pontois - AE a écrit : >>>> >>>> Bonjour et merci beaucoup de cette réponse. >>>> Le module utilisé nous bloque. Il faudrait le recoder mais bien >>>> évidemment, nous n'avons pas le budget pour. >>>> Il n'y a pas de demande d'accessibilité sur ce site. Mais tant que >>>> faire se peut, j'essaye toujours de faire en sorte que les critères simples >>>> soient implémentés de base. >>>> Dans ce cas, j'imagine cependant qu'entendre "graphique" est plus >>>> acceptable que d'entendre la lecture du nom du fichier ... >>>> >>>> Nathalie Le Pontois >>>> 0637731973 >>>> [email protected] >>>> >>>> Le 22 avr. 2015 à 08:34, Frédéric Halna <[email protected]> a écrit : >>>> >>>> Bonjour Nathalie, >>>> >>>> Malheureusement un alt avec un espace n'est pas équivalent à un alt >>>> vide. >>>> >>>> Nvda par exemple ne vocalisera pas du tout une image dont l'alternative >>>> est vide. L'image est décorative et donc l'utilisateur de lecteur d'écran >>>> ne sera pas averti de sa présence. >>>> >>>> Dans le cas d'une image avec une alternative composée d'un espace, NVDA >>>> vocalisera "graphique" sans plus d'information. >>>> >>>> >>>> quel est le frein à pouvoir implémenter des alternatives vides ? >>>> >>>> >>>> Bonne journée. >>>> >>>> Frédéric. >>>> >>>> Le 21 avril 2015 16:56, Nathalie Le Pontois - AE < >>>> [email protected]> a écrit : >>>> >>>> Bonjour, >>>> >>>> Sur un projet, nous utilisons une médiathèque qui, lorsqu'elle affiche >>>> les images, met par défaut le nom du fichier image dans le alt et le title >>>> si les champs sont laissés vides. >>>> Je m'interroge sur le rendu sonore des lecteurs d'écran si le alt prend >>>> la valeur d'un espace (renseigné dans le bo). >>>> Est ce que le lecteur d'écran le lit ou l'évite ? >>>> Est ce acceptable ? >>>> >>>> Merci >>>> >>>> Nathalie Le Pontois >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> liste_gta mailing >>>> [email protected]http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>>> >>>> >>>> _______________________________________________ >>>> liste_gta mailing list >>>> [email protected] >>>> >>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>>> >>>> >>>> >>>> _______________________________________________ >>>> liste_gta mailing >>>> [email protected]http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>>> >>>> >>>> _______________________________________________ >>>> liste_gta mailing list >>>> [email protected] >>>> >>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>>> >>>> >>>> _______________________________________________ >>>> liste_gta mailing list >>>> [email protected] >>>> >>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>>> >>>> >>>> _______________________________________________ >>>> liste_gta mailing list >>>> [email protected] >>>> >>>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>>> >>>> >>> >>> _______________________________________________ >>> liste_gta mailing list >>> [email protected] >>> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >>> >>> >> >> _______________________________________________ >> liste_gta mailing list >> [email protected] >> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> >> > > _______________________________________________ > liste_gta mailing list > [email protected] > http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org > >
_______________________________________________ liste_gta mailing list [email protected] http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
