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

I noticed a comment typo in the first patch uploaded. Here's another one.

I also didn't explain all the changes I have made in this patch.

The original JS had event listeners to detect humans for mousemove, touchmove and keydown (with a further check that key pressed was tab or enter). The patch changes mousemove to pointermove and adds an additional listener for pointerdown so that if a user clicks submit without mouse movement, the mouse click is detected and antibot protection on the form is unlocked and submission proceeds.

Pointermove and pointerdown events cover both mouse and touch input events. So there is no need for a separate touchmove event listener and it is removed.

In relation to the keydown event, I have removed the check for tab or enter keys because it is possible for keyboard users to use space to activate a button. I then thought why not allow any key press to detect a human?

I have added an additional check for all event listeners to check the Event.isTrusted property is set to true. The browser sets this when an event is triggered by a user as opposed to being triggered programmatically by Javascript. In theory, I was thinking this would be a good extra check to prevent form submissions by more sophisticated bots using a headless browser (with Javascript enabled) to simulate mouse, touch or keyboard events. I have not tested this theory though ...

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 before other than a click on the "next page" button.
2. Voice control (dictation) users are not detected at all. The first event their browser fires is "click" on the submit button.

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.