E2.03.3programmatic label associationdesignresearch

Label and field must be associated in the accessibility tree

Aliases: label for · accessible name · aria-labelledby

What it is

Seeing a caption next to a trough does not mean assistive technology knows they are a pair. Programmatic label association binds the name to the control in the accessibility tree: a label for pointing at the control id, or aria-labelledby pointing at the name node. Screen readers, voice control, and autofill read that tree, not the layout. The issue is whether the name belongs to this slot, not whether the caption sits above or to the left.

Why it happens

Visual association rides on proximity and alignment; programmatic association rides on an explicit reference. Without the reference, a screen reader entering the slot announces “edit text” and the user cannot tell what to type without hunting. Clicking a caption should move focus into the slot—the default behavior of a label element, which also enlarges the hit target. A div that merely looks like a caption has none of that behavior, so even sighted users who click the name miss. Placeholders, icons, and header cells are not reliable accessible-name sources. When several slots share one visible phrase (two boxes under “Name”), binding the phrase to only one leaves the other anonymous in the tree. A wrong for that points at the neighboring field is worse than none: the announcement is a lie, and people fill the wrong value.

Studying it

Walk each input with an accessibility-tree inspector and a screen reader: does it have an accessible name, does that name match the visible caption, does clicking the caption focus the matching slot? Factors: association method (for / wrapping / aria-labelledby / placeholder only), whether the visible caption is display:none or off-screen. Outcomes: name exposure, click-to-focus hit rate, time and errors for screen-reader users completing the form. Automations catch “no name”; they miss “name points at the wrong object,” which needs a screen reader checked against visible text. Sighted lab participants will not feel this failure at all.

Where it stops holding

Canvas widgets, custom comboboxes, and contenteditable surfaces often sit outside the native label model and need an accessible name of their own; “there is text nearby” is not enough. Hiding the visible caption and stuffing a name in only for the tree can satisfy a checker while the name vanishes from the visual field after typing—that is not the same as association. Machine translation that rewrites visible nodes but not aria-label produces two languages of name. Captchas and file pickers sometimes have user-agent-synthesized names that override or sit beside the author’s association; listen in the target browsers.

Applying it

  • Bind every input to its visible caption with label for or equivalent aria-labelledby; do not fake a label with an unreferenced div.
  • Make a click on the visible name focus the matching slot; a dead click means the association was not built.
  • Inspect the accessibility tree: the name string must match the visible text and must not belong to the neighboring field.
  • Verify by filling the whole form with the screen off and a screen reader on. The announced name at each slot must be enough to decide what to type. Then, with the screen on, click every caption; focus must land in the slot it names.

Related

  • Within the group: E2.03.1 Top-aligned labels cost height but scan fastest · E2.03.2 Left labels save height but add saccades
  • Adjacent: E2.04 Placeholders · E2.21 Read-only, disabled, and non-editable
  • Search terms: programmatic label association · accessible name · label for

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E2.03.3