Score-based reCAPTCHA tokens expire after a short period, while keyboard, screen-reader, speech-input, cognitive, and zoom users may need longer to complete a form. A generic validation failure without field-level errors can trap focus, lose multipage data, or invite repeated submissions.
Use this for long applications, quote forms, donation forms, checkout-related forms, multipage surveys, file uploads, conditional logic, and any Gravity Forms workflow protected by score-based or checkbox reCAPTCHA.
Quick answer
Complete the form with keyboard, screen reader, 200 and 400 percent zoom, speech input, and a deliberate delay beyond token validity. On failure, the summary must be announced, focus must move predictably, entered values and files must follow policy, a fresh token must be obtained, and one final entry must be created.
What to check first
- Record form version, reCAPTCHA type, key type, add-on version, cache and script optimization, page count, conditional logic, file fields, save-and-continue, and AJAX state.
- Run keyboard-only, VoiceOver or NVDA, zoom, reflow, speech input, reduced motion, and slow-entry journeys with a fixed test dataset.
- Delay before first submit and between multipage steps, then capture token age, network requests, validation summary, ARIA live behavior, focus target, and preserved fields.
- Exercise client validation, server validation, back navigation, retry, double activation, and a transient reCAPTCHA service or network failure.
- Confirm one entry, one set of feeds and notifications, correct spam status, no abandoned upload leakage, and a useful accessible error message.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define accessible test journeys | Record form version, reCAPTCHA type, key type, add-on version, cache and script optimization, page count, conditional logic, file fields, save-and-continue, and AJAX state. | Validation feedback is announced and receives predictable focus. |
| Capture token and focus behavior | Run keyboard-only, VoiceOver or NVDA, zoom, reflow, speech input, reduced motion, and slow-entry journeys with a fixed test dataset. | Entered values and approved file state survive the retry. |
| Preserve allowed form state | Delay before first submit and between multipage steps, then capture token age, network requests, validation summary, ARIA live behavior, focus target, and preserved fields. | A fresh token is requested without requiring a page reload. |
| Refresh and retry once safely | Exercise client validation, server validation, back navigation, retry, double activation, and a transient reCAPTCHA service or network failure. | Exactly one entry, notification set, and feed run are created. |
Why this usually happens
- Token lifetime can be shorter than a real completion session.
- A score-based failure may not belong to a visible form field.
- AJAX replacement can remove the live region or reset focus.
- A retry can resubmit feeds even when the first response was lost.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
journey: screen_reader_slow_entry
elapsed_seconds: 310
first_token_state: expired
error_summary_announced: true
focus_target: validation_summary
fields_preserved: 22/22
file_policy: retained_for_retry
refreshed_token: valid
entries_created: 1
notifications_sent: 1
result: pass
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Define accessible test journeys
- Capture token and focus behavior
- Preserve allowed form state
- Refresh and retry once safely
- Verify entry, feeds, and announcements
Decision rule
Pass when every assistive journey can understand and recover from token failure without losing allowed data, focus remains predictable, a fresh token is used, and exactly one entry and downstream workflow complete.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Validation feedback is announced and receives predictable focus.
- Entered values and approved file state survive the retry.
- A fresh token is requested without requiring a page reload.
- Exactly one entry, notification set, and feed run are created.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, or delayed background work.
- Do not paste secrets, personal data, or complete production payloads into tickets or screenshots.
- Do not close the test until the final user-visible state and server-side evidence agree.
Questions teams ask during testing
Should the form automatically resubmit after refreshing a token?
Only if the user remains informed and duplicate protection is reliable. A clear retry action is often easier to verify and understand.
Is legacy reCAPTCHA v2 a better accessibility fallback?
Gravity Forms notes that the legacy CAPTCHA field can introduce accessibility issues. Test the current supported options against real user journeys.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, test Gravity Forms accessible spam recovery.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Extend the Gravity Forms 3.0 accessibility and spam review
Run the Gravity Forms 3.0 accessibility regression checklist for keyboard, screen reader, focus, errors, zoom, phone, and date tasks. If valid users are still classified as spam, use the Gravity Forms 3.0 honeypot and token compatibility test.
Helpful references