The next visitor should see a clean invitation, not the previous person's name, answers, photo, score, language choice, or unfinished form. A public screen changes hands without a formal logout. That makes the end of each interaction a design decision as well as a technical one.
First decide what a single visit owns. A product quiz might hold three answers and a recommendation. A competition may add a nickname and score. A photo experience may create an image, a download link, and an email request. Write these states down before deciding what “reset” means. The general accessible event touchscreen brief mentions reset alongside timing; this is the separate acceptance test for what remains visible and stored after a visitor leaves.
Map each state to an end rule
Use a small handoff register for every field or file:
| State | Where it may appear | End-of-visit question |
|---|---|---|
| Current answers and result | Screen and browser memory | Does the next visitor see any of it? |
| Contact detail or photo | Browser, server, email or print queue | What is the approved purpose and retention rule? |
| Session identifier | Browser and server | Is the old session invalidated? |
| Operational count | Analytics or event report | Can it be kept without exposing a person's response? |
The table is an Archv planning tool, not a legal retention schedule. An organizer should decide the purpose and applicable privacy requirements for information it actually collects. A visible reset does not prove that stored information has been cleared. OWASP's session management guidance distinguishes browser-side state from server-side session invalidation and notes that cached content can survive the end of a session. Its browser storage testing guide identifies local storage, session storage, IndexedDB, and cookies as places to inspect. These are web-application controls; an installation may also have camera, printer, or local-device files.
Design two ways to finish
Give the visitor an explicit Finish or Start again action. Also decide what happens when they walk away mid-task. An idle timeout can return the screen to the invitation, but it should warn a visitor before erasing work that takes time to complete. For browser-based content, WCAG 2.2's timing guidance addresses when a time limit needs to be turned off, adjusted, or extended and its exceptions. A public device still needs a practical turnover rule. Review the two requirements together for the actual interaction.
Reset the public view immediately at a completed handoff, and agree a separate cleanup rule for any stored data. The screen need not display a guest's contact detail after submission to prove that a message was sent. A neutral receipt such as “Your result was sent” can close that task without leaving the address on view. Where a saved result is needed, a short-lived personal link or staff-controlled retrieval route should be specified and tested as a project choice, not assumed safe by default.
Run the next-visitor test
Have one tester enter realistic dummy data, leave at four points, and let a second tester approach each time: after completion, during an unfinished form, after an idle warning, and after a browser or device restart. Check the screen, back button, print queue, download history, and the operator's recovery path. Ask a developer to inspect browser and server state as appropriate. Record what is retained, by whom, and for how long.
This test has a clear pass condition: the second visitor cannot retrieve the first visitor's result through the ordinary public route. It does not certify a system's legal compliance or security. If the installation also uses cameras, the separate camera-based visitor notice guide covers what people should understand before capture begins.