Verify the admin setting can be understood and operated without a mouse, then separately check the warning presented on the public form.
Quick answer
Partial Entries 1.8.2 lists an accessibility correction for the Warning Message setting tooltip. Test the help control in the form-settings screen with a keyboard and the screen reader used by your team. Then check the public form warning separately. An accessible admin tooltip helps the editor understand a setting; it does not prove visitors receive an adequate notice or that the whole form is accessible.
Start with the task an editor needs to complete
The practical task is to find the setting, understand what it changes, edit the intended value, and save it. Record the Gravity Forms and Partial Entries versions, browser, screen reader, and WordPress user role. Use a staging form and synthetic entries. Keep the test focused on the Warning Message control rather than judging the entire administration interface from one tooltip.
Before updating, record the behavior if you can reproduce it safely. Does the trigger receive focus? Does help appear only on hover? Is the text announced? Does opening help move focus unexpectedly? Concrete observations make the post-update comparison useful and help support identify a remaining compatibility problem.
Walk through the setting without using the pointer
Navigate to the setting with the keyboard and watch the focus indicator. Activate the help trigger using the interaction supported by that control, then dismiss it and continue through the form settings. Confirm that focus does not disappear into hidden content or jump to an unrelated part of the screen. Repeat after scrolling because a floating help panel can behave differently near the viewport edge.
Record whether the text remains readable while the user moves to inspect it. Check that the panel does not obscure the setting value or save action in a way that prevents completion. Do not require an arbitrary key sequence simply because another tooltip uses it; assess the documented control and the actual user task. Escalate inconsistent keyboard behavior with an exact reproduction.
Illustrative diagnostic worksheet. Values are examples, not measurements from a customer site.
Listen to the information exposed to assistive technology
Use the screen reader and browser combination available to the editor. Confirm the trigger has an understandable accessible name and the help text can be reached or is associated with the setting as intended. Listen for repeated text, an unlabeled button, a misleading state announcement, or help content that remains announced after it is dismissed.
Then edit and save a harmless test value. Reopen the screen and confirm the saved value is understandable and remains associated with the correct label. A screen reader announcing the tooltip once does not establish that saving the setting works or that validation errors are accessible. Include a validation failure only if that setting has a meaningful invalid input to test.
Check zoom, narrow screens, and translated text
Increase browser zoom and inspect the help near the edges of a narrow viewport. Ensure text can be read without being clipped behind another panel. Longer translated strings often expose problems that the English label does not. Where the site uses another language, repeat the task with that locale and record any untranslated or truncated content.
Compare a clean browser session if custom admin styling or extensions affect the result. Update the plugin on staging, refresh the relevant admin assets, and repeat the same sequence. Avoid adding a broad CSS override that hides help text or removes focus outlines. A local visual workaround should preserve the accessible relationship and survive ordinary resizing.
Verify what a visitor sees separately
Open the public form in a fresh session and check the configured warning text at the point where it is meant to appear. Test the visitor-facing behavior with keyboard navigation as a separate task. Confirm that conditional logic and partial capture still follow the approved configuration. The vendor tooltip fix does not automatically revise the wording or timing of your site notice.
Document the result as a scoped accessibility check, including browser, assistive technology, version, and date. Do not label the entire form compliant based on one corrected tooltip. If an issue remains, include the exact control, action, observed announcement, and expected user outcome in the support report so another tester can reproduce it.
Working example
Use this as a read-only starting point or an evidence worksheet. Replace example identifiers with the approved staging fixture.
accessibility_record:
control: Warning Message help
keyboard_open: record
keyboard_close: record
announced_name: record
tooltip_text: record
public_notice_checked: separately
Before closing the work
- Help is available without mouse hover.
- Focus remains visible and predictable.
- Screen-reader output explains the setting.
- The public notice matches the approved wording.
For help applying these checks to a live site, HandL WP WordPress support can review the affected configuration and verify the result. Continue with Partial Entries identifier regression checks when that adjacent issue matches your evidence.
Helpful references