Quick answer
Check the repeater's group label and each child field label separately. Gravity Forms 3.1.1 includes a fix for child labels being hidden when the repeater label is hidden. After updating, inspect visible labels, computed accessible names, and dynamically added rows rather than checking only the first row with a mouse.
Start with a small repeater
Create a staging example containing two clearly different child fields, such as attendee name and meal preference. Give them distinct labels and use fictional values. Keep the original field IDs when reproducing the problem so notifications and reports continue to refer to the same fields.
Record whether the group label is hidden, whether child labels are intentionally hidden, and what theme or custom CSS is active. A styling rule that hides every label inside a wrapper can resemble a plugin defect. Compare a minimal standard layout before changing the production form's entire design.
Inspect what the user can see
Load the public form, not just the editor preview. Check the first repeater row at a comfortable zoom level and on a narrow viewport. Look for clipping, low contrast, labels behind other elements, or text that disappears when a value is entered.
A placeholder inside an empty field can look like a label in a screenshot but disappear during typing. Do not use that appearance as the only evidence that the input is identifiable. Verify that the actual question remains understandable after a visitor has filled in a value or revisits an earlier row.
Inspect what assistive technology receives
Use browser accessibility inspection to record the computed name and role of each input. Where an explicit HTML label is used, its association must identify the intended control. Check that repeated rows do not accidentally reuse an association that points every label to the first input.
W3C guidance distinguishes visible labeling from programmatically available names. Both matter to this review. An aria-label can provide a name in some situations, but adding one indiscriminately is not a substitute for understanding why the intended label disappeared. Preserve clear visible questions for people who rely on them.
Add a second and third row
Dynamic rows are a separate test. Add a row, enter distinct fictional values, and inspect its labels and accessible names again. Then remove the middle row and inspect the remaining rows. A correct initial render does not prove that cloned or regenerated controls retain correct relationships.
Check the accessible names of add and remove controls as well. The user should be able to understand which operation will happen and where. If several identical removal buttons are ambiguous, preserve that observation for the form maintainer rather than assuming the child-label release fix covers every repeater interaction.
- Inspect first, added, and remaining rows separately.
- Do not duplicate field IDs while trying to repair labels.
- Check both empty and filled controls.
- Record an observed screen-reader result only after using that screen reader.
Follow the keyboard through a complete task
Begin before the repeater and move through the controls using the keyboard. Add a row, fill it, and remove a row using the supported controls. Observe where focus moves after each action and whether it stays visible. Do not accept a result that leaves focus apparently lost after removal.
Submit the test form with one required child value missing. Check how the error identifies the affected input and whether the user can return to it. A correct label during normal entry can still be insufficient if the validation message or focus target points to another row.
Verify the saved values and downstream output
After a valid submission, inspect the local entry and one important notification or report. Match the fictional values to the correct child fields and row order. This is a separate integrity check from the accessible-name review, and it protects against a repair that recreated fields unnecessarily.
If the browser is now clear but the email output is confusing, use the related repeater output guide. Do not fix an email formatting problem by changing public labels repeatedly. Keep public interaction, stored data, and formatted output as distinct checkpoints.
Document the actual coverage
Record plugin version, theme, browser, viewport, and any assistive technology used. Note which combinations were tested and which remain untested. Avoid claiming universal accessibility compliance from a single browser inspection.
Release the smallest maintained CSS or configuration correction needed, if an update alone did not solve the problem. Preserve the prior revision, clear relevant assets, and repeat the public-page checks. The useful handover is a reproducible field-level result, not just a new screenshot of the editor.
Illustrative diagnostic worksheet, not results from a customer site.When to bring in help
For WordPress form accessibility support, provide a minimal repeater fixture, browser and assistive-technology versions, and the exact label or focus failure. A screenshot helps with visible labels, but include the accessible-name observation too. Do not claim a screen-reader pass based only on an automated score.
Related troubleshooting
Check repeater output in notifications and reports.
Helpful references
Gravity Forms 3.1.1 release notes. W3C guidance on labeling controls.