Antibot blocks multistep webform submission if user fails to move mouse pointer, and all submissions from some assistive technologies

I found additional problems that block disabled users, stemming from the same cause.

1. Screen readers are not reliably detected. Screen reader users can navigate without using the Tab key, and several navigation methods throw no JS events at all. So only meta keys may be received, or it's possible NOTHING will be received other than a click on the "next page" button.
2. Voice control (dictation) users are not detected at all. The first and only event their browser fires is "click" on the next page button, while the form is still locked.

I pulled your patch into an issue fork and added some more:

1. Simple click detection to permit users relying on assistive technologies to submit the form. It's the only event that some browsers are going to fire I'm afraid.
2. Config settings to make the error messages customizable, so that real human users who are blocked for any reason can be given a fallback contact method, such as email or phone.

One possible remaining task...I'm not passing admin-overridden config through translation, as that would strip links. This is not a regression per se as the default is your current text, which is still being translated. Not sure what makes sense there unless someone knows a way to pass user generated content with links through translation -- restricting links, restricting translation, exposing a user preference?

Another way to address the accessibility issue may be to have some sort of "are you a human" field that a user can interact with, and disabling the submit button until the user has passed any tests.

Another way to address the accessibility issue may be to have some sort of "are you a human" field that a user can interact with

This is just captcha though, right? The idea is to avoid having to interact.

I'm adding the target tag to track this one, and I think if we can't resolve it we'll remove the module from Drupal CMS until a solution can be found. It seems like a edge case but it renders the form unusable so it's fairly serious.

Tagging this as a Drupal CMS dependency critical, because it is severe enough that we need to remove Antibot from our dependencies, for now (see #3498392: Remove Antibot module because of unaddressed accessibility issues) until this issue is fixed and in a tagged release of Antibot. :(

@glugmeister @itmaybejj Thanks for using Antibot and working on this issue. Are you still able to reproduce the issue with the latest 2.0.4 release? I created a multi-step web form, followed the steps mentioned in the issue and then used Apple voiceover to make submission and it was not blocked by Antibot. Possible to share any other inputs that might help others reproduce the issue? Thanks.

The solution of allowing clicks and querying the isTrusted attribute can significantly reduce the effectiveness of the module. We have therefore created a new merge request that adds an adjustable time component (default 5 seconds) to the click event.

Please review / feedback.

I tested the original bug regarding the mouse pointer and I got the same error:

I had some issues applying the patch # 3, but It seemed to fix the issue

$ patch -p1 < antibot-issue-3406484-2.patch 
patching file js/antibot.js
Hunk #2 succeeded at 19 (offset 2 lines).
Hunk #3 FAILED at 46.
1 out of 3 hunks FAILED -- saving rejects to file js/antibot.js.rej

I'll look into the accessbility issues now.

I'm using Linux here and the default screen reader that comes with it (Orca) is just a nightmare and I can't submit/navigate the form unless I use the tab and hit enter to submit the form, I believe JAWS has the option to navigate the webform without the tab, I'll ask one of my colleagues who uses Windows if he can do some tests with JAWS.

@danrod: Thank you for testing. The patch antibot-issue-3406484-2.patch you used is almot 13 months old. Please test with current issue fork.

I changed the test to fill in the form data via JS instead of using Mink because Mink simulates the keystroke events.

In general the scope of this issue moved. The webform-bug seems to be fixed without this issue.

Interesting is comment #5 where several new a11y problems are mentioned that call into question the functioning of the module in general for accessibility reasons.

The MR!23 tries to solve this problems and attempts to balance accessibility and spam protection.

For testing you can use the /user/password page without further config (only enable antibot) and I uploaded webform.webform.test_3406484.yml which you may import and use for multi-page webform tests.

I agree the scope has changed somewhat.

I retested the issue after comment #17 and was not able to reproduce the issue with the latest 2.0.4 release using a keyboard only. I haven't been able to test with no keyboard, no mouse movements except a submit button click as my testing screen doesn't support that, I'll try on a larger screen asap.

I will also try to test the MR additions. Thank you

Hello @jan kellermann can you share with me how to use Mink to test this MR? I'm not familiar with Mink and I'ld like to help on this.

Behat/Mink is predefined in Drupals PHPunit-Config. For local testing you need a chromium. We are running this via docker, see here.
See also this pipeline (line 68ff)
See also this commit.

Based on the discussion around the issue during the contribution event, the change can have a major impact on the accessibility, security, and overall working of the module so it will be better to have a separate release at the moment. This will help in gathering more feedback and based on that in the future we can either have one release or multiple releases maintained in parallel. Congratulation

Thank you @gaurav.kapoor , It is a shame that I wasn't able to work on this issue closely, I had some work commitments on the side, but I'll look into the other issues from time to time.

Will the 3.0.x branch have the release with the accessbility features/fixes?

@danrod, no worries, I can take up this one. Plan at the moment is to have fixes from this issue in 3.0.x and a release after some more testing. But we continue to maintain 2.0.x and have a release as well with some of the recent fixes. In future, we can again switch to a single supported release and active development branch.

A client we have is still seeing this on multi-page forms, as regular users, without any assistive technology.

I assume this only happens on subsequent steps. Could we set a flag in local storage or something like once user successfully passed the check and immediately unlock the form for them for any future request, possibly for a given period of time?