The invalid field must be visible in the viewport

What it is

Focus on a field is not the same as seeing it. Sticky headers, mobile keyboards, bottom bars, and error copy that pushes the input off-screen all park the “current item” outside the viewport. Visible in the viewport means the invalid label, the input itself, and the error text next to it appear together in unobstructed visible area, so people do not have to guess where focus went. This entry is about geometric visibility. It is not which item should receive programmatic focus, and not whether red versus gray can distinguish an error. A summary visible at the top does not make the field itself visible.

Why it happens

The viewport is a rectangle cut jointly by the browser, the system keyboard, and sticky layers the product built. focus() by default only gets the element into the scroll container. It does not keep a 56-pixel sticky bar from covering it, and it does not keep a phone keyboard from pushing the input behind the keys. People who see blank space or half a box think the system did nothing, and they submit again. A second layer is the three-piece set on stage together. If only the input shows, the label is above the fold, and the error copy is below it, “which item, what is wrong” cannot be read in one look; fixing becomes a memory task. Visible is not a blinking caret. It is the bounding box of label + control + error copy inside the safe area. If a scroll animation is long, or reduced-motion turns it off, a final position that is still covered is a failure even when the animation “succeeds.”

Studying it

Fail submit on pages with sticky navigation, a virtual keyboard, and a bottom banner. Measure how many pixels of the error three-piece set land in unobstructed area.

Independent variables: sticky header height, system keyboard up or not, scroll alignment (flush top / padded for the header), error copy above versus below the field. Dependent variables: occluded pixels of label, input, and error copy, rate of “I can’t see the box to fix,” repeat submits.

Desktop labs miss keyboard occlusion. Use a real device with the keyboard up. Do not treat “scrollIntoView was called” as success—calling and seeing are not the same.

Where it stops holding

A very long error cannot share the viewport with the input; compress the visible explanation to two lines and expand the rest, rather than shoving the input away to fit the essay. In a split pane, the field may live in the right pane while the window scrolls the left; scrolling the wrong container leaves the field off-screen forever. At 200% zoom or with a screen magnifier, “visible” is relative to the magnified window, not the layout viewport; the focus indicator then matters more than the whole three-piece set, but the input still cannot sit outside the magnified window. Print preview has no interactive viewport; the claim does not apply.

Applying it

• After a failed submit is aimed at the invalid item, scroll the actual scroll container so label, input, and error copy enter the safe area not covered by sticky layers or the system keyboard; when aligning to the top, pad by the sticky header’s height.
• On mobile, measure again after the keyboard opens, and scroll the field above the keyboard rather than to the physical top of the page.
• Keep error copy next to the field, with a visible summary of at most two lines, so a long message does not push the input out of the viewport.
• Verify with the sticky header on and the first error at the top of the page; screenshot after submit and check the label is not sliced by the bar. Submit again on a real device with the keyboard up and check the input is fully visible above the keys. Write the error to four lines and see whether the input is pushed out; compress to two and retest that the three-piece set shares the screen.

Related

• Within the group: H1.05.1 A failed submit must move focus to the first invalid field · H1.05.3 Error identification cannot rely on color alone
• Adjacent: F1.02 Feedback location matching the action · F1.10 Viewport compression when the keyboard opens · F1.12 Fixed elements and safe areas
• Search terms: scroll into view · sticky header · viewport