Here is an English version of the French guide “Petit guide à l’usage des hôteliers-restaurateurs et de leurs webmestres“ (FR).

What is this guide?

In some countries, incentive measures allow hotel managers to adapt their premises to the needs of disabled people, and there is a large amount of technical aids to facilitate their life. However, if we consider websites of hotels and restaurants, few efforts are made to take into account the different disabilities and to promote the technical adaptations made in the premises.

Most websites do not respect the basic principles of web accessibility, whether the users are disabled or not. It is necessary to inform hotel and restaurant managers and their webmasters so that they can take into account the needs of every potential user of their site. The quality of the information and its presentation being essential to build an inclusive and respectful information society.

The guide begins with general advice which will improve the accessibility of a website for all categories of guests. In the next section, advice is given for each of the four categories of disabilities (visual, motor, hearing, and cognitive). The third part recapitulates all the recommendations and allows you to evaluate an existing website or to verify that the key points have been taken into account during the design phase. To conclude, the final part gives some references regarding digital accessibility.

The CRI – Greta du Velay has written this guide thanks to the collaboration of several communities and expert associations in the areas of disabilities and technologies. The contributors are listed at the end of the guide. Thanks to Jenifer Marian Littman from Tourism for All UK for the English proof reading.

To go further we suggest collecting comments and propositions of readers in the comments of this post, in order to prepare the next version of the guide.

C’est possible, à condition d’y être sensible ! Ruby, le langage qui monte qui monte en donne un exemple. Une simple ligne de code permet de tracer un triangle de Sierpinski :

32.times{|y|print" "*(32-y),(0..y).map{|x|~y&x>0?" .":" A"}}

Le résultat :

Il suffit de remplacer 32 par le nombre de lignes souhaitées.

Bravo à Brian Mitchell (via DZone Snippets)

Explications

Ce programme exploite la compacité du langage Ruby pour tracer un semblant de triangle de Sierpinski. En fait il n’implémente pas un algorithme récursif mais utilise une petite formule magique (cf. commentaires) qui permet de tracer le triangle dans un espace discret.

On peut récrire le programme d’une façon plus claire et traditionnelle :

n = 32
for y in (0..n-1) do            # pour y allant de 0 à n-1 (c-a-d pour chaque l
    ligne = " "*(n-y)               # créer n espaces (puis n-1, puis n-2...)
                                    # représente la pente gauche du triangle
    for x in (0..y) do              # pour x allant de 0 à y (c-a-d pour chaque
        if (~y & x > 0) then            # ~y est le complément binaire de y, & le ET binaire
                                        # c'est la formule magique du programme
            ligne = ligne + "  "            # si (~y & x) > 0 la colonne contient un espace
            ligne = ligne + " A"            # sinon c'est un 'A'
        end
    end
    print ligne                 # afficher la ligne et passer à la suivante
end

D’autres lieux d’amusement : 99 bottles of beer dans 1200 langages de programmation…

Suite à la publication du Petit guide à l’usage des hôteliers-restaurateurs et de leurs webmestres, le Pôle Lozérien d’Economie Numérique nous invite à intervenir (mardi 29 avril 2008 de 15 heures à 17 heures à Mende) sur le thème de l’accessibilité technique des sites web et la prise en compte des handicaps par les sites web de prestataires touristiques.

Cette intervention intéressera les décideurs et concepteurs de sites web, ainsi que les organismes qui accueillent du public et souhaitent prendre en compte sur leur sites web les efforts d’accessibilité opérés dans leurs prémisses.

Contenu de l’intervention

• les utilisateurs, les contenus, les moyens d’accès ;
• les principes de séparation du contenu et de sa mise en forme ;
• l’application de ces principes pour faciliter la vie des utilisateurs ;
• les outils pour webmasters et concepteurs de sites ;
• les sources d’information pour aller plus loin.

Concernant le guide :

• introduction sur le but du guide ;
• revue des points importants lors de la conception ou l’adaptation d’un site qui respecte ses usagers ;
• les sites de référence pour travailler l’accessibilité de son site et mieux connaître les handicaps.

Le site de Polen
Inscription sur le site de Polen

[ English version ]

Le CRI a conçu, avec l’aide de plusieurs contributeurs (cf. ci-dessous), un « Petit guide à l’usage des hôteliers–restaurateurs et de leurs webmestres ». Son but est de sensibiliser les acteurs du tourisme à l’accessibilité de leurs sites web, ainsi que les webmasters qui travaillent pour eux. Car si la prise en compte de l’accessibilité physique des hôtels-restaurants devient peu à peu une réalité, les sites web restent largement peu soucieux de l’accessibilité technique et de la diffusion d’informations adaptées aux quatre principaux handicaps et aux séniors. Les hôteliers-restaurateurs auraient pourtant beaucoup à gagner à accorder un minimum d’attention à des clients qui profitent de plus en plus de leur temps pour voyager.

« Ce guide commence par des conseils généraux qui amélioreront l’accessibilité d’un site pour l’ensemble des visiteurs ainsi que sa visibilité pour les moteurs de recherche. Ensuite des conseils sont donnés spécifiquement pour chacun des quatre handicaps ciblés (visuel, moteur, auditif, cognitif) …/… Il est difficile d’être exhaustif, tant le problème de l’accessibilité est complexe et continuellement sujet à débats. Ce guide s’arrête donc à des conseils pratiques et réalistes, qui bien souvent feront le bonheur de tous les visiteurs, handicapés ou non, et sans pour autant dégrader le site et repousser les personnes non concernées. …/… Une troisième partie récapitule l’ensemble des conseils donnés, de façon à pouvoir rapidement évaluer un site existant ou vérifier que les différents points ont été pris en compte lors de la conception d’un site. Enfin, la quatrième partie donne des références incontournables en matière d’accessibilité numérique et du handicap. »

Le guide est disponible en français au format PDF (prochainement en anglais). Sa diffusion est gratuite, selon les termes de la licence Creative Commons (By-Nc-Sa).

Vous rencontrez des problèmes sur les sites web d’hôtels ? D’autres conseils vous paraîtraient utiles ? Cet article vous laisse la parole à travers les commentaires que vous pouvez laisser ci-dessous.

Le CRI publie un guide intitulé “Nouveaux outils & nouvelles technologies : guide de bonnes pratiques pour améliorer l’utilisation du e-learning dans les PME, une approche par l’expérience”. Basé sur l’analyse de projets e-learning, ce rapport propose une vue d’ensemble des technologies et des outils utilisés pour soutenir la formation. Quels sont les besoins des organismes de formation ? Qu’attendent les petites et moyennes entreprises de ces nouveaux services ? Comment choisir au mieux et mettre en application “la bonne solution” ?

Les nouvelles caractéristiques de ces outils peuvent être une source d’espoirs trop ambitieux, sans rapport avec les usages réels et les besoins des PME. En même temps, il y a un mouvement fort vers l’utilisation des technologies dans la formation car elles apportent une valeur ajoutée, parfois de façon inattendue, renforçant par exemple des mécanismes d’apprentissage informel.

Les PME doivent garder à l’esprit que nous sommes encore dans la préhistoire de l’e-learning. Elles doivent ainsi pratiquer une veille permanente tout en étant vigilantes par rapport aux tendances trop médiatisées. Dans ce contexte très évolutif, les meilleurs outils et technologies restent en général ceux qui sont les plus flexibles.

Il y a quelques semaines, Google lançait un jeu original (Google Image Labeler) dont le principe est assez simple. Le joueur se rend sur le site. Un autre joueur, connecté au même moment, lui est attribué aléatoirement de façon à créer une équipe. Les deux joueurs n’ont pas la possibilité de se connaître. Ensuite le jeu commence. Les deux joueurs de l’équipe reçoivent sur leur écran une même image (par exemple une mouette blanche dans le ciel bleu) et doivent en quelques secondes fournir des mots-clefs permettant de décrire cette image. L’équipe marque des points pour chaque mot-clef trouvé en commun par les deux joueurs. Par exemple Joueur 1 donne “oiseau blanc ciel bleu” et Joueur 2 “mouette blanche ciel”, les deux joueurs gagneront 1 point grâce à “ciel”. Puis une autre image s’affiche et tout recommence, pendant la minute trente que dure la partie. Le but final étant de marquer le plus de points, et de monter dans le classement général.

Au delà de ce jeu anecdotique qui peut occuper quelques minutes des millions d’utilisateurs, Google a trouvé un moyen efficace et gratuit de “tagguer” des images, c’est-à-dire leur attribuer des mots selon un sens commun. Dans l’exemple ci-dessus il y a au moins une certitude c’est la présence d’un “ciel” puisque le mot est cité par les deux joueurs. “oiseau” et “mouette” statistiquement apparaissent ensemble dans de nombreuses pages (essayez de taper ces deux mots dans Google), donc c’est une information intéressante même si elle n’est pas totalement fiable : il y a probablement un oiseau dans l’image. Idem pour “ciel” et “bleu”. Et “blanc” et “blanche” ne font aucun mystère pour Google, qui sait certainement travailler sur les racines des mots. Bref, en quelques secondes Google obtient des informations sur cette image, qui même si elles ne sont pas totalement fiables, pourront être affinées en reproposant la même image à une autre équipe. Impossible de biaiser le système, car il faudrait un consensus entre les joueurs, ce qui est impossible puisqu’ils ne se connaissent pas.

Il y a quelques semaines, Google (encore) lançait (encore) un nouveau service : Google Custom Search. Le principe est simple, pour résumer rapidement… Chacun peut créer son propre moteur de recherche, à partir d’une sélection de sites. Ensuite la recherche peut s’effectuer sur cet ensemble plutôt que sur le web tout entier ou sur un unique site comme c’est le cas actuellement. Le tout est gratuit pour celui qui crée son moteur (le webmaster) et pour celui qui fera les recherches (le visiteur). Cerise sur le gateau, il est possible de personnaliser l’apparence de la page de résultats.

Il y a une analogie avec le jeu présenté ci-dessus. Google ne va pas se priver d’exploiter les informations issues de ce montage astucieux. De nombreuses petites mains ont déjà commencé à sélectionner des sites qui traitent d’un même thème, et proposent ainsi une recherche thématique (certains parlent de moteurs de recherche verticaux). Google va lancer sa machine à statistiques pour essayer de comprendre ce que ces sites réunis ont en commun, quels mots ils partagent, quels mots reviennent souvent, quel espace du web est lié à cet ensemble de sites et quels mots ce même espace contient, etc. Les statistiques vont pouvoir faire ressurgir des informations importantes, mais cette fois à partir de sous-ensembles ordonnés du web. Il est évident que les recherches récurrentes faites sur le web tout entier vont profiter de ce qu’aura appris Google avec les mêmes recherches faites parmi ces sous-ensembles du web. Bref, toute trace d’ordre est bonne à (ap)prendre dans ce bouillon désordonné d’information qu’est le web.

Google fait donc travailler ses utilisateurs mais c’est de bonne guerre : le service est gratuit, et la seule chose qu’il demande est aux uns de sélectionner des sites qu’ils apprécient, et aux autres de faire des recherches parmi ces sites (qui les intéressent aussi). Les uns et les autres se nourrissent mutuellement, dans la basse-cour “offerte” par Google. Avec son pouvoir grandissant, cela rassure (un tout petit peu) de savoir qu’au delà de la publicité qui le fait vivre, les utilisateurs de tous bords restent une denrée précieuse pour la Grande entreprise, et qu’il faut les ménager. A ma connaissance, Exalead, le petit concurent européen de Google, n’a jamais sollicité les principaux intéressés pour améliorer son service, et doit considérer qu’une observation passive de la sphère internet suffit. Alors que Google, en rendant ses utilisateurs producteurs et actifs, a compris qu’il avait beaucoup à gagner en terme de pertinence des informations reccueillies.

Les polices de caractères Tiresias ont été conçues pour faciliter la lecture des personnes malvoyantes. Elles sont déclinées selon les usages :

• pour de l’affichage et la signalétique publics (Tiresias Infofont & Signfont),
• pour les claviers (Tiresias Keyfont),
• pour les textes larges, comme les pages d’un livre (Tiresias LPfont),
• pour l’affichage sur écran d’ordinateur (Tiresias PCfont),
• pour les sous-titrages TV (Tiresias Screenfont).

Chaque police contient des subtilités propres au handicap visuel et au contexte d’utilisation. C’est un travail de recherche approfondi, mené par plusieurs organismes anglais (dont le Royal National Institute of the Blind, partenaire du CRI-Greta du Velay), qui a permis de donner à ces polices une forme optimale et accessible. Par exemple le l (L minuscule) et I (i majuscule) sont clairement différents, de même que le i et le j sont plus difficiles à confondre. Les polices traditionnelles ne tiennent pas forcément compte de ces subtilités, rendant parfois la lecture hasardeuse même pour les voyants.

La police Keyfont, plus particulièrement adaptée à l’écriture des touches (clavier, calculatrice, boutons d’interphone, etc.) est désormais gratuite. Il suffit de la télécharger et de l’installer (format True-Type Font, TTF) sous Windows, Mac OS ou Linux. Au-delà de l’usage prévu par les chercheurs qui l’ont mise au point, elle est tout à fait utilisable dans d’autres contextes. Elégante, elle facilite la lecture de tous sans stygmatiser le handicap.

Sébastien Billard (Référencement, Design et Cie) nous signale un article critique à propos des polices Tiresias, ainsi que l’existance de l’APHont (A Font for Low Vision), une police dont les lettres sont (en autre) plus larges, plus ouvertes et plus espacées. Gratuite, présentation plus détaillée ici.

AJAX est une nouvelle façon de combiner un ensemble de technologies pour concevoir des sites web aux fonctionnalités très évoluées. Le terme signifie « Asynchronous Javascript And XML ». Mais au delà de Javascript et XML, le HTML et les CSS sont fortement impliqués dans la conception d’applications AJAX puisqu’ils en constituent la face visible. Le(s) navigateurs(s) étant la coquille d’accueil de ces applications. Une partie de l’application co-existe en général côté serveur, dans un langage différent de Javascript.

Le « Web 2.0 », symbole de l’explosion des nouvelles tendances au partage, et AJAX se nourrissent mutuellement. AJAX permet de concevoir des sites web dignes de véritables applications d’un nouveau type pour l’internaute. Et le « Web 2.0 », sans le saut technologique apporté par AJAX, ne serait pas vraiment vu comme une révolution.

Alors, [r]évolution majeure ou nouveau joujou pour technophiles ? AJAX est-elle la technologie qui manquait, ou juste une façon bricolée d’arriver à son but ? Son émergence est-elle dû aux qualités intrinsèques de Javascript, depuis longtemps critiqué, ou bien au désert laissé par ce qui devrait être LE framework (cadriciel) libre de développement d’applications portables, partageables, ouvertes et modifiables, ergonomiques ?

Voir l’article de Jean-Louis Nauges qui présente AJAX en détail et Fred Cavazza pour une “première définition du web 2.0″. Eric van der Vlist propose également un bon article de fond sur le web 2.0.

La mutation dans l’utilisation de Javascript

Juste avant la révélation AJAX, Javascript était plutôt le vilain petit canard des langages de programmation. Les développeurs du web ne l’aimaient pas pour différentes raisons : un nom proche de Java qui suscite l’amalgame, trop d’implémentations pas très compatibles entre elles et sources de bugs, trop sous l’emprise de Sun et Netscape, frein à l’accessibilité, et surtout des situations d’usage plus proches du gadget boiteux que de la fonctionnalité ingénieuse et indispensable. De nombreux exemples de sites ont contribué à la mauvaise image de marque de Javascript, le reléguant à quelques vérifications de formulaires ou la gestion des fenêtres “popup” insupportables.

Puis Google a marqué les esprits avec Google Maps, qui n’existerait pas sans Javascript, et qui est un exemple de bon usage remarquable. Depuis Javascript s’est désinhibé, et de véritables logiciels sont apparus dans nos navigateurs (citons Netvibes, exemple parmi tant d’autres^[1]). Google continue dans cette voie avec plusieurs services basés sur AJAX (Google Maps n’était pas le premier). Apple a également choisi Javascript pour développer ses widgets « Dashboard » (Yahoo! également avec ses Widgets), de véritables petites applications autonomes, que l’on peut modifier ou créer soit même. Et la fondation Mozilla développe un modèle proche d’AJAX+HTML avec son framework XUL.

Javascript est donc passé du petit langage d’agrément pour pages web au langage de développement d’applications réseau. Non pas parce qu’il est le plus doué pour ce genre de développement, mais essentiellement parce qu’il est présent dans tous les navigateurs quelque soit le système d’exploitation. Et le navigateur, pour un grand nombre d’utilisateurs, est la porte d’entrée de l’ordinateur et du réseau.

Avant AJAX : la page web est le support pour de petites applications Javascript, le plus souvent d’agrément et facultatives pour utiliser le contenu.

Avec AJAX : Javascript devient le coeur du site. Il génère du contenu HTML dont il a la maîtrise. D’autres langages côté serveur peuvent intervenir. Javascript, côté client, s’appuie sur le moteur graphique du navigateur pour générer l’interface de l’application, plus pratique que n’importe quel « toolkit ».

Cette mutation a quelque-chose de perturbant et d’illogique : le navigateur n’est plus seulement un logiciel pour consulter des pages web (ce que tout le monde avait fini par comprendre), mais c’est également un logiciel qui permet d’exécuter d’autres logiciels en son sein (en somme il devient système d’exploitation). Il faudra écrire un autre article pour essayer de comprendre comment les « vrais gens » vont interpréter et adopter ces prérogatives technologiques. Car s’il est logique pour le développeur AJAX de s’appuyer sur le navigateur pour créer un tableur, un traitement de texte, un calendrier, etc, du point de vue de l’utilisateur ce n’est pas aussi évident ! Le point d’orgue de ce délire technologique est peut-être atteint avec http://palary.org, un navigateur web créé avec AJAX… et qui fonctionne donc, pour l’instant, à l’intérieur d’un navigateur web ! Ou ici encore avec YouOS (voir la demo), un bureau entièrement fait en javascript (menu démarrer, barre des tâches, gestionnaire de fichiers, etc).

La simplicité et le bricolage

AJAX est donc plébiscité parce qu’il donne naissance à des applications comme jamais nous avions vu par la fenêtre du navigateur. Mais il s’agit bien d’applications qui pourraient exister de façon autonome : Google Earth par exemple est l’équivalent “extrapolé” et bien plus puissant de Google Maps. Parmi tous les langages existants et doués grosso modo des mêmes fonctionnalités que Javascript, aucun n’a séduit et rassuré les développeurs pour faire cela. Aucun n’a donné facilement accès à HTML pour mettre en page simplement des interfaces graphiques, les animer, et interagir avec l’utilisateur. Aucun n’a permis aux utilisateurs de créer des applications installables aussi naturellement qu’en téléchargeant quelques scripts texte dans un navigateur, en un clic, sur n’importe quel ordinateur. Aucun n’a su se médiatiser aussi rapidement auprès des milliers de petites mains « nouvelle génération » qui développent pour le web, et aucun ne s’est montré autant « nouveau » et « ouvert » à leurs yeux. C’est le petit qui l’emporte, sans marketing et sans stratégie à long terme, seul contre tous. Il est probablement là le succès (relatif pour l’instant) d’AJAX : la simplicité et le bricolage dans le navigateur, sous couvert de révolution technologique.

Car Javascript n’est pas encore portable (il faut encore développer certaines fonctionnalités en double ou triple selon le navigateur qui l’exécute), pas très rapide, pas plus dédié qu’un autre langage procédural pour gérer les particularités de la programmation client/serveur appliquée au web. Les applications AJAX qui ont médiatisé le concept ont été montées de toutes pièces avant que de véritables frameworks permettent de développer rapidement et de façon fiable. Il faut, comme cela est en train de se faire avec PHP, réinventer les poudres d’un véritable environnement de développement. On voit déjà différentes solutions^[2] pointer leur nez, souvent plus pour solutionner de nouveaux problèmes que pour jeter les bases théoriques d’un véritable outil de développement du « web 2.0 » (pour parler à la mode !).

En ce sens et d’un point de vue technique, c’est une forme de retour à la préhistoire, pas une révolution. Mais les « geeks » aiment reconstruire, la puissance Google est là, et les concurrents mastodontes ne leur ont rien proposé de plus séduisant sur les atouts évoqués. En attendant AJAX prend donc la place qu’on lui laisse…

L’association BrailleNet publie un manuel méthodologique pour aider les développeurs et gestionnaires de sites web à évaluer l’accessibilité de leurs sites, et à défaut corriger les points défaillants. Les critères utilisés sont ceux du référentiel AccessiWeb, composé de 92 critères, référencés sous forme de fiches au sein du “Guide AccessiWeb”. Par exemple le critère n°1 est “Chaque élément graphique possède-t-il une alternative textuelle ?”. Chaque fiche donne des méthodes pratiques pour évaluer le point abordé.

Les retours des utilisateurs ont montré la nécessité d’avoir des outils concis et pragmatiques pour aborder le travail d’évaluation. Ce manuel en 4 volumes constitue donc des “méthodes opérationnelles” spécifiques selon l’approche souhaitée par l’évaluateur. Il couvre l’évaluation par le code source, l’évaluation par la barre d’accessibilité AIS, l’évaluation par la barre d’accessibilité Web Developer, l’évaluation par le logiciel JAWS.

Méthode

Selon la méthode de travail souhaitée, il suffira de choisir un des 4 volumes du manuel et de vérifier les 92 points du référentiel. Par exemple pour le point n°1, avec une approche par le code source, le guide préconise : “1. Identifier tous les éléments IMG en faisant une recherche dans le code source. - 2. Vérifier que chaque élément IMG a un attribut ALT qui lui est associé.”

Notons qu’Hervé Chuzeville a réalisé un tableau récapitulatif des points à vérifier (sur deux pages), displonible en plusieurs formats sur son site.

Plus d’excuse donc pour ne pas se lancer dans une évaluation profonde de l’accessibilité de ses sites…

Références

• Le manuel AccessiWeb.
• Le guide AccessiWeb et ses 92 critères.
• L’association BrailleNet, a l’initiative des ces outils. Voir également les formations accessibilité.

Enervé par des commentaires répétitifs de spammers (pipi, caca, etc), j’ai légèrement modifié Dotclear de façon à berner ces messieurs. Les systèmes antispam que j’avais testés ne me convenaient pas, puisqu’il fallait rester aux manettes pour effacer les commentaires indésirables.

En fait les spammers sont assez feignants (sinon ils ne feraient pas ce métier). Ils cherchent à automatiser à moindre frais pour poster sur les systèmes de blog les plus populaires. Il suffit d’introduire une petite modification dans le fonctionnement de son gestionnaire de blog pour débusquer les trompeurs. Quand un spammer réussi à passer j’ajoute une nouvelle méthode de détection. Pour l’instant ce petit hack de Dotclear suffit à tromper ceux qui nous ennuyaient. C’est simple, plus aucun commentaire de spam !

Pour les sceptiques, voici le log des messages de spam reçus sur ce blog (vidé de sa moitié de temps en temps). MAJ : ce blog fonctionne maintenantavec Wordpress.

IMPORTANT : Il faut appliquer successivement les modifications (méthodes de détection) proposées ci-dessous, et non pas en choisir une au hasard (à moins de comprendre ce que l’on fait). Ou bien vous pouvez télécharger les fichiers modifiés, en bas de page. Et surtout, n’oubliez pas de tester vos modifications en vous envoyant un commentaire.

Méthode de détection 1

Dans le fichier /themes/votredossiertheme/form.php, ajouter cette ligne :

<!-- <input type="hidden" name="name" value="value" /> -->

juste avant le dernier champ fieldset :

</fieldset>

Et dans /layout/prepend.php, chercher la ligne contenant :

if ($blog->addComment($post_id,$c_nom,$c_mail,$c_site,

et transformer en :

if (isset($_POST['name']) or     $blog->addComment($post_id,$c_nom,$c_mail,$c_site,

Voilà. Un navigateur respecteux ignorera le commentaire (et n’enverra donc pas le champ caché), un spammer irrespectueux ne prend pas le peine de tester le commentaire HTML et son message sera ignoré… Très facile à contourner, mais en attendant ça filtre les ballots.

Methode de détection 2

Si le spammer n’analyse pas le contenu HTML de la page, le hack ci-dessus est inefficace. Mais dans ce cas, il doit connaître la nature des champs à envoyer au serveur pour poster le message. Changeons un peu le code de façon à rendre son automatisation obsolète :

Toujours dans le fichier /themes/votredossiertheme/form.php, chercher la ligne contenant :

<textarea name="c_content" id="c_content" cols="35" rows="7">

et transformer en :

<textarea name="c_content_blabla" id="c_content" cols="35" rows="7">

Ensuite dans /layout/prepend.php, remplacer c_content par c_content_blabla (à deux endroits, lignes 226 et 232).

Si le robot spammer automatise son envoi, il utilisera c_content comme nom de champ. Mais votre DotClear customizé s’attend à recevoir le message dans c_content_blabla, qui sera vide. Plouf !

Methode de détection 3

Certains spammers bourrent les champs TEXTAREA du formulaire avec leurs infamies. Trompons un peu plus l’ennemi avec cette méthode 3. Pensez également à appliquer les méthodes 1 et 2 ci-dessus.

Dans le fichier /themes/votredossiertheme/form.php, ajouter cette ligne :

<p class="field" style="display: none">Commentaire :
  <textarea name="c_content" cols="35" rows="7">Ne pas modifier ceci !</textarea> </p>

par exemple juste avant :

<p class="field"><label for="c_content">Commentaire :</label>

Ensuite dans /layout/prepend.php, modifier la même ligne que dans la méthode 1 pour avoir :

if (isset($_POST['name']) or $_POST['c_content'] != "Ne pas modifier ceci !" or
  $blog->addComment($post_id,$c_nom,$c_mail,$c_site,

Normalement ce champ de formulaire n’est pas affiché par le navigateur (s’il connait CSS) et n’est donc pas modifié. Les robots devraient tomber dans le piège en remplissant ce champ, chose à ne pas faire pour que le commentaire soit pris en compte… Et comme le nom du champ est celui normalement utilisé par Dotclear (c_content), cela donne une chance supplémentaires aux spamikazes de tomber dans le panneau.

La suite

Quand les robots contourneront ces tests, il faudra en inclure un autre, puis un autre, etc. Au mieux on élimine les messages dont on est sûr qu’ils sont un spam, au pire on les laisse passer, et dans ce cas un plugin antispam peut prendre la relève, comme d’habitude. A l’inverse, une méthode supplémentaire basée sur JavaScript pourrait confirmer que le message n’est pas un spam. Le tout est de s’adapter plus vite que l’ennemi. Mais comme les spammers ne consultent jamais les sites qu’ils poluent, nous sommes tranquilles !

Sinon, d’autres solutions techniques contre le spam des trackbacks sont proposées dans les commentaires ci-dessous.

Les fichiers modifiés

Vous pouvez obtenir les fichiers en service actuellement sur ce blog : form.php et prepend.php (attention, un fichier de log spamlog.txt est créé sur la racine du site pour enregistrer les messages ignorés). Même si ce serait plus pratique, il n’y aura probablement jamais de plugin Dotclear clef-en-main, car l’uniformisation amènerait rapidement des contournements de la part des spammers. Restons isolés pour éviter les tirs groupés !