Kiosk session reset and privacy: make the next visitor truly new

Define reset as several separate actions

A reset is not the same as hiding a chat bubble. Inventory every surface: visible transcript, speech buffer, caption history, camera preview, microphone state, downloads, uploads, browser storage, server session, queued work, accessibility focus, and avatar state. For each, name whether it is cleared, retained under a documented policy, or handed to an authenticated account. The safest shared-device default is no personal persistence unless a specific service flow requires it.

The avatar must not imply continuity after reset. An idle animation, remembered greeting, or personalized prompt can reveal that a prior session existed even if the main transcript is gone. Start the next session with generic state and no authority inherited from the previous visitor.

Warn, extend, or end clearly

Before inactivity causes a loss of unsaved work, give a visible and accessible warning with a countdown, an extend option, and an end-now option. Do not rely on an animated avatar or a fading screen to communicate the deadline. If the kiosk has no safe extension because it is public, say so plainly and offer a way to begin again. End-session should be available at all times, not only after a timer.

Worked example, hypothetical: a museum guide displays “This private session ends in 30 seconds. Continue or end now.” Choosing End clears the transcript, stops audio, hides uploaded image previews, returns focus to the start button, and invalidates its short-lived session token. The next screen does not show “welcome back” or retain the selected language as a personal profile.

Revoke authority before presentation reset

A delayed cleanup job is not sufficient for a shared device. Server-side action authority and tool tokens must expire or be revoked at the reset boundary, even if a network call arrives late. Cancel or mark outstanding requests so their response cannot redraw the old session after the start screen appears. If an external action has unknown outcome, show no claim of cancellation; route the case through its accountable service instead.

The counterexample is a kiosk that clears text locally but lets a late booking confirmation render under the next visitor’s session. Another is a reset that deletes cookies while a valid server session continues. Presentation, local state, and authority need independent checks.

Give operators a repeatable test

Write a reset test that uses a non-production test account or harmless fixture. Enter a sample message, start media, navigate away, wait for timeout, and begin a new session. Confirm no transcript, preview, download, caption, chosen identity, authenticated route, or late response reappears. Test explicit end, inactivity end, browser refresh, network loss, and power restart. Record device, software version, date, and failed surfaces.

Acceptance checks: reset can be invoked without hidden gestures; timeout warning is perceivable and operable; new sessions begin unauthenticated; and an operator can demonstrate the full clear path. A visual reset alone does not pass.

Physical check. Include headphones, external display, printer, and accessibility hardware in the operator walk-through. Privacy failure can remain outside the browser after the web session clears.

State the policy limits

WCAG discusses warning users about inactivity that could cause data loss and re-authentication without loss of data in certain contexts. Those criteria do not dictate a kiosk retention policy or prove compliance with privacy law. Public-device risk depends on location, operating system, browser configuration, media devices, and service architecture.

This article offers a practical control inventory, not legal advice or a guarantee that data was erased from every backup or external system. Privacy and security owners need to define retention, incident response, and physical-device controls. The operator test is evidence of one observed reset, not certification.

The reset test should include going back through browser history, reopening a recently closed tab where that is possible, waking a locked display, reconnecting a headset, and attaching a previously paired accessibility device. These are not instructions to weaken a kiosk; they identify surfaces the deployment owner must configure or block. Record any platform control that lies outside the web application, because an application-only checklist cannot prove the device is safe for public handoff.

Operators should repeat the test after browser, operating-system, accessibility-device, and kiosk-shell updates. A reset path can regress through configuration outside the application. Keep an owner for each device-level control so a failed physical check has a repair route rather than an ambiguous application ticket.

Treat accessibility preferences carefully

A shared device may apply language, volume, contrast, or reduced-motion settings during a session. Decide whether each resets, persists as a device accommodation, or is restored by managed policy. Never treat a preference as identity.

A reset that clears all preferences without an accessible path back can harm the next visitor; a reset that retains personal selections can expose them. Test this distinction alongside transcript clearing.