Gravity Forms 3.1.0.3 fixes an issue where the Datepicker field F1 key and keyboard navigation did not work properly. Earlier 3.1 patches also address minimum and maximum dates being overwritten. A mouse click can pass while keyboard users lose focus, hear the wrong date, cross a disabled boundary, or submit a manually typed date that the server parses differently. The regression fixture should include help, arrow movement, month boundaries, constrained dates, manual entry, validation failure, AJAX redraw, and mobile input.
Use this for booking, appointment, application, delivery, birth date, and event forms where keyboard access or min and max rules matter.
Quick answer
Install the current Gravity Forms 3.1 patch, focus the Date field without a mouse, open the picker, invoke F1 help, move by day and week, cross month and year boundaries, test disabled minimum and maximum dates, select and submit, then repeat after validation failure and an AJAX page change. Compare the visible date, hidden or submitted value, server validation, stored entry, notification, and downstream date format.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| F1 help | Picker open with keyboard | Help is announced and focus remains usable |
| Min and max | Boundary and blocked dates | Constraints remain intact |
| Validation retry | Other field fails | Date and focus survive |
| AJAX page | Navigate away and back | One initialized picker |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Document the date contract | Record date format, first day of week, locale, minimum, maximum, default date, manual-entry mask, conditional logic, AJAX, and any custom datepicker hooks. | F1 help and keyboard navigation work without trapping or losing focus. |
| Update to the current 3.1 patch | Test Tab, Shift Tab, Enter, Escape, F1, arrow keys, Page Up, Page Down, Home, End, and focus return using the actual supported keyboard contract. | Minimum and maximum dates remain enforced after every render and retry. |
| Run the keyboard and boundary matrix | Exercise allowed and blocked dates at both boundaries, leap day, month and year transitions, typed input, paste, mobile picker, and browser autofill. | One picker instance exists after AJAX or conditional display changes. |
| Remove stale hooks or duplicate initialization | Trigger another field validation error and an AJAX page transition, then confirm the picker reopens once with the same constraints and no duplicate handlers. | Entry, notification, calendar, and CRM dates match the documented canonical value. |
What to check first
- Record date format, first day of week, locale, minimum, maximum, default date, manual-entry mask, conditional logic, AJAX, and any custom datepicker hooks.
- Test Tab, Shift Tab, Enter, Escape, F1, arrow keys, Page Up, Page Down, Home, End, and focus return using the actual supported keyboard contract.
- Exercise allowed and blocked dates at both boundaries, leap day, month and year transitions, typed input, paste, mobile picker, and browser autofill.
- Trigger another field validation error and an AJAX page transition, then confirm the picker reopens once with the same constraints and no duplicate handlers.
- Reconcile the displayed date, submitted value, PHP validation, entry value, merge tag, email, calendar feed, and CRM field.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because cache purges, retries, scheduled actions, and deployments can change the evidence between tests.
- Test the public browser path and the server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, stored record, logs, and relevant downstream system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
form_id=17
field_id=8
locale=en-US
week_starts_on=1
min=2026-09-01
max=2026-12-31
f1_help=pass
keyboard_select=pass
stored_date=2026-09-14
Why this usually happens
- A new accessible datepicker has different focus and help behavior than the previous jQuery implementation.
- Custom code mutates date options after Gravity Forms applies min or max constraints.
- AJAX rendering initializes the field twice or fails to restore the keyboard listener.
- Browser display format and server parsing expect different locale or separator rules.
Decision rule
A datepicker passes only when keyboard, screen-reader, typed, mobile, and server-side paths select the same permitted date and return focus predictably after close or validation.
Production verification checklist
- F1 help and keyboard navigation work without trapping or losing focus.
- Minimum and maximum dates remain enforced after every render and retry.
- One picker instance exists after AJAX or conditional display changes.
- Entry, notification, calendar, and CRM dates match the documented canonical value.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Document the date contract
- Update to the current 3.1 patch
- Run the keyboard and boundary matrix
- Remove stale hooks or duplicate initialization
- Verify stored and downstream dates
Mistakes to avoid
- Changing production code, cache settings, form fields, webhook endpoints, or firewall rules before preserving the exact failure, current versions, and rollback point.
- Treating one successful page load or dashboard status as proof while browser behavior, PHP logs, scheduled jobs, delivery records, and downstream data remain unchecked.
- Testing a different role, device, locale, form, URL, order state, cache state, or plugin combination than the workflow that users actually reach.
- Leaving helper plugins, debug logging, copied secrets, broad exclusions, temporary endpoints, or test notifications active after the verification window.
Questions teams ask during testing
Can I run this directly on production?
Begin with read-only checks and preserve evidence. Use staging for changes that affect PHP, cache generation, form submission, payment, email, or customer state. When production is necessary, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Match the exact plugin and WordPress versions, URL, role, device, locale, cache state, and integration path. Repeat the same fixture before and after the change, then compare stored evidence rather than relying on memory.
What evidence should I keep?
Keep UTC time, versions, affected URL or record ID, expected result, actual result, relevant log lines, configuration snapshot, change made, rollback point, and final verification. Remove credentials, payment details, and personal data.
When should I bring in a specialist?
Escalate when the site is unavailable, checkout or lead capture is affected, a security boundary is unclear, several systems disagree, or the next step could destroy evidence. A concise incident packet makes outside help much faster.
What to tell the client or owner
Give the owner a short evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected and actual result, key logs, the change made, rollback point, final result, owner, and next review date. Redact credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP repair the Gravity Forms datepicker regression.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references