A cue must sit next to the element it belongs to

What it is

The validation failure is a red banner at the top of the form; the person is still editing the third field. For them that banner might as well be in another room. Tooltips, status dots, character counts, inline help — all of these are a sentence about a particular object. The sentence has to appear next to that object, or a magnified user cannot hear it without moving the lens.

Stable pairs living far apart are scatter. This leaf is about where the “about this” feedback lands.

Why it happens

A cue is brief and directional: it answers “what is wrong with this field.” If the lens is on the field and the cue sits in a page-top summary, a corner toast, or a native bubble offset far from the control, the user still sees the field and the feedback channel is dead. They either keep typing or pan at random to find the red sentence, then still have to bind that sentence back to the object.

Proximity is not visual neatness. It puts the object and the sentence about it in the same lens. Once they cannot share a frame, the cue has not been issued.

Studying it

Have people submit a form with planted errors under magnification. Record: how long until the error text first enters the lens, whether focus is still on the matching field when it does, and whether they fix the wrong field. Independent variable: errors as a page-top summary / inline on the field / both. Dependent: time to notice, fields corrected, pans spent hunting the cue.

A cheap overlay also works: draw bounding boxes for each cue and its owner, measure centre distance. If that distance exceeds the short side of the lens at the current zoom, the cue is unusable at that zoom.

Where it stops holding

A confirmation page that is the task (“check these three items”) is not field-level feedback. Screen-reader users also need the error tied to the field in the accessible name or description; visual proximity does not repair a missing programmatic association. Native browser bubbles are only partly under page control — the page still needs its own visible, adjacent explanation rather than hoping the bubble lands in the lens.

Applying it

• Put field-level errors, constraints, counts, and password strength against that field (below or beside it), not only in a form-top stack or a corner toast.
• If a page-level summary is required, each item should point back to its field, and focus should move to the first error so the lens follows.
• Help that appears on hover must also appear beside the control on keyboard focus.
• How to check: at 8×, leave focus on the target control and trigger its error or help. Without panning, the sentence should already be in the shot. If it is not, the landing is wrong.

Related

• Same group: J2.07.1 Magnification shrinks the visible field to a tiny viewport · J2.07.2 Scattered related elements force pan-and-search · J2.07.4 Screen magnifiers make the pointer easy to lose · J2.07.5 Hover menus can open outside the magnified window · J2.07.6 Some low-vision users rely on color, not zoom — both paths must work · J2.07.7 Dynamic content is missed unless the magnified view is cued
• Nearby: F1.02 Feedback location versus point of action · J2.06 Focus Visibility
• Search terms: cue proximity · inline error · associated description