Summary items should jump to the matching field
Aliases: summary in-page link · error list navigation · jump to invalid
What it is
If the top list is only unclickable text, people still have to hunt the item in a long form. Jumpable means each summary line is an in-page link to the matching input: on activation, focus lands on that field and it becomes editable. The jump is to the control, not to a nearby section anchor. This entry assumes the list already exists and only covers its navigation. It does not argue why a list is needed, and it does not argue whether the list can replace the sentence beside the field.
Why it happens
Between a table of contents and an object sit scroll distance and visual search. A plain-text list only informs; arrival is left to the person. On long forms, split panes, and collapses, the name in the list may not match the on-screen label (“Contact number” versus “Mobile”), and search fails. A link collapses arrival into one activation: reading order, focus, and viewport alignment bind to the same target. A second layer is a reversible round trip. After fixing one item, people often return to the list to see what remains. If the jump is a one-way location.hash and focus is stranded on the field with no cheap way back, the list’s counting job is wasted and people go back to using submit as a probe. Typical jump failure is not a missing href. It is an id on a wrapper div, a disabled field, or focus() into a still-collapsed section, so focus lands on an invisible node and looks like nothing happened.
Studying it
Build the same three-error list as plain text, jump-to-section-heading, and jump-to-input-and-focus. Measure time from choosing a list item to starting to edit. Include keyboard and screen-reader users.
Independent variables: jump target (none / section / input control), whether a collapse auto-expands, whether a path back to the list exists. Dependent variables: time from click to first keystroke in that field, whether focus lands on an editable node, whether the reader announces the field name, trips back to the list to handle the next item.
Mouse users scroll themselves and hide jump failure. If Tab order breaks after a keyboard user activates a list link, record that separately. An anchor is not the same as focusable-on-the-input.
Where it stops holding
One-time codes and file pickers that cannot take focus should send the link to their focusable trigger or wrapping text, expanding any needed collapse on arrival. If a single-page router treats #field-id as another navigation, the jump reloads the form and dumps filled values; use an in-page focus API, not a route change. A printed list has no jump. When the list itself is taller than a screen, it must be keyboard-traversable, or the jump entries cannot be reached.
Applying it
- Turn each summary line into a link to the matching input
id. On activation, expand its collapse and set focus on that input—not merely scroll to a nearby heading. - Keep the same wording for the field in the list and on the label, so arrival does not look like the wrong place.
- Provide a keyboard path back to the list (a focusable list container, or “Back to error list”) so people can work the directory item by item without resubmitting.
- Verify by activating the second list item from the keyboard: focus must be in the second input and ready to type. Put that field in a collapse and confirm it expands then focuses. After a fix, Shift+Tab or “Back to error list” must return to the list. Bind
idto an outer div as a counterexample and reject that implementation.