Give PDF form fields a name, role, and value
Every PDF form field has to expose three things through the accessibility layer. A name, a role, and its current value or state. Each lives in a named entry of the field dictionary. FT carries the role, TU carries the name, V carries the value, and DV carries the default. Pushbuttons take their name from CA instead. W3C publishes PDF12 as a sufficient technique across the six control types PDF supports, which are text field, check box, radio button, combo box, list box, and button. There is one trap here that catches almost everybody. The Name box in Acrobat's field properties dialog is the T entry, and it is not the name assistive technology reads. TU is, and Acrobat calls it Tooltip.
How we find it in an audit
We operate every control with a screen reader and check all three parts. What it is called, what kind of control it announces as, and whether a state change is spoken when a box is ticked or a list option chosen. Then we confirm the field types and the tooltip entries in Acrobat's form editor, and look at the tag tree. A field with a filled-in Name box and an empty Tooltip box announces as nothing at all, which is the shape this defect usually takes.
How affected users experience it
When role or state is missing, a checkbox announces as nothing in particular and never confirms it was ticked. The user checks "I agree to the terms" and gets silence. Did it register? On legal forms, not knowing a control's state means not knowing what you just agreed to.
Passes vs. fails
Passes
The form uses real AcroForm checkboxes. "I agree to electronic delivery of statements, check box, not checked", and "checked" is announced the moment it is toggled.
Fails
A consent form's checkboxes are drawn squares with an invisible button on top. Screen readers announce "button" with no name, and ticking one reports no change at all.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Headers attribute specified on a cell refers to cells in the same table elementA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA global properties not used where prohibitedA tool can check this
- ARIA required context roleA tool can check this
- ARIA required owned elementsA tool can check this
- ARIA state or property is permittedA tool can check this
- Table header cell has assigned cellsA tool can check this
- Image button has non-empty accessible nameA tool can check this
- Link has non-empty accessible nameA tool can check this
- Button has non-empty accessible nameA tool can check this
- Element with aria-hidden has no content in sequential focus navigationA tool can check this
- Element with presentational children has no focusable contentA tool can check this
- Menuitem has non-empty accessible nameA tool can check this
- Summary element has non-empty accessible nameA tool can check this
- Iframe element has non-empty accessible nameA tool can check this
- Iframe elements with identical accessible names have equivalent purposeA tool finds candidates, you decide
Other ways to satisfy this rule
52 guides on this site are filed under 1.3.1 Info and Relationships. W3C lists this one as sufficient for that rule when used for making information and relationships conveyed through presentation programmatically determinable, so the condition is part of the test rather than a footnote to it.
- ARIA11sufficientAdd landmarks so users can skip around
- ARIA12sufficientUse role=heading when h1-h6 is impossible
- ARIA13sufficientName repeated landmarks so they are distinguishable
- ARIA16sufficientName controls from visible text with aria-labelledby
- ARIA17sufficientGroup related form fields with ARIA roles
- ARIA20sufficientMark leftover page areas with role=region
This guide is our interpretation of W3C technique PDF12: Providing name, role, value information for form fields in PDF documents. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.