Kiosk Readiness Check Guide

A reference for the DeskTest.net Kiosk Readiness Check. Explains what the tool checks, how to read the verdict, and how to close each gap before you stand up a tenant-facing kiosk - a leasing-office lobby screen, a self-storage rental terminal, or any always-on signage. The short version: a locked-down kiosk needs Chrome or Edge in kiosk mode, and this tool tells you in about twenty seconds whether the machine in front of you can deliver that.

Open the Kiosk Readiness Check →

What does the Kiosk Readiness Check test?

Two steps, each behind a button, because the browser only grants these capabilities in response to a real click. Nothing runs on page load, and nothing leaves the tab.

1. Display: stays awake and fills the screen. Requests a screen wake lock with navigator.wakeLock.request('screen'), then enters fullscreen with the Fullscreen API, holds it briefly to prove it can stay there, and exits. This answers "will the display stay lit and full-screen with no one touching it?"
2. Lockdown: captures keys and detects an idle user. Tests navigator.keyboard.lock() (can it trap Esc and system key combos - Chromium only), verifies the right-click menu can be suppressed, and reads the autoplay policy. It then offers an optional, permission-gated Idle Detection check (Chromium only) so the kiosk can auto-reset when a tenant walks away.

Each capability is reported on its own row: Works, Failed, Unavailable (the API is not in this browser), or Partial. The verdict at the top rolls them into a single go/no-go.

When should I run this?

• Before you deploy a kiosk. Run it on the exact machine and browser that will sit in the lobby. A pass here means the browser can do its part of the lockdown.
• Evaluating a browser or device for signage. Compare candidates: a cheap Android tablet in a webview will fail keyboard lock and idle detection, while Chrome or Edge on a mini-PC passes everything.
• After an OS or browser update. Updates can change Permissions-Policy defaults, reset kiosk profiles, or flip the autoplay policy. Re-run to confirm the terminal still locks down.
• Triaging a kiosk that "went to sleep" or "let someone out of the app." The report pins whether it was the wake lock, fullscreen, or keyboard lock that the browser could not deliver.

Reading the verdict

The verdict panel gives one of three outcomes, plus a likely cause and a recommended next step:

• Kiosk-ready (green). The wake lock, fullscreen hold, and keyboard lock all work. This browser can keep the display awake, full-screen, and trap Esc. Add the optional idle-detection check if you need auto-reset.
• Partially ready (amber). Some controls work and some do not. The most common case: a non-Chromium browser holds the display fine (wake lock plus fullscreen) but lacks Keyboard Lock and Idle Detection, so it cannot trap Esc. Fine for display-only signage, not for a locked-down self-serve terminal.
• Not kiosk-ready on this browser (red). None of the core capabilities worked - typically an in-app webview, a very old browser, or one restricted by policy. Move to Chrome or Edge in kiosk mode and re-run.

Copy Diagnostic Report writes a plain-text summary - browser, platform, and a Works / Failed / Unavailable line for every capability - to the clipboard. It contains capability results only, no screen contents. Paste it into a ticket or a deployment checklist.

The capabilities, one by one

Screen wake lock

The Screen Wake Lock API keeps the display from dimming or sleeping while the page is active. The tool acquires a 'screen' lock, confirms it, holds it briefly, and releases it. Supported in Chrome, Edge, and Firefox (126+), and in Safari 16.4+. If it is Unavailable, fall back to the OS power plan: set the screen and sleep timeouts to Never so the display stays on regardless of the browser.

Fullscreen hold

The Fullscreen API (requestFullscreen) makes the page fill the screen and hides browser chrome. The tool enters, waits for fullscreenchange, holds, then exits with exitFullscreen. It is supported nearly everywhere, so a Failed here usually means a Permissions-Policy (fullscreen) is blocking it or the page is inside a restricted iframe. In production, kiosk mode starts fullscreen automatically so you do not depend on a click.

Keyboard lock (Esc capture)

The Keyboard Lock API (navigator.keyboard.lock()) lets a fullscreen page capture keys the browser normally reserves - most importantly Esc, which otherwise exits fullscreen, plus combinations like Alt+Tab on some platforms. It is Chromium-only (Chrome and Edge). Without it, a tenant can press Esc and drop out of your kiosk shell. Note that the lock only takes effect while the page is fullscreen; kiosk mode combines the two for you.

Right-click suppression

Not an API so much as a technique: a contextmenu event handler that calls preventDefault() hides the right-click menu (with its "Save as", "Inspect", "Open in new tab" entries) from tenants. The tool dispatches a synthetic contextmenu event and confirms the handler cancels it. This works in every browser, so it is almost always Works.

Idle detection (auto-reset)

The Idle Detection API (IdleDetector) reports when the user has been inactive and the screen is idle, so a kiosk can reset itself to the home screen after a tenant walks away mid-transaction. It is Chromium-only and permission-gated, which is why the tool puts it behind its own explicit button - clicking it triggers a browser permission prompt. If it is unavailable or denied, fall back to a plain JavaScript inactivity timer (reset the UI after N seconds of no pointer/key events); you lose only the "screen locked" signal.

Autoplay policy

navigator.getAutoplayPolicy('mediaelement') (Chromium) reports whether media can start on its own: allowed, allowed-muted, or disallowed. Signage that plays a welcome video or audio needs allowed. If the policy blocks it, launch the kiosk browser with autoplay permitted (for example Chrome's --autoplay-policy=no-user-gesture-required). On non-Chromium browsers this reads as Unavailable and you should set the flag at launch to be safe.

For IT admins: kiosk mode and OS lockdown

This tool tests what the browser can do. A production kiosk pairs that with launch flags and OS-level lockdown. The usual recipe:

Windows Assigned Access (Settings then Accounts then Other users then Set up a kiosk, or the AssignedAccess CSP via Intune) is the strongest lockdown: it runs a single app for a dedicated account, blocks Ctrl+Alt+Del escapes, and auto-logs-in. Combine it with the browser's own kiosk mode for the app itself. The Kiosk Readiness Check verifies the browser half; Assigned Access handles the OS half.

Behind the scenes

Everything runs in JavaScript on the page - no network requests, no uploads, no tracking. Step 1 calls navigator.wakeLock.request('screen') and reads the returned sentinel's released flag to confirm the lock took, then calls sentinel.release(). Fullscreen is entered on document.documentElement, confirmed by watching for fullscreenchange and checking document.fullscreenElement, then exited. Both are triggered from the button's click so they run inside a valid user activation.

Step 2 calls navigator.keyboard.lock(['Escape']) and immediately unlock()s - the successful call is the readiness signal, since the lock only actually intercepts keys while fullscreen. Right-click suppression is proven by dispatching a synthetic cancelable contextmenu event and checking that a preventDefault handler cancels it. The autoplay policy is read with navigator.getAutoplayPolicy. Idle detection, behind its own button, calls IdleDetector.requestPermission() then starts a detector with a 60-second threshold and immediately aborts it via an AbortController.

Every acquired resource is released: the wake lock on completion and on reset, the idle detector via its abort signal, and fullscreen is exited if the tab is closed mid-test (a beforeunload handler). Chromium-only APIs that are absent report an honest Unavailable rather than a false failure. View source to verify any of this.

Related

• Kiosk Readiness Check - the diagnostic itself
• Display Test - resolution, dead pixels, and color for the kiosk screen
• Touch Test - multi-touch and touch accuracy for a touchscreen kiosk
• Keyboard Test - key-by-key check for an attached keyboard
• Screen Share Test Guide - the display-capture equivalent for video calls
• About DeskTest.net
• Help: getting started
• DeskTest.net home

Elsewhere on the web:

• MDN: Screen Wake Lock API
• MDN: Keyboard.lock()
• MDN: IdleDetector
• Microsoft: set up a single-app kiosk (Assigned Access)