Hacker News Reader

Comment by tpetry | Hacker News Reader

For bots which are not specifically targeted at your page i simply add an invisible form element named url. Bots _LOVE_ to share their viagra urls. Any request which submitted an url is discarded.

This trick is simple stupid and should not work but somehow the simple spam bots have not improved.

This does not work for sophisticated bots (never met one) or the ones programmed specifically for your site (happens very rarely).

View on HN

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.

There are lots of options for automated accessibility scans, but there are many common accessibility issues that aren't feasible to test for with automation.

My team at Microsoft recently open sourced a tool called Accessibility Insights (https://accessibilityinsights.io). The web version is a chromium extension that includes both automated scans and also a guided assessment option that leads you through how to test for and fix the stuff that has to be found manually. This is the tool Microsoft pushes its own teams to use as part of their release processes.

Simply try to browse the page without using mouse, just the tab key. The next step would be to use screen reader, NVDA[1] (Windows) or Apple VoiceOver (MacOS). There are automated testing tools, but they don't cover the whole spectrum of problems. Nevertheless you can try

* 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)

Please do the tab test. Some of us do this even if we don't need accessibility tools, as it can be faster (those who create forms which cannot be tabbed through are evil).

Everything everyone else has said. However, if you don't have a budget for this, you can do a few basic things that will greatly improve the usability of your site.

First, can you navigate your entire site without using a mouse (including any widgets, forms, embeded stuff)? You should also have a "Skip to main content" button that is the first element you hit when you tab into your page.

Next, download the NVDA screen reader, which is free, turn off your monitor (or close your eyes), and navigate your site using it. I recommend using FireFox for this.

Finally, use a color contrast analyzer plugin for your browser to ensure you have enough contrast between all of you elements.

From there, you can review the WCAG 2.0 spec to get into the fine details. If you have the budget, hire a consultant/contractor. What I described above doesn't make your site pleasent to use for a disable person, just usable.

Surprised no one has mentioned this yet, but pa11y was what a large enterprisey company I used to work at tried to adhere to. http://pa11y.org/

You can switch any iPhone to accessibility mode. Those with vision impairments love their iPhone because generally "it just works"

I couldn't find anything like it, which surprises me. It should be in the interest of companies selling screenreaders that the web is accessible with them. Creating a service where you can submit a link and it shows you a textual representation of how the screenreader sees the page would be immensely useful.

uh, there are a lot of services that do automated scans. These obviously arent completely failsafe, but still give an indicator.

just google relevant keywords https://www.google.com/search?q=accessibility+scan+website

and if you want the full experience: just enable the screen reader and try to use your website with it.

/edit: and i almost forgot: chromes build-in Audit tool in the Developer Panel includes some Accessibility tests as well

These scans are in my experience always just that: they read the source and match it against a set of common anti-patterns. I was talking about something that would tell me how common commercial screen readers interpret an arbitrary new construct. If you have a specific reference to something else, please send me a link!

Screen readers often cost significant amounts of money, and are not trivial to "just turn on".

I believe y4mi was referring to screen reading software, not a physical device. Like VoiceOver on macOS.

You could start here: https://www.w3.org/standards/webdesign/accessibility

I'm sorry - did I offend someone. Or did limited mobility cause a click on the fiddly and untitled downvote link instead of following the link :-)

We do this, but we've labeled our field very explicitly with something along the lines of "Please leave this field blank, it is for SPAM control.". We also provide a hidden error message if it is filled in to alert the user that it really should be blank.

It's also always place this field after the Submit button with the idea that a user with a screen reader would never make it that far. Bots still see it and add it to the post request since I don't think they care about the order of the form fields.

But then what if you disabled CSS or use Lynx? (You should also add text next to it to say don't use it, and hide that text as well sa the form field. Then, if the form field is visible for any reason, the user will know not to use it.) (Using scripts for it also applies, if you have scripts disabled or are using Lynx or something that does not implement JavaScripts.)

Can confirm, formerly used a spin of this technique and had to stop to better support blind users.

I've used this technique with a label that said "Leave Blank", also hidden with CSS. Seemed to work great, but now I wonder.

I wonder if using aria-hidden on the input field would work or if the bots would also ignore it.

On the face of it this looks like an issue with screen-readers reading the page simplistically.

An element that is not displayed should not be 'displayed' by screen-readers either.

It's been a couple years since I've implemented one of these, but I've used this method in various forms on projects for at least a decade. Sometimes I use a hidden "email" field. Sometimes a hidden "subject" field. Hadn't thought of a "url" field, which is a great idea.

It works surprisingly well.

> This does not work for sophisticated bots (never met one)

The basic prerogative of a sophisticated bot is to ensure you believe that.

Having written a variety of sophisticated bots - some from pre-existing libraries, others from scratch; for specific websites and for general purpose - I'm reasonably confident most people who think they've never seen a sophisticated bot are mistaken.

I agree with you that anything more sophisticated or bespoke than a mass-spam bot is rare. But rare things happen often to most websites with nontrivial traffic. The types of bots with the most funding and skill behind them are the ones which don't try to spam anything on a website at all.

But this is good enough in many cases. It's intended to reduce the volume of input from a form in order to prevent overloading human resources at the next level of filtering. If one or two bots per week get through, it isn't a big deal. Not only are the more sophisticated bots less common, they also tend to not send a bunch of messages.

So if you have a contact form, this simple method may reduce the spam content to a low enough level that the effort to implement some type of third-party service is not necessary. There is not enough incentive for someone to target the form directly.

In addition, the captcha service may actually deter real submissions, whereas this is completely invisible to non-bots.

If you have a form that has a greater incentive for bots to abuse, then you need something more sophisticated.

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

Are most websites run by businesses which employ 15 or more full-time employees?

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...

Whoa, it is actually illegal to make "not accessible" websites?

In the US, it is if you're an incorporated business serving as a "public accommodation" as defined in the Americans with Disabilities Act, which includes hotels, restaurants, theaters, storefronts. If it is just your personal blog, it doesn't apply. It is the same law that requires storefronts to have wheelchair ramps, but not homes. See Gil v. Winn-Dixie: https://scholar.google.com/scholar_case?case=674450226911160...

More than that; as someone else linked [1], if you're in a business employing at least 15 people (more than half the year), you are also required to have your site be accessible. You don't have to be serving as a public accommodation, for that.

[1] https://www.businessnewsdaily.com/10900-ada-website-requirem...

https://www.section508.gov/manage/laws-and-policies

They even have a compliance tester.

Yeah it's been the only way to make sure people with disabilities aren't left behind.

Ontario, Canada has a similar (maybe a bit more relaxed) law: https://www.ontario.ca/page/how-make-websites-accessible

Awesome! Love a good Ruby solution. Please keep these coming :)

A similar tactic I have is to just require JS to submit a form. Sorry noscript users.

That said, we encounter many sophisticated bots and also a decent number of what I'm pretty sure are real people in low-wage countries pasting data into forms. That last one is tough.

This is simple form of a honeypot but it is really ineffective. Any bot with even minimal sophistication will know to leave the hidden field empty.

I agree that it's possible - potentially trivial - for a bot to figure out if a field is hidden from view, but "really ineffective" seems a bit extreme for something I've seen work well multiple times.

It's not a definitive solution, but it's an easy and practically free first line of defense for a young project, and depending on the project, can stand for years.

Overall, it depends on the sophistication of the bots your project attracts.

You hide it with CSS, not type='hidden'

So now you're filtering out bots and people with disabilities?

Nope, screen readers (usually?) ignore elements with "display: none".

To be sure, you could add aria-hidden="true", which I'd guess most bots don't recognize.

http://alistapart.com/article/now-you-see-me/

Many don't just use display:none but position text off-screen or make it tiny or use sizing and overflow:hidden. I've seen a blind user be tripped up by these, so yes, it often also filters out disabled users.

Many people use tools incorrectly, that doesn't mean you shouldn't use those tools, you just have to be aware of the problem, which everyone in this (sub)thread now is.

A decent screen reader will look at the final rendered Dom and obviously cull items off-screen, the same colour as the background, or 1px high.

If it doesn't, its a bug in the screen reader.

There's quite clear standards on how screen readers are expected to interact with the DOM. What you claim is in none of them, and the techniques you mention are explicitly mentioned as something authors of webpages should avoid/mark up correctly for screenreaders.

No such screen reader exists, so you could claim it's a bug in all of them, but it's not a useful position to take. Screen readers are tricky enough to write without having to second-guess people who are trying to hide-but-not-hide text.

Unfortunately I've not given thought to people with disabilities in this case. It's an oversight and that's on me.

I wonder if bots are smart enough to figure out aria-hidden="true". Possibly empty it out using javascript on submit. I would guess a bot not using CSS would also not be using javascript? Unsure, would need testing.

Could we just tell the people with screen readers to ignore it?

As a fallback I imagine so yeah. I'm trying to think about what would be going on at the time, wondering if unexpected instructions inside a form would be confusing.

Disclaimer: I don't know how a screenreader would present this, example only

"Form entry. Input name. Input email. Ignore this field it's for spambots. Input url. Submit" -- In this case does the message more naturally apply to email or url? I'd imagine there'd be a pause after input email (to wait for the input)? I need to set up a screen reader :)

And then hide the warning using CSS too, so it gets picked up by screen readers just like the hidden input!

Should we put the onus on screen readers to not read elements that would not be displayed when the page is rendered in a browser??

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.

You can set placeholder with something like "leave it empty".

It really doesn't matter. display:none or position:absolute;left:-1000px makes little difference. Honey pots only catch a small number of bots.

I just removed Google's ReCaptcha for a honeypot solution with an additional name and url field. But there's also a timer which checks how long it takes you to submit the form. If you can fill out everything in <2s, you're most likely not human. I have to figure out how people with disabilities can use the page though. Good to get a reminder here. So far it performs way better than ReCaptcha, I haven't received any spam so far and plenty of ham of course. No human complaints either.

A timer is a novel idea. I hadn't seen that suggested before.

Do you anticipate any problems with form auto-filling tools?

I only have anecdata of course but so far I've had a 100% success rate. I imagine this will come down eventually but for the past ~year or so it's been working fine to just hide the honeypot field with CSS

I'm glad it's worked for one of us at least.

I don't know if it helps any but I've been using a field that looks real.

Depending on where it is the name= would be surname (where the form submission has a name field rather than a first name surname split), website, url, etc

You can still figure out it's hidden.

Sure but the point is that almost nobody does.

Another interesting approach is to include an input which is not visible: due to `visibility:hidden`, due to being positioned well off-screen (`left: -10000px`), read-only, set unfocusable by keyboard (`tabindex="-1"`), etc.

Ideally it would have a varying id / name and a varying ARIA attribute for blind users, saying something like "human users, please ignore this".

It would not stop a really sophisticated bot that runs an actual browser and uses machine vision to detect page elements. But unless your site is very high-profile, running such a sophisticated bot to defeat its protections likely won't be profitable.

Honeypots are the best. It will filter out at least 90% of the spam (or so I have experienced everywhere I have implemented them).

Reply on news.ycombinator.com