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