I haven't used a screen reader, nor have I looked at their source code, but it did make me wonder if such a setup (with user invisible fields) might still be read by the screen readers (depending on how they convert the raw html into content for the listener).
If I ever get around to fixing my comment system on my blog (I don't really like comments... and thats probably why my current commenting system is passive-aggressive), I'll try implementing these ideas. Good link.
I have played with captchas a bit and I think its important to make captchas which rely on thinking and comprehending, not on some facet where human senses are still more acute than electronic sensors (this is a deadend, as computer cycles get cheaper and algorithms improve I don't really believe that human senses will be superior to dedicated electronic ones in well... anything).
My favorite captcha (perhaps my own idea, not quite sure though) is to have something like this "Please enter the missing item: 532 533 534 535 536". This satisfies my requires for a 'fair' captcha: 1. it is delivery neutral (a screen reader, a blind individual, or a fully healthy individual can all understand this captcha), and 2. It is relatively resistant to brute force because the question doesn't contain the answer.
As is stands, the vast majority of captcha implementations are discriminatory (you need to, at minimum, have a choice between an audio and a visual captcha, or use a captcha that is delivery neutral).
The best way to avoid needing a captcha is to build a non-consistent UI (which is to say, to differentiate yourself, hopefully by making it better) that the existing spam algorithms won't recognize. Much like diverse genetics give species resistance to disease, diverse design and UIs give the internet resistance to spam.
By non-consistent UI I mean breaking the "Name, Email, Webpage, Body" paradigm. I think a good (although certainly harder to implement) example of this is http://www.djangobook.com/en/beta/chapter01/ . If you click on the little tabs/indexes on the side of the page a little comment box pops up that is relevant to the specific position. This UI is sufficiently different from a standard commenting system that a standard form filling spambot would be clueless. This is only an example, but perhaps it helps explain my idea of diversifying a bit. Other types of spam bots would not be affected, but perhaps similar changes would make them less effective as well (your example of using Ajax is a good possible example).
Picture matching is a viable alternative and can reduce cog load, but it also increases the time between captcha and the intended action. I use a 3-character captcha. We'll see how that holds.
I think the point is not which modification I made - nothing that was much different from some other usual spam-prevention mods which are in use. The trick is that no spammer cares about a single site enough to work around a custom solution.
Of course, the only thing you really care about when someone/thing does a captcha is that the, uh, thing won't spam and that it will give you money. This problem might go away if someone succeeds in designing a system for making micropayments with a much smaller granularity than Paypal.
Face detection is a solved problem, and accessing webcams from a browser is solved. http://www.merl.com/projects/FaceRecognition/ http://youtube.com/my_videos_upload
If I weren't busy with another idea, I would suggest someone work on this. It could also be used for a secure login if done with face recognition, which is fast maturing.
Repetitive captcha tests can be avoided if your application limits the frequenzy of submissions made . But this in turn is a larger annoyance for commenting systems.
1. A flower from your sweetheart?
2. A warm puppy?
3. A properly formatted data file?
ANSWER!
http://oltsm.blogspot.com/2007/06/ra-captcha-idea-for-ajax-b...