Hover menus can open outside the magnified window

What it is

“More” opens and the menu grows toward the display edge. The trigger is still in the centre of the lens; all twelve items are already outside it. The type is not too small — the floating layer never entered the current window. Selects, date panels, nested popovers, chart hover cards: under magnification they all risk painting the newly opened UI at coordinates the user cannot see.

Putting an error next to its field is cue proximity. This leaf is overflow of floating UI relative to the magnified window.

Why it happens

Positioning algorithms key off the trigger or the browser viewport: open downward, flip upward if short, hug the window edge. They do not know a magnifier lens is wrapped around a small patch. A 300-pixel menu below the trigger is convenient on a full screen and entirely off-canvas at 8× when the lens only covers the trigger.

If the lens follows the pointer, the menu is reached only after the pointer moves into it — and if the menu closes on “pointer left the trigger,” the user can never catch it. If the lens follows keyboard focus and focus stays on the trigger, the menu is equally off-screen. The distinctive failure: the feature is open, and visually it looks as if nothing happened.

Studying it

At 4× and 8×, open typical layers (select, date picker, overflow “more,” chart tooltip) and capture the lens at the instant of opening. Record: what fraction of the layer sits inside the lens, whether a pan is required to see the first item, whether the layer closes during that pan. Independent: placement (below / above / overlapping the trigger) and tracking mode. Dependent: visible fraction, time to the first successful hit, accidental dismissals.

Contrast “move focus into the layer on open” with “leave focus on the trigger” to see whether follow-focus magnification will carry the lens into the menu.

Where it stops holding

A large modal that fills most of the browser window at least shows a patch of itself in the lens; the problem becomes further panning inside, not total overflow. Global toasts pinned to a viewport corner are not trigger-relative; they fail as sudden appearance elsewhere. Touch long-press menus can still clip under pinch-zoom, but they do not share desktop hover-dismiss logic. Fully keyboard use with focus actually entering the menu can be rescued by follow-focus — only if focus really enters, rather than the menu merely painting.

Applying it

• Open the layer next to the trigger, with the first item adjacent to it. Do not leave a large empty gap before the first option.
• On open, move focus to the first item so follow-focus magnification brings the lens along. Do not dismiss as soon as the pointer leaves the trigger while travelling toward the menu.
• Flip to the other side when short on space, but keep visible overlap with the trigger; do not jump to the opposite edge of the display.
• How to check: aim an 8× lens at the trigger, open the menu, do not pan, take a shot. If no selectable item is in that shot, it overflowed. Then move focus into the menu and confirm the lens follows without the menu closing.

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.3 A cue must sit next to the element it belongs to · J2.07.4 Screen magnifiers make the pointer easy to lose · 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.08 Overlay anchoring · J3.02 Focus Order and Focus Traps
• Search terms: magnified popover · hover overflow · lens clipping