A hotspot is the single reference location within a cursor graphic

What it is

A cursor hotspot is the one pixel or coordinate within a cursor graphic that the system treats as the actual pointer location. Click, hover, and drag hit testing use the hotspot rather than the whole graphic. An arrow normally uses its tip so it can indicate small objects without covering them.

Why it happens

Input supplies one coordinate, which the system binds to the graphic's hotspot before hit testing. The graphic may change size or shape with state while the pointing expectation remains stable if the hotspot does not move. Without a fixed reference, visual cursor movement and event location diverge.

Putting the hotspot at the tip rather than the graphic's centroid is a usability trade-off — it lets the cursor point at a target instead of covering it — and the price is that the hotspot has to be declared and maintained as metadata separate from the graphic, not inferred by looking at the image. That separation is exactly where the common bug lives: image editing, export, and scaling tools generally operate on the bitmap and know nothing about the hotspot coordinate. Once an asset gets re-exported, cropped, or regenerated at another resolution, the hotspot is easy to leave out of sync — the graphic looks unchanged, but where clicks land quietly shifts.

Studying it

Vary hotspot position, cursor size, and target width; measure selection error, movement time, and first correction. Include corners, small controls, and drag origins, since large central targets conceal configuration errors.

The same problem also fits Fitts' law: a hotspot that systematically diverges from where people visually aim behaves, in effect, like a smaller effective target width W. Running a reciprocal tapping task (ISO 9241-9) with a deliberately introduced, known hotspot offset and comparing the resulting drop in throughput turns "an offset too small to notice" into a reportable number.

Where it stops holding

Touch ordinarily hits with a contact region or inferred contact point, not a visible cursor hotspot. Magnifiers, assistive pointers, and remote control can introduce an offset proxy point and must state where the actual hit occurs. Platforms may also use different pixel-coordinate conventions.

A multi-resolution asset pipeline is a concrete failure case: the hotspot coordinate is annotated at one baseline resolution, and if @2x, @3x, or other scaled variants do not carry the hotspot forward at the same ratio, different screen densities end up with different-sized offsets — often visible only on the higher-density devices where the discrepancy is large enough to notice. Remote-desktop protocols that transmit the cursor graphic and its hotspot coordinate as separate channels can also produce a misalignment between the client-rendered bitmap and the server's notion of the hit point, reproducible only inside a remote session.

Applying it

• Define and preserve a stable hotspot for every pointer state, especially across loading, drag, and disabled states.
• Use a debug visualisation of hotspot and hit point to catch drift after asset scaling.
• Automate edge and tiny-target clicks to verify event coordinates equal the designed hotspot.
• After every static asset export, run an automated check that reads the hotspot field embedded in the cursor file and compares it against the design-specified coordinate, so an export or compression tool cannot silently rewrite it.

Related

• Same group: C1.05.2 A cursor's visual centroid and hotspot can create systematic offset · C1.05.3 A hit region can exceed its visual region · C1.05.4 Overlapping hit regions need explicit priority rules
• Nearby: C1.01 Types and properties of pointing devices · C1.08 Drag and drop
• Search terms: cursor hotspot · hit testing · pointer coordinates