111–120 of 207 posts
Earlier quoted context omitted.
You hide it with CSS, not type='hidden'
So now you're filtering out bots and people with disabilities?
Admittedly, I am not familiar with screen reader standards, but my gut feeling is that they are doing their users a disservice if they are not representing what browser users are seeing as similarly as possible.
Earlier quoted context omitted.
Are there tools or guides to help test how websites "appear" to people with disabilities ? It is difficult to design something if you don't have an idea of what will be the outcome, but I wouldn't know which software is used by (e.g.) a blind user, let alone how I would use it.
You could start here: https://www.w3.org/standards/webdesign/accessibility
Earlier quoted context omitted.
Be very careful how you do this, unless you want to exclude blind users. I've seen a blind user have an online form silently fail at them because they filled in a field that wasn't visible. Using display:none applied indirectly via CSS is probably reasonably effective against bots and won't interfere with screen-readers.
Are there tools or guides to help test how websites "appear" to people with disabilities ? It is difficult to design something if you don't have an idea of what will be the outcome, but I wouldn't know which software is used by (e.g.) a blind user, let alone how I would use it.
* WAVE (Chrome or FF plugin, https://wave.webaim.org/extension/)
* AXE (https://www.deque.com/axe/)
* AChecker (https://achecker.us/checker/index.php)
* Funkify (Chrome plugin, tries to emulate various disabilities)
* Lighthouse in Chrome Dev Tools also checks some accessibility rules
The full list of things that you need to take care of: https://www.w3.org/TR/WCAG21/ (it's huge I know, it takes 5-7 days to test everything from this list)
W3C has published an extensive list of reCAPTCHA alternatives: https://www.w3.org/TR/turingtest/ W3C is requesting feedback for the document, if you'd like to make suggestions, please open an issue: https://github.com/w3c/apa/issues
That's a very informative document. Privacy Pass caught my eye: https://privacypass.github.io/ It's an extension that is currently only supported by Cloudflare's CAPTCHA, that pretty much stores tokens after you complete a CAPTCHA, and the next time instead of requiring you to complete a CAPTCHA again, it will use those tokens. The point is that it does it in an anonymity preserving way. You can fork their server for…
Earlier quoted context omitted.
If you work in the Ruby ecosystem at all, there is a gem called invisible_captcha that does just this. It beat back most of the bot signups we were getting, though some still slip through occasionally. https://github.com/markets/invisible_captcha
Note that that library is not accessible and is hence illegal to use for most websites in the US. I've raised an issue on the project [1]. [1] https://github.com/markets/invisible_captcha/issues/52
To be illegal the website must be run by a business which employs 15 or more full-time employees. Or the business is some form of public accommodation like a hotel. From what I have read.
Of course it would be better to make sure the website is accessible, but I'm mostly commenting on the statement that it is illegal.
https://www.businessnewsdaily.com/10900-ada-website-requirem...
Fingerprinting users is no more a problem than using cookies, there are far more legitimate reasons to use these things than illegitimate. The problem is Google and Facebook using these techniques to spy on people at massive scale.
Once again the problem is Google and Facebook not the internet.
Earlier quoted context omitted.
You could use JavaScript cryptocurrency mining instead. User clicks a button to activate miner script, it runs in their browser for 10-30 seconds or whatever, then reports back to your server that they are good to go.
There are torrent sites that do this already (not as spam prevention, just to generate money). It's pretty annoying but I guess for spam prevention you could make the length of time shorter.
Since I'm also generally against javascript, ideally the code would open-source and it could be verified that it doesn't do anything malicious...
> nobody in their right mind should add a script that fingerprints users Fingerprinting users is no more a problem than using cookies, there are far more legitimate reasons to use these things than illegitimate. The problem is Google and Facebook using these techniques to spy on people at massive scale. Once again the problem is Google and Facebook not the internet.
A text-based challenge-response captcha doesn't fingerprint you in any way. Google's reCaptcha does -- not to mention that it uses you for free labour that I would argue should be a violation of minimum wage laws in most countries (Google hires people to do data entry for ML, so why am I being forced to do the same work for free in order to post a comment on a forum or log into a website).
Earlier quoted context omitted.
That's a very informative document. Privacy Pass caught my eye: https://privacypass.github.io/ It's an extension that is currently only supported by Cloudflare's CAPTCHA, that pretty much stores tokens after you complete a CAPTCHA, and the next time instead of requiring you to complete a CAPTCHA again, it will use those tokens. The point is that it does it in an anonymity preserving way. You can fork their server for…
So now the spammers only need to solve one captcha?
Earlier quoted context omitted.
Note that that library is not accessible and is hence illegal to use for most websites in the US. I've raised an issue on the project [1]. [1] https://github.com/markets/invisible_captcha/issues/52
Whoa, it is actually illegal to make "not accessible" websites?