Gravity Forms 3.0 enables accessible settings by default for new forms and changes datepicker, button, choice, phone, consent, quantity, total, heading, and error behavior. These improvements reduce common barriers, but they cannot predict custom theme CSS, translated labels, JavaScript replacements, multi-page logic, third-party add-ons, or an existing form created under older settings. A form can pass an automated scan and still trap keyboard focus, announce errors poorly, hide a required indicator, or present a datepicker that is difficult to operate. The regression check needs both automated evidence and a short manual task flow.
Use this after a Gravity Forms 3.0 update, when creating a new form from the accessible defaults, or before claiming that a lead or payment form meets a WCAG target.
Quick answer
Choose the critical forms and run them with keyboard only, screen reader, 200 percent zoom, narrow viewport, high contrast, errors, conditional fields, datepicker, phone country search, and multi-page navigation. Check labels, instructions, required state, error summary, focus movement, button names, choice controls, totals, consent, and confirmation. Automated tools are useful for repeatable defects, but manual completion is required to verify the task actually works.
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 |
|---|
| Keyboard | Invalid multi-page form | Focus reaches first error |
| Screen reader | Phone and date fields | Labels and results announced |
| Zoom and reflow | 200 percent and mobile | No clipped controls |
| Automated scan | Known pages | Findings manually confirmed |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Select critical user tasks | Record form version, theme, embed method, accessible setting state, locale, viewport, browser, assistive technology, and any custom field templates. | A keyboard and screen-reader user can understand, complete, correct, and submit each critical form. |
| Run keyboard and screen-reader fixtures | Complete every form with keyboard only, including invalid submission, first error, conditional fields, datepicker, phone country search, file upload, multi-page controls, and final confirmation. | Focus order, visible focus, labels, errors, announcements, headings, buttons, and conditional content are coherent. |
| Confirm automated findings manually | Inspect programmatic labels, fieldset and legend structure, descriptions, required state, live announcements, error summary links, focus indicators, heading order, and button names. | The form reflows at zoom and mobile sizes without clipped text or unreachable controls. |
| Fix theme and field boundaries | Test zoom, reflow, contrast, reduced motion, touch targets, autocomplete purpose, timeout behavior, and screen-reader reading order in the real page layout. | Regression fixtures are attached to future Gravity Forms, theme, and add-on updates. |
What to check first
- Record form version, theme, embed method, accessible setting state, locale, viewport, browser, assistive technology, and any custom field templates.
- Complete every form with keyboard only, including invalid submission, first error, conditional fields, datepicker, phone country search, file upload, multi-page controls, and final confirmation.
- Inspect programmatic labels, fieldset and legend structure, descriptions, required state, live announcements, error summary links, focus indicators, heading order, and button names.
- Test zoom, reflow, contrast, reduced motion, touch targets, autocomplete purpose, timeout behavior, and screen-reader reading order in the real page layout.
- Log each barrier with a repeatable step, affected user task, severity, selector or field ID, owner, fix, regression test, and verification date.
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 a cache purge, scheduled action, retry, or deployment can change the evidence between tests.
- Test the real browser and downstream record, not only an admin preview or isolated API call.
- Close the task only after the public workflow, server-side record, and relevant delivery or analytics 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
version=3.0.3
fixture=invalid-multipage
keyboard=pass
screen_reader=review
zoom_200=pass
first_error_focus=pass
owner=accessibility-qa
Why this usually happens
- A custom theme removes focus styles or changes button and error markup presentation.
- An existing form keeps older settings while a newly created form uses accessible defaults.
- A third-party field does not follow the same label, error, or keyboard contract.
- Translated text expands beyond a control or changes the meaning of an instruction.
Decision rule
Do not describe a form as accessible based only on a plugin setting or automated score. Approve the user task when manual keyboard, screen-reader, error, zoom, and mobile flows pass with documented evidence.
Production verification checklist
- A keyboard and screen-reader user can understand, complete, correct, and submit each critical form.
- Focus order, visible focus, labels, errors, announcements, headings, buttons, and conditional content are coherent.
- The form reflows at zoom and mobile sizes without clipped text or unreachable controls.
- Regression fixtures are attached to future Gravity Forms, theme, and add-on updates.
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.
- Select critical user tasks
- Run keyboard and screen-reader fixtures
- Confirm automated findings manually
- Fix theme and field boundaries
- Add regression checks to releases
Mistakes to avoid
- Changing production code, form fields, webhook endpoints, cache settings, or security limits before preserving the failing fixture and current configuration.
- Treating one clean dashboard status as proof even though the browser, PHP process, database, delivery provider, and downstream record have not been reconciled.
- Testing with a different form, role, locale, order state, entry shape, plugin version, or cache state than the workflow users actually reach.
- Leaving debug logs, temporary endpoints, broad permissions, copied secrets, or test notifications active after the verification window closes.
Questions teams ask during testing
Can I test this directly on production?
Read-only checks can be appropriate when access is controlled and output is redacted. Make a backup first, use a named canary record, test state-changing work on staging, define rollback, and schedule any production change for a monitored window.
How do I avoid a false positive?
Match the exact version, request path, form or order ID, role, locale, cache state, and integration path. Repeat the same fixture before and after the change, then compare the saved evidence rather than relying on memory.
What evidence should I keep?
Keep the UTC time, site and plugin versions, fixture ID, expected result, actual result, relevant logs, configuration snapshot, change made, rollback point, and final verification. Remove passwords, tokens, payment details, and personal data.
When should I bring in a specialist?
Escalate when checkout, payments, lead capture, security, customer email, accessibility, or several integrations are affected, or when the safest next step is unclear. A concise evidence packet reduces diagnosis time.
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, logs, change, 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 test the form accessibility workflow.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references