Interactive Element Names Available

Proposed "Label gaps" in #194: when one element acts as a label of another, the gap between them is no larger than twice the smaller of the labelled element's width or height, measurable with a browser ruler or a script comparing absolute positions. When textareas broke that formula he reworked it to four times the smaller dimension of the label itself, so an icon or short text label sets the budget rather than a large field. He cites repeated findings in his own user testing with low vision users — drop-down menus on accessuse.eu and the incobs tablet tests — while conceding the label-to-control pair catches only a subset of the proximity problem, and that the exception list may grow until the requirement is lost, as happened with target size.

Found the loophole immediately: a designer could make fields unnecessarily tall purely to buy leeway to push the label further away, conforming while defeating the point for low vision users. detlevhfischer answered "not likely to happen"; patrickhlauke replied that creative interpretations of normative text to do the minimum necessary to pass are routine. His broader position is that layout and design questions resist rigid binary pass/fail rules, that Apple's own iOS guidance is couched as could and should and Apple ignores it freely, and that this belongs in a non-normative best-practice note or at AAA rather than as a hard requirement. He also asked that the measurement drop mm for px to avoid reopening the CSS-versus-physical-units confusion, which detlevhfischer did immediately.

awkawk points to left-aligned label columns with aligned fields, where varying label lengths necessarily produce varying gaps, and argues this is common enough that the working group needs clear evidence before proposing a criterion against it — this is not an absolute like page title or programmatic label association. He wants the goal stated first: at what magnification must the user see the full label and the full input, or the full label and part of the input, and what happens when the label is long. jake-abma checked with designers and reported back that almost all current forms would fail the proposed calculation, which he called too prescriptive for design aesthetics, and later that mixed 3x and 4x width-or-height measurements are simply too complicated for designers, developers and testers.

Answers awkawk that clear evidence only ever comes from research, and the group has a chicken-and-egg problem when practitioner experience outruns formal study. Cites the Understanding document for SC 3.3.2, which stated in 2008 that labels in close proximity assist screen magnifier users because field and label are more likely to be visible within the magnified area, plus technique G162 and two Nielsen Norman Group articles on closeness of actions to objects and form white space. Turns the evidence demand back on existing criteria by questioning whether page titles are still demonstrably useful when browsers truncate or hide them. Calls awkawk's own screenshot a prime example of the problem: a common pattern is not thereby a correct one.

patrickhlauke suggested a minimum built on reflow rather than ratios: the related element must be at least partly present in the viewport even at 320 CSS px width. jake-abma picked this up as the direction most likely to work — label and input visible in a 320 CSS px viewport at the same time, easy to test, with exceptions. He also supplied its limits: whether the label is visible depends on how far you have scrolled, something can be inside the viewport and still too far to read, and desktop zoom tools push the label off to the right and force horizontal scrolling, so the desktop case stays unsolved.

alastc showed the formula failing a usable pattern — the GOV.UK Design System text input with hint text between label and field, and again when an error message is inserted — then proposed folding associated information into the definition of label, and a looser framing that two related things must be close to each other unless there is a programmatic relationship, with gestalt principles consulted for what close means. He intended the escape hatch to leave room for a future user agent that draws an arrow or indicator, and suggested the COGA task force's design guidance as the better home. patrickhlauke rejected both halves: if the requirement is visual then a programmatic relationship is irrelevant to a user who is not running AT that exposes it, shifting the burden to user agents is a cop-out, and since programmatic association is already required by 1.3.1 and usually 4.1.2, a criterion satisfiable by passing those is redundant. jake-abma agreed on widening, arguing all name-value pairs and many other related pairs deserve the same treatment.

In #890 (October 2026) mcking65 proposes removing the programmatically available requirement from this provision, rewording it as "Names (including labels) that identify the purpose of the interactive element are visually persistent", and moving programmatic names into Roles, values, states, properties available, reworded so those attributes are "reliably" programmatically determinable. His grounds are that visual and API testing are separate processes, often by separate testers, and that bugs are easier to route when a provision clearly concerns visual design or code. GreggVan objects that "reliably" cannot be defined to mean matching the visible label and is not an objective term, that names do not include labels — labels have meant what is visible and names what is programmatically determinable — and that the name often should say more than the label, as with ON/OFF buttons whose association is visually obvious. He asks the group to start from desired outcomes for users without vision, with good vision and with low vision (and cognitive needs if not covered elsewhere), then decide whether this is one requirement or two.