Gravity Forms 3.1.1.1 fixes an entry-list star toggle that was not operable by keyboard and screen readers. This control often marks leads, applications, disputes, or support cases for follow-up. A visual-only fix is incomplete if focus disappears, state changes are silent, the wrong row is updated, or filtering loses the saved value.
Use this for teams that triage Gravity Forms entries in WordPress, especially support desks, admissions teams, nonprofits, sales operations, agencies, and organizations subject to accessibility requirements or internal keyboard-only workflows.
Quick answer
Create three synthetic entries with distinct IDs and open the entry list as a role that can view and edit them. Reach each star using Tab and reverse Tab, activate it with Space and Enter, and listen with VoiceOver, NVDA, or another supported screen reader. The control needs an accessible name, a perceivable on or off state, a stable focus indicator, one saved change on the intended entry, and the same state after refresh, filtering, pagination, bulk actions, and a second session.
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 | Tab then Space | Correct row toggles |
| Screen reader | Star off then on | Name and state announced |
| Refresh | Previously starred entry | State persists |
| Read-only role | Focus control | No unauthorized change |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Create distinct entry fixtures | Record Gravity Forms and WordPress versions, browser, screen reader, zoom, admin color scheme, role, form ID, entry IDs, pagination, and active filters. | Every visible star is reachable in a logical focus order and has a clear focus indicator. |
| Test native keyboard actions | Navigate from the page heading to the first entry star and through adjacent row actions using Tab, Shift plus Tab, Space, Enter, and arrow keys where applicable. | The accessible name and state describe the same value shown visually before and after activation. |
| Inspect announced state | Confirm the accessibility tree exposes a useful control name, current state, focus order, and state change without depending on color or the star glyph alone. | Refresh, sorting, filtering, pagination, and a second browser session preserve the intended entry state. |
| Reconcile the saved entry | Toggle stars on different rows, refresh, filter to starred entries, change pages, use bulk actions, and verify the saved database state matches the visible row. | A read-only or unauthorized role cannot change the value and receives understandable feedback. |
What to check first
- Record Gravity Forms and WordPress versions, browser, screen reader, zoom, admin color scheme, role, form ID, entry IDs, pagination, and active filters.
- Navigate from the page heading to the first entry star and through adjacent row actions using Tab, Shift plus Tab, Space, Enter, and arrow keys where applicable.
- Confirm the accessibility tree exposes a useful control name, current state, focus order, and state change without depending on color or the star glyph alone.
- Toggle stars on different rows, refresh, filter to starred entries, change pages, use bulk actions, and verify the saved database state matches the visible row.
- Repeat at 200 percent zoom, high contrast, reduced motion, a narrow viewport, and with a least-privilege role that can view but not edit entries.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison far more useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, OAuth refreshes, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Browser checklist
# 1. Tab to the star without using a mouse.
# 2. Record the accessible name and pressed state.
# 3. Press Space, refresh, and filter by Starred.
# 4. Confirm the same entry ID remains starred in a second session.
Why this usually happens
- A clickable icon is rendered without native button behavior or an equivalent keyboard handler.
- The visual class changes while aria-pressed, the accessible name, or live feedback remains stale.
- An event handler uses row position instead of the persistent entry ID after sorting or pagination.
- A permission failure is swallowed, leaving a star that looks active until the page reloads.
Decision rule
Approve the fix only when keyboard and assistive technology users can discover, activate, understand, and verify the star state on the correct entry without mouse input or elevated permissions.
Production verification checklist
- Every visible star is reachable in a logical focus order and has a clear focus indicator.
- The accessible name and state describe the same value shown visually before and after activation.
- Refresh, sorting, filtering, pagination, and a second browser session preserve the intended entry state.
- A read-only or unauthorized role cannot change the value and receives understandable feedback.
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.
- Create distinct entry fixtures
- Test native keyboard actions
- Inspect announced state
- Reconcile the saved entry
- Repeat across filters and roles
Mistakes to avoid
- Changing production before recording plugin versions, WordPress version, PHP version, UTC time, the exact fixture, and a tested rollback point.
- Accepting one successful admin screen while the public form, stored record, API response, accessibility tree, cache, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving test accounts, broad credentials, debug logs, temporary compatibility filters, or synthetic customer data active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, caching stack, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I know the result is not a cache artifact?
Record the origin response, purge only the affected paths, and repeat the test in a private session and a normal session. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When can I close the test?
Close it when the primary path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove 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 Gravity Forms accessibility.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references