I prefer display: none, as it’s more likely to hide it from screen readers too.
However, these days I prefer not to have hidden fields like this, and instead place a timer on the form. Bots will tend to submit the form very quickly, so if you put a hidden timer on the form, it will stop them. Then you don’t risk confusing some of your users.
I didn’t do a scientific comparison to see which was more or less effective. I just think of it as an additional barrier to entry that a spammer or bot would trip up on.
What I basically meant was an input text field (type=“text”, not type=“hidden”) that is simply hidden using display:none. Regular visitors won’t see this field, and thus will never enter anything into. Bots, on the other hand, can’t tell that it’s hidden and tend to enter text into most fields that they can find. So, you’re basically setting a small trap for them, and if they enter any text in that field, the submission is blocked.
I think you have that twisted around - from what I’ve read…
There are two approaches…
1.) Have a Hidden Field that is blank
The goal being that a spam bot won’t notice it is “hidden” and fill it out anyway, thus tripping a flag.
2.) Having a Text Field that is visually hidden which contains a code.
The spam bot will see this, and if it tries to modify the pre-set value in the field, this trips off a flag.
I have heard the combination is good to use, possibly along with a “Time Trap”.
The hidden form field to trap bots is the honeypot. It either has to be left blank or a specific answer needs to be given. Either way, people with CSS off or screen readers may see that input, and they may get confused by it. Display: none gives it a better chance of staying hidden from a screen reader.
IMHO you only need one of these for tripping a bot. I’ve had great results just using a timer. I just had to figure out how to do it. I wrote up the results here: http://pageaffairs.com/notebook/contact-form-honeypots
Bots will tend to submit the form very quickly, so if you put a hidden timer on the form, it will stop them.
Be aware some users (like me) may find that submit dies and we need to refresh the page, while our browser keeps our fields filled in, and we immediately hit submit. So better make that a damn fast timer, because it is possible for a human to “fill out” a form quite fast.
Display: none gives it a better chance of staying hidden from a screen reader.
However traditionally the 2 most popular screen readers ignored display: none precisely when it involves form controls. I have no idea why (old article).
So while I often wiggle between display:none and pulling off-screen, I still always have a label explaining what the user should do. Bots universally don’t understand instructions, though often they know to scan for particular words like “email” to know to fill in something that looks like an email address, etc.
To have a truly hidden field, something you would want sent to the server and never interacted with by the user, input type=“hidden” is for this. For example, we use a hidden input to avoid cross-site scripting; this is default in both our web framework (flask) and others like Django (example, however their HTML example is using display:none unnecessarily. Hidden-type inputs do not appear, whether CSS is on or not (similar to how the <head> does not appear visually whether CSS is enabled or not)).
Whenever they get things straight in the W3C spec, it’s going to be something like, any element with a “hidden” attribute will also by default have “aria-hidden” which does work in latest screen readers. Right now they’re hashing out what happens to stuff like descendents if an ancestor has hidden while descendents have focusable thingies in them.
Regarding the first, it’s also considered a honeypot and decent anti-spam measure to have a visible input where legitimate users must follow some simple directions (do some math, answer if fire is hot, count kittens, that sort of thing). So this type of honeypot is often called a CAPTCHA because many people think it can tell humans from robots, but because it “catches” things (either positive or negative) it would also be a honeypot. The “simple directions” may simply be a visible input with a label asking “are you a robot? if not, leave this blank”.
Of course bots should be excellent at simple math, but more often than not spambot-builders aren’t adding this functionality in, so it still works. No calculus please and no weird questions with double or triple negatives; we’re trying to determine the user is legit, not that they’re a super genius. If dumb people like me with dyscalculia are considered legit users, then we need to be able to answer the questions easily.
Also if someone is filling out a form and are in the rhythm of answering everything, people may fill out “no” to the input they are supposed to leave blank, which is why visible inputs asking not to be filled in are much, much less common (or messed with Javascript when user hits submit). Where I give blood, they always have a series of questions only for men, only for women, only for pregnant women and only for people over age 65. Yet I know many people continue filling these sections out as well (simply answering “no” to everything) because humans suck at context switching I guess. Take that however you will.
My Registration Form has 7 required fields, and I have “Remember search and form history” checked in FireFox, so when I test my form I just have to type the first letter (e.g. “D” for “DoubleDee”), and the value is there, and so I can complete the Form pretty darn quick with no real typing, and I think it still takes me like 15 seconds to complete things. (Having to enter a Password that is 8-40 characters with One Upper, One Lower, One Number, and One Special Character adds LOTS of time to even “speed demons” like you…)
I am thinking anything under 10 seconds is a bot for my form.
Good to know!
I think having one Type=“Hidden” along with a Timer is probably sufficient for now.
Researching this topic I see LOTS of people misusing and misunderstanding what CAPTCHA is.
First off, it is an acronym! It stands for “Completely Automated Public Turing test to tell Computers and Humans Apart” which is a trademark for Carnegie Mellon University.
It has nothing to do with “capturing” anything…
Secondly, CAPTCHA is not the appropriate name for things like “Logic Questions” (e.g. “What color is grass?”) or for “Honeypots”.
Ummmm… The reason for “Logic Questions” and “Honeypots” and TImers and so on, is to avoid needing to use a CAPTCHA!!!
If I used “Logic Questions”, I’d go with…
1.) How much $$$ is in your bank account?
2.) How much available credit do you currently have on your credit card?
3.) Do you have your husband’s (wife’s) permission to make “splurge” buying decisions?
(If the $$$ amounts won’t help me hit my targeted Quarterly Earnings, or if there is a b i t c h y spouse involved, then you cannot register on my website!!!)
:vsmiley: :angel6:
It takes me a lot less than 10 seconds to hit “refresh” in my browser and then “submit”. All I’m saying.
I’m quite aware of what CAPTCHA means. This is what I said
A “is fire hot?” question (popular with forms like Mike Cherim’s) is considered a CAPTCHA because people believe (and there is very strong emphasis on the word “believe” here) that these kinds of questions can tell a human from a robot. I have two problems with this:
it can’t. While teaching a robot to speak a natural language is hard, it’s not impossible. Plus, I believe the Chinese Room thought experiment shows that it is theoretically impossible to tell the difference between “having an exquisite number of instructions for any possible input” and actually understanding. Sex chat bots and help desk “people” show it may just not matter. Obligatory XKCD post.
We Don’t Care If The User Is Human Or Computer. We only care that it is a legitimate user, a user we want. Sometimes we want a human user. Sometimes we want a program. Sometimes we only want humans who speak our natural language and have a mental capacity to leave comments better than “LOL”.
Reason #2 is why I always hate CAPTCHAs. Because a CAPTCHA is looking for something we don’t care about: whether the user can sweat or not. That should rarely if ever be a criteria. Mechanical Turks sweat, but they just spam or let in spam bots.
But honeypot does. It’s full of honey, and catches bees and flies. And Poohbears. And whatever else. My comment above was explaining that honeypots are sometimes called CAPTCHAs because people believe that honeypots can tell humans from computers; that it will “catch” the bots and not the humans, or “catch” the humans and not the bots.
Hm, I think people are most likely to lie here, while bots will either leave these blank, fill with garbage or maybe figure out the questions (because there are monetary units in it) want numerical answers. Though whomever makes a bot that can do that deserves to get some spam in
I dunno what they do, actually. The cross-site-scripting tokens are always compared with a similar token on the server, so I suppose if the bot changed the value there somehow, it would then still fail.