Radio groups need distinct field names

PDF/UA check RADIO_BUTTON_UNIQUE_NAMES · Forms · severity Medium · PDF/UA 8.10.2 Context · advanced check

↩ Back to the rules index · WCAG cross-reference

Advanced check. This is a file-internals rule. It is hidden from the standard report view and generally indicates a problem with the tool that produced the PDF rather than something an author did.

Why it matters#

Radio buttons sharing a variable name also share the TU tooltip, so screen reader users hear the same label for unrelated controls.

What you will see#

Radio buttons belonging to different questions share one field name, so they behave and announce as a single group.

How to fix#

Rename each radio button group so its /T (field name) is unique within the form. Buttons within one group must share a /T, but separate groups must not. In Acrobat: field Properties > General > Name.

Step-by-step guide#

1. Open All tools > Prepare a form and study the Fields list in the right-hand pane: radio buttons that belong to one question correctly share a field name, but separate questions must never share one.
2. For each group that wrongly shares a name with an unrelated group, select all buttons of that group, open Properties > General, and enter a unique Name. Acrobat writes this as the /T entry of the group's field dictionary.
3. Within a single group, keep the shared name but give each button a distinct choice value: Properties > Options > Radio Button Choice (the export value), e.g. Yes / No.
4. Give every radio button group a Tooltip (Properties > General; Acrobat writes it as the field's TU entry) describing that group's question. This rule also errors any radio group field whose dictionary lacks a non-empty TU, and after renaming, formerly shared tooltips must be rewritten per group.
5. Search any form JavaScript, calculation, or submit logic for the old fully qualified field name and update the references, since renaming changes it.
6. Test the form by clicking through both groups: selecting a button in one group must no longer change the selection in the other.

Verify: Re-run the EQChecker scan in advanced mode (this rule is advanced-only): RADIO_BUTTON_UNIQUE_NAMES should report zero errors once every radio group has a unique /T and a non-empty TU, and manual fill-in should show each group toggling independently.

Note: EQChecker flags two modes under this rule: a /T value reused by more than one radio button group, and a radio group field missing its /TU tooltip. The name defect is functional as well as accessibility-related: same-named groups mirror each other's selection, so sighted users are affected too. Buttons that should act as one group (one answer among several widgets) legitimately share a /T and are not flagged.

WCAG success criteria#

4.1.2 Name, Role, Value — Level A#

Every UI component must expose a correct name, role, and (where relevant) state/value to assistive technology.

Understanding 4.1.2

Standards#

This check contributes to the following standards:

PDF/UA WCAG A EN 301 549