Screen magnifiers make the pointer easy to lose
Aliases: lost cursor · magnified pointer · custom cursor failure
What it is
To a magnifier, the pointer is “where I am”: the lens tracks it, and the click lands on its tip. Swap the system pointer for a hairline, a custom cursor that matches the background, or hide it during drag or loading, and the user loses more than an arrow — they lose the lens’s anchor.
This is not about whether a menu opened off-screen. It is about whether people can still see their own pointing location.
Why it happens
Unmagnified, the pointer is one of the highest-contrast small objects on the display; peripheral vision holds it. Under magnification it is just another glyph in the lens, and it does not automatically grow with zoom (large pointer / crosshair are extra OS settings; page-level custom cursors often bypass them). A 16-pixel pale arrow on a pale toolbar is, inside the lens, texture without an anchor.
Worse is disappearance: cursor: none, a drag preview that replaces the pointer, a busy spinner drawn somewhere else. The lens stays put or chases the preview, and the user cannot answer “where will the next click land.” The usual recovery is to fling the mouse to a screen edge — which flings the lens away and loses the block they were reading.
Studying it
Three pointer conditions: system default, system large pointer, and a page custom cursor (low contrast against the background, plus a drag that hides the pointer). Tasks at 8×: hit a small target; complete a drag-reorder. Dependent: time from losing the pointer to re-acquiring it, mis-clicks, use of the “fling to edge” strategy, reports of not knowing where the click will land.
Toggle OS pointer trails / crosshair / “shake to locate” as a control. If the pointer is still lost with those on, the page has replaced the glyph the OS was enhancing.
Where it stops holding
Keyboard, switch, and eye-gaze users do not locate themselves with a pointer. Touch has no persistent pointer; magnification is pinch or system zoom, and the failure becomes finger landing rather than a lost arrow. Larger, better-spaced targets lower the cost of losing the pointer but do not remove the need to see it. Games and canvases that draw their own reticle must supply a high-contrast, scalable one — the OS large pointer will not composite on top.
Applying it
- Do not replace the system pointer unless the new glyph stays obviously larger than the default on light, dark, and forced-colour backgrounds, and still honours OS pointer enlargement.
- Do not hide the pointer during ordinary operations. During drag, keep the pointer or a high-contrast ghost at the same coordinates.
- If a busy, draw, or crop state must change the shape, give that shape contrast and an outline; do not swap in an icon that melts into the background.
- How to check: 8× magnification, pointer trails off. Park the pointer on a toolbar, body text, a photo, and a dialog. Any shot where the arrow cannot be named is a loss site. Then drag something and confirm that throughout, the user can still say where the next click lands.
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.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: J2.06 Focus Visibility · J5.13 System Accessibility Settings
- Search terms:
pointer loss·large pointer·custom cursor magnification
Cards in the same group
- J2.07.1Magnification shrinks the visible field to a tiny viewport
- J2.07.2Scattered related elements force pan-and-search
- J2.07.3A cue must sit next to the element it belongs to
- J2.07.5Hover menus can open outside the magnified window
- J2.07.6Some low-vision users rely on color, not zoom — both paths must work
- J2.07.7Dynamic content is missed unless the magnified view is cued