Form fields need labels

PDF/UA check FORM_FIELD_DESCRIPTION · Forms · severity Critical · PDF/UA 8.10.2 Context

↩ Back to the rules index · WCAG cross-reference

Why it matters#

Form fields need labels that screen readers can announce. Without a TU or Contents entry, users hear 'edit field' with no indication of what information to enter (name, email, phone number, etc.).

What you will see#

A form field has no tooltip or description, so screen readers announce it as an unnamed edit box.

How to fix#

Add a TU (tooltip) entry to the form field dictionary or a Contents entry to its widget annotation, stating what to enter or select (e.g. 'Email address'); either entry satisfies this check. In Acrobat: field Properties > General > Tooltip.

Step-by-step guide#

1. Open All tools > Prepare a form (the classic Prepare Form tool) in Acrobat Pro and locate each flagged field.
2. Double-click the field, and on the General tab of the Properties dialog enter a Tooltip that states what to enter or select, e.g. Email address or Date of birth (DD/MM/YYYY). Acrobat stores this as the field's TU entry; a non-empty TU alone satisfies this check.
3. Alternative path: the standard also accepts a Contents entry on the widget annotation dictionary (ISO 14289-2 section 8.10.2 accepts both as context sources), but Acrobat has no UI for widget Contents - use the Tooltip (TU) path above, which fully satisfies this check.
4. When one field owns multiple widgets (e.g. a radio group in a survey grid), a shared TU is often insufficient per section 8.10.2.4, which requires a label, a Contents entry, or both per widget. To clear this check give each widget its own TU or Contents entry - EQChecker reads them on each widget dictionary and does not inherit the parent field's TU or count a visible Lbl label.
5. Also give each named parent field that groups widget kids (e.g. a radio group's parent dictionary) its own TU tooltip: EQChecker flags a named field with widget children and no TU under this same rule.
6. If the widget annotation has an additional-action (AA) entry, make its Contents entry describe the action's intent (section 8.10.2.3).
7. Write descriptions that add information: per section 8.10.2.3 the Contents entry should not simply duplicate the visible label. State the expected input or the effect of the control.

Verify: Re-run the EQChecker scan: FORM_FIELD_DESCRIPTION should report zero errors. Acrobat's accessibility check (Field descriptions) should also pass.

Note: The field name (/T entry) does not count as context (section 8.10.2.1 note). A widget used exclusively for calculations or otherwise invisible should be marked as an artifact instead of described (section 8.10.1); artifact widgets are outside this requirement. A visible label wrapped in Lbl satisfies the standard and FORM_LBL_STRUCTURE, but this specific check looks only at TU and Contents.

Fixing it in your authoring tool#

WCAG success criteria#

3.3.2 Labels or Instructions — Level A#

Inputs need labels or instructions so users know what to enter.

Understanding 3.3.2

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

References#

• W3C — PDF Techniques for WCAG 2.1