Hide Email Address from Bots - Keep mailto:
css, html, mailto, web-crawler
Solution
The issue with your request is specifically the "Supporting screen-readers", as by definition screen readers are a "bot" of some sort. If a screen-reader needs to be able to interpret the email address, then a page-crawler would be able to interpret it as well.
Also, the point of the `mailto` attribute is to be the standard of how to do email addresses on the web. Asking if there is a second way to do that is sort of asking if there is a second standard.
Doing it through scripts will still have the same issue as once the page is loaded, the script would have been run and the email address rendered in the DOM (unless you populate the email address `on click` or something). Either way, screen readers will still have issues with this since it's not already loaded.
Honestly, just get an email service with a half decent spam filter and specify a default subject line that is easy for you to sort in your inbox.
<a href="mailto:no-one@example.com?subject=Something to filter on">Email me</a>
What you're asking for is if the standard has two ways to do something, one for bots and the other for non-bots. The answer is it doesn't, and you have to just fight the bots as best you can.
Problem
tl;dr Hide email address from bots without using scripts and maintain `mailto:` functionality. Method must also support screen-readers. Summary Email obfuscation without using scripts or contact forms Email address needs to be completely visible to human viewers and maintain `mailto:` functionality Email Address must not be in image form. Email address must be "completely" hidden from spam-crawlers and spam-bots and any other harvester type Desired Effect: No scripts, please. There are no scripts used in the project and I'd like to keep it that way. Email address is either displayed on the page or can be easily displayed after some sort of user interaction, like opening a modal. The user can click on on the email address which in turn would trigger the `mailto:` functionality. Clicking the email will open the user's email application. In other words, `mailto:` functionality must work. The email address in not visible or not identified as an email address to bots (This includes the page source) I don't have an inbox that's full of spam What does NOT Work - Adding a contact form - or anything similar - instead of the email address I hate contact forms. I rarely fill up a contact form. If there's no email address, I look for a phone number, and if that's not there, I start looking for an alternative service. I would only fill up a contact form if I absolutely have to. - Replacing the address with an image of the address This creates a HUGE disadvantage to someone using a screenreader (please remember the visually impaired in your future projects) It also removes the `mailto:` functionality unless you make the image clickable and then add the `mailto:` functionality as the `href` for the link, but that defeats the purpose and now the email is visible to bots. What might work: Clever usage of `pseudo-elements` in `CSS` Solutions that make use of `base64` encoding Breaking up the email address and spreading the parts across the document then putting them back together in a modal when the user clicks a button (This will probably involve multiple `CSS` classes and the usage of `anchor tags`) Alterting `html` attributes via `CSS` @MortezaAsadi gracefully brought up the possibility in the comments below. This is the link to the full - The article is from 2012: What if We Could Use CSS to Alter HTML Attributes? - Other creative solutions that are beyond my scope of knowledge. Similar Questions / Fixes - JavaScript: Protect your email address by Joe Maller (This a great fix suggested by Joe Maller, it works well but it's script based. Here's what it looks like; ``` <SCRIPT TYPE="text/javascript"> emailE = 'example.com' emailE = ('yourname' + '@' + emailE) document.write('<A href="mailto:' + emailE + '">' + emailE + '</a>') </script> <NOSCRIPT> Email address protected by JavaScript </NOSCRIPT> ``` Looking for a PHP only email address obfuscator function (A Clever solution using both `PHP` and `CSS` to first reverse the email using PHP then reverse it back with CSS) A very promising solution that Works great! But it's too easy to solve. Is it worth obfuscating email addresses on the web these days? (JavaScript fix) - Best way to obfuscate an e-mail address on a website? The selected answer works. It actually works really well. It involves encoding the email as `html entities`. Can it be improved? Here's what it looks like; ``` <A HREF="mailto: yourname@domain.com"> yourname@domain.com </A> ``` - Does e-mail address obfuscation actually work? (The selected answer to this SuperUser question is great and it presents a study of the amount of spam received by using different obfuscation methods. It seems that manipulating the email address with `CSS` to make it `rtl` does work. This is the same method used in the first question I linked to in this section. I am uncertain what effects adding `mailto:` functionality to the fix would have on the results. - There are also many other questions on SO which all have similar answers. I have not found anything that fits my desired effect The Question: Would it be possible to increase the efficiency (ie as little spam as possible) of the email obfuscation methods above by combining two or more of the fixes (or even adding new fixes) while: A- Maintaining `mailto:` functionality; and B- Supporting screen-readers Many of the answers and comments below pose a very good question while indicating the impossibility of doing this without some sort of `js` The question that's asked/implied is: Why not use `js`? The answer is that I am allergic to `js` Joking aside though, The three main reasons I asked this question are: Contact forms are becoming more and more accepted as a replacement for providing an email address - which they should not. If it can be done without scripting then it should be done without scripting. Curiosity: (as I am in fact using one of the `js` fixes currently) I wanted to see if discussing the matter would lead to a better way of doing it.