Pinpoint the location of the problem

What it is

An error message should draw attention to the smallest fixable unit: which field, row, object, parameter, permission, or step failed. Error location covers visual markers, focus movement, anchor links, and context summaries, so users do not have to check every item one by one. It is a different job from stating the problem in plain language: that card answers "what," this one answers "where" — however clearly a sentence is written, if the user still has to scan a fifty-row form to find which row triggered it, the cost of missing localization is still there.

Why it happens

The cost of fixing an error splits into two parts: understanding what the error means, and finding where it is in the interface. The second part is routinely underestimated, yet it is often the larger one in long forms, batch files, code editors, and query builders — settings where dozens of candidate objects can coexist. A generic banner such as "there is an error in this form" does not narrow the search at all; the user has to rescan everything, effectively handing back to the user a computation the system had already finished internally. Precise location compresses the search space from "the whole page" to "one object," which is really the system handing over the result of a lookup it already did, instead of making the user redo that lookup. One detail that is easy to miss: after moving focus or scrolling to the error, a summary of the remaining errors must stay visible at the edge of view — otherwise the user resolves the one detail in front of them but loses track, mid-scroll, of how many others remain and why they came here in the first place.

Where it stops holding

The system cannot always pin down a single cause, especially in forms with interdependent conditions — an "end date" error might stem from its own bad format, or from the "start date" having just been edited. A compound error should list every detected location and the order to address them, rather than reporting only the first one found, because a user who fixes one field only to have a second error pop up afterward has a worse experience than seeing the full list at once. In asynchronous or concurrent settings, the location can shift after the error was generated — a collaborator may have already deleted that row during shared editing — so the system needs to record a version or timestamp and state explicitly which version the error was detected against; otherwise the user navigates to a problem that no longer exists, which is more confusing than no location at all. Security contexts may forbid exposing an exact internal path or object identifier, but a relative location the user can still understand — "the shipping address in step 3" rather than a raw database field name — remains available.

Applying it

• Show field-level errors inline and automatically move focus to the first error that blocks continuing, so the user does not have to search for it manually.
• For batch tasks, show the object ID, row number, and a summary of the failure reason, and support filtering to "failed items only" so users are not left paging through hundreds or thousands of records by hand.
• When multiple errors coexist, provide a jumpable navigation list that updates its count and remaining items automatically as each one is fixed, instead of requiring a full re-validation to see progress.
• How to check: walk the full error-to-fix flow three separate ways — mouse scrolling, keyboard-only navigation, and a screen reader — and confirm the error location is reachable, announced, or visible under all three, not only as a red visual highlight.

Related

• Same group: B3.09.1 Error messages should explain the problem in plain language · B3.09.3 Provide an actionable path forward · B3.09.4 Do not use an error code as the only information
• Nearby: B3.05 Error Prevention · J1 Accessibility and Inclusive Design
• Search terms: inline validation · error localization · focus management · search space