DeskTest.net
GitHub

Touchscreen Test Guide

A reference for the DeskTest.net Touchscreen Test. Covers how it detects touch, maps whether the whole screen responds, and checks multi-touch, how to read the verdict, and what to do about dead zones, unresponsive touch, and single-touch panels.

Open the Touchscreen Test →

What does the Touchscreen Test check?

The tool drives the browser's PointerEvent API as its primary path: pointerdown, pointermove, and pointerup listeners keyed off pointerId so each finger is tracked independently. Where PointerEvent is missing (older Safari) it falls back to Touch events keyed off Touch.identifier. No plugin, no extension, no upload. Works on Chrome, Edge, Firefox, and Safari. The three steps run in order:

  1. Touch input is available. Reads navigator.maxTouchPoints (how many fingers the digitizer can track), 'ontouchstart' in window, the matchMedia('(pointer: coarse)') and '(any-pointer: coarse)' media queries, and whether PointerEvent is supported. If maxTouchPoints is 0 and there is no touch-start support, this device has no touchscreen; the step reports that as an informational result, not a hard fail, because a mouse or trackpad is not a touchscreen.
  2. Touch points register across the screen. A large capture area is divided into a grid of cells. As you tap and drag, each active touch is drawn and the cell under it turns green. A cell left gray is a spot the digitizer never reported - the classic dead zone. The tool records the number of distinct touches and the peak number of simultaneous touches seen. Full coverage passes; some cells missing reports as a partial; no touch at all fails.
  3. Multi-touch works. Derived from the same capture: the most simultaneous touches observed at once. Two or more means multi-touch (pinch, rotate) works. One means single-touch only, which is normal for many kiosk and POS panels and is reported informationally, never as a hard fail.
Important: Run this on the touch device itself. Opening the page on a desktop with only a mouse will correctly report "no touchscreen" - the tool is checking the device the browser is running on, not a screen plugged in elsewhere.

When should I run this?

Reading the results

The capture grid fills each cell green the first time a touch lands in it. The Area covered meter and the Cells covered figure show how much of the area responded; a cell left gray after you have dragged into it is a dead zone. Distinct touches counts every touch-down, and Peak at once is the most fingers tracked simultaneously.

Each step row carries a status badge: Pending (gray), Running (yellow), Pass (green), Partial (yellow), or Fail (red). The touch-coverage step passes on full coverage, reports Partial when some cells never registered, and Fail when no touch registered at all. The multi-touch step reports Pass at two or more simultaneous touches and Partial for single-touch - never a fail, since single-touch panels are legitimate hardware. The support step reports Partial when no touchscreen is present. On fail or partial the row expands with the diagnosis and a numbered checklist, and the verdict panel at the top names the most likely cause and a recommended next step.

Copy Diagnostic Report copies a plain-text report: browser user-agent, platform, input mode (PointerEvent or TouchEvent), maxTouchPoints, the touch feature flags, distinct touches, cells covered out of the total, the peak simultaneous touches, and the diagnosis tag from each step. Paste it into a ticket.

Common failures and fixes

The tool produces a named diagnosis for every failure path. Each maps to a fix. In step order:

no-touchscreen: no touch input on this device

The browser reports maxTouchPoints = 0 and no touch-start support, so there is no digitizer to test. A mouse or trackpad is not a touchscreen: it moves a single cursor and cannot report a physical touch point or two fingers at once.

  1. If this should not be a touch device, there is nothing to fix - open the test on an actual touchscreen instead.
  2. If this is a touch device (an all-in-one, 2-in-1 laptop, kiosk, or POS terminal), the digitizer is likely disabled or missing its driver. On Windows, open Device Manager → Human Interface Devices and look for an HID-compliant touch screen entry. If it is disabled, enable it; if it has a warning icon, reinstall or update the driver.
  3. Confirm touch is not switched off in firmware or a vendor utility. Some convertibles disable touch in tablet/laptop mode transitions.

no-touch-registered: touchscreen present but nothing registered

The device advertises a touchscreen, yet no touch reached the page during the capture. Rule out the simple causes before suspecting the panel.

  1. Check for a physical barrier: a thick or misapplied screen protector, a case lip over the edge, water, or grime. Clean the screen with a dry microfiber cloth.
  2. Use a bare fingertip. Gloves and non-conductive styluses do not trigger a capacitive panel.
  3. Reboot. A hung digitizer controller very often clears on restart.
  4. On Windows, confirm the HID-compliant touch screen driver is enabled in Device Manager. If touch fails on the OS home screen too - not just in the browser - the digitizer or its ribbon cable has failed and needs service.

dead-zones: part of the area never responded (partial)

Touch worked, but some grid cells stayed gray even though you dragged across them. That patch of screen is a dead zone.

  1. Re-run and drag slowly through the gray cells. A cell can be missed simply because your finger jumped over it, so confirm the gap is real before treating it as a fault.
  2. Remove any screen protector or case and retry. A bubble or lifted film under the glass is the most common cause of a localized dead strip.
  3. If the same region stays dead across reboots and in other apps, the digitizer layer is physically damaged there. On a laptop or all-in-one this means a panel or digitizer replacement.
  4. On a large touch display, a dead edge can be a loose digitizer ribbon connector. Reseating it (or an authorized service call) may recover it.

single-touch: only one touch at a time (partial, not a fault)

Touch works everywhere, but only a single point was ever tracked. For many industrial, POS, and kiosk panels this is by design and is not a failure.

  1. If the digitizer advertises more than one point (see maxTouchPoints in the report), try again and place two fingers down together, well apart, and hold. If a second point never appears, a vendor touch utility or a "single-touch" mode may be capping it.
  2. If maxTouchPoints is 1, the hardware is single-touch and multi-touch gestures are simply not supported. That is fine for standard tap-and-drag use.
  3. Multi-touch is not required for a healthy screen. Only chase this if users actually need pinch-to-zoom or two-finger gestures.

For IT admins

Touch behavior is governed at three layers: hardware (the digitizer and its cable), OS (the HID touch driver and any touch settings), and per-app (the browser and any vendor touch utility). The test sees the last layer's view, but the failure pattern points at the layer to fix.

HID touch driver. On Windows the panel presents as an HID-compliant touch screen under Human Interface Devices. A feature update or a bad OEM driver push can disable it or leave it in an error state, which reads here as no-touch-registered on a device that clearly has a screen. Baseline your image with the correct digitizer driver and watch for updates that regress it.

Screen protectors on shared terminals. Kiosks and POS units get protectors swapped by field staff. A protector that is too thick, misaligned, or bubbled produces edge and corner dead zones - the dead-zones diagnosis. Standardize the protector part number and train staff to squeegee out bubbles, especially along the edges where UI buttons live.

Single-touch by design. Many resistive and older industrial capacitive panels are single-touch. Do not treat the single-touch result as a fault on that hardware; record the expected touch-point count per device model so a genuine multi-touch regression is distinguishable from normal single-touch hardware.

Ghost touches and calibration. This tool confirms that a region registers touch; it does not measure where the touch lands versus where you touched (calibration) or catch phantom touches that fire with no finger present. Ghost touches usually trace to a failing digitizer, a bad ground, or a noisy charger - swap the power supply first. Calibration drift on resistive panels is fixed in the OS touch-calibration applet.

Kiosk shells and iframes. A locked-down kiosk browser or an embedding iframe can swallow or reinterpret touch (for example, forcing everything through emulated mouse events). The report notes whether the page is in an iframe. When a kiosk misbehaves, test the same URL in a full browser tab on the same device to separate a shell problem from a hardware one.

Behind the scenes

The tool uses Pointer Events as its primary path because they unify mouse, pen, and touch and expose a stable pointerId, so each finger in a multi-touch gesture is tracked independently. Where PointerEvent is unavailable it falls back to the older Touch Events API and keys off each Touch.identifier in event.touches. The report notes which mode was used.

The capture area is a <canvas> with touch-action: none set in CSS, so a drag paints instead of scrolling or triggering the browser's pinch-zoom. On the pointer path the canvas calls setPointerCapture() on each pointerdown so it reliably receives the matching pointerup even if the finger drifts off the element.

Coverage is tracked by dividing the area into a fixed grid and recording the index of every cell a touch passes through. Because coverage is stored by cell index rather than by pixel, rotating the device or resizing the window does not lose what you have already covered - the canvas is simply re-measured and repainted. The peak simultaneous-touch count is the maximum size of the active-pointer set (or event.touches.length on the fallback path) seen at any instant during the capture.

Nothing leaves the browser tab. No touch coordinates are logged to a server, no telemetry beacon is fired, no analytics. The report is built on Copy from in-memory state, and the page discards everything on reload. Open DevTools, Network tab, and confirm: no outbound requests while the test runs.