Webrichtlijn 59 t/m 62: Links naar e-mailadressen
Links naar e-mailadressen: het e-mailadres waaraan het te versturen bericht is gericht dient zichtbaar te zijn in de linktekst. (R-pd.8.16) Links naar e-mailadressen: de URL in het href attribuut van een link naar een e-mailadres, mag alleen het mailto protocol en een e-mailadres bevatten. (R-pd.8.17) Pas geen technische maatregelen toe op de website om een e-mailadres te verhullen voor spam robots. (R-pd.8.18) Ga uiterst voorzichtig om met het publiceren van e-mailadressen van bezoekers van de website. Informeer de bezoeker over welke gegevens worden gepubliceerd op de site, of publiceer het e-mailadres van de bezoeker niet. (R-pd.8.19)
Ondanks dat het niet mag: welke hacks/trucjes gebruik jij om e-mailadressen in links "onbereikbaar" te maken voor spambots?
Een probleem met contactformulieren is dat het voor de bezoeker vaak niet duidelijk is naar wie dit formulier verzonden wordt en wat er onder water dus allemaal gebeurt. Hoe ga je om met dit probleem?
Een ander probleem met (contact)formulieren is dat (spam)robots deze ook automatisch invullen, en zo dus alsnog je inbox vervuilen. Ook bij gastenboeken of reactieformulieren komt dit veel voor. Hoe ga je hier mee om?
Reacties
- 1 Sander A op 05-11-2008 om 16:08 uur:
- Afhankelijk van het type site, bv. weblog, vind ik een eenvoudig rekensommetje, of iets vergelijkbaars, wel kunnen als methode om te voorkomen dat spambots je formulier kunnen submitten. Als je vervolgens zorgt dat de som automatische berekend wordt indien JavaScript ondersteund wordt en je verbergt het bewuste veld dan tevens, dan moeten alleen bezoekers die JS disabled hebben het sommetje maken.
Ik heb een kleine 2 jaar geleden eens zo'n scriptje geschreven voor iemand die last had van dergelijke spam en ik hoorde onlangs dat het nog steeds voldoet.
Voor sites van grote organisaties en/of overheid is zo'n extra check natuurlijk not done.
V.w.b. de richtlijnen: ik ben het er helemaal mee eens dat bij een mailto-link altijd het e-mailadres de linktekst moet vormen. Het is erg vervelend als je op iemands naam klikt op zoek naar meer info over de betreffende persoon en dat dan je e-mailclient geopend wordt.
Ook met de regel dat je e-mailadressen van bezoekers niet zomaar publiceert ben ik het geheel eens. Gewoon een kwestie van fatsoen.
Over het verhullen van adressen voor spambots en het toevoegen van extra gegevens, zoals een subject en/of default body tekst, ben ik wat minder stellig. - 2 Harm op 05-11-2008 om 16:56 uur:
- Wat ik soms doe is het e-mailadres 'versleutelen' als htmlentities (&##;).
Ook voor spambots weer te decoden maar toch weer een extra stapje. - 3 Marc op 06-11-2008 om 10:05 uur:
- Over trucs om e-mailadressen te verhullen zijn de richtlijnen heel duidelijk, dus dat kunnen we helaas niet gebruiken. Klanten die de vrijheid hebben om een klein beetje af te wijken van de richtlijnen, willen dat vaak wel op dit punt.
Trucs tegen contact form spam zijn er veel. Wat ik soms doe is een tekstveld toevoegen bovenaan het formulier en dat met CSS verbergen. Een gewone gebruiker zal het niet invullen, een spam bot meestal wel. Maar ook externe services, zoals mollom.com, kunnen goed werken. - 4 Raph de Rooij op 12-11-2008 om 08:25 uur:
- Voor wat betreft webrichtlijn R-pd.8.18: op http://www.opvallendeplanten.nl/contact/ is gebruik gemaakt van een principe dat stamt uit de tijd van de nieuwsgroepen: een door mensen begrijpelijke beschrijving van een e-mailadres. Met JS-ondersteuning ziet het er uit en werkt het als een mailadres-met-link, en zonder leidt het naar een pagina-met-uitleg.
Over deze oplossing en hoe die zich verhoudt tot de Webrichtlijnen is vorig jaar een discussie gevoerd op http://forum.accessibility.nl/viewtopic.php?id=134
De input is overigens gebruikt om de oplossing op punten aan te passen, waaronder de link naar een pagina-met-uitleg.
Strikt formeel is dit niet strijdig met de Webrichtlijnen, maar ik kan we heel wel voorstellen dat niet iedereen het eens is met een oplossing als deze. Dat was ook het doel van de exercitie: de grens opzoeken. Het probleem dat de aanleiding is voor webrichtlijn R-pd.8.18 is immers met de richtlijn niet opgelost. - 5 Kor Dwarshuis op 12-11-2008 om 10:05 uur:
- Hoi Raph,
Ik vroeg me af wat de meerwaarde is van de uitweiding over Javascript die je te zien krijgt als Javascript uitstaat op de opvallendeplantenwebsite.
Als niet-techneut heb je er niets aan, het enige dat je er aan overhoudt, is het gevoel dat je kennelijk iets niet hebt wat je eigenlijk wel moest hebben, "of zo". - 6 Raph de Rooij op 12-11-2008 om 19:54 uur:
- @Kor: De meerwaarde is volledigheid van de boodschap. Maar die informatie is inderdaad niet voor iedereen relevant. Zonder kan het ook; ik heb het daarom aangepast en beperkt tot de instructie.
- 7 Joop op 29-09-2009 om 15:54 uur:
- Een door mij veel geziene oplossing is dat bezoekers een code moeten intikken. Deze code wordt aan de hand van een sleutel gegenereerd die per bezoek wordt aangemaakt. Enkele systemen met gastenboeken werken met deze methode. Het systeem is voor een bezoeker laagdrempelig en de code wordt gepresenteerd in een klein, maar wel goed leesbaar, plaatje. Spamrobots zien wel een plaatje, maar zijn (nog) niet in staat om uit te maken wat in zo'n plaatje wel en niet relevant is. Het enige nadeel aan dit systeem is dat de server ervoor moet worden ingericht c.q. er moet een script draaien met een van de bekende script talen zoals bijvoorbeeld CGI. Een klein en aardig detail kan dan nog zijn dat deze service ook kan worden aangeboden aan gebruikers van het www die geen beschikking hebben over een eigen server. Doel van dit alles is natuurlijk het onmogelijk maken dat spamrobots nog kunnen functioneren. Minder spam betekent minder netwerkverkeer en dat spaart geld.