An event touchscreen brief should cover more than button size. It should identify who must use the experience, where the screen will sit, how people start and finish, and what route exists when touch is difficult or unavailable. For a browser-based interface, the W3C Web Content Accessibility Guidelines (WCAG) 2.2 provide testable digital criteria. They do not by themselves certify the physical mounting, aisle, lighting, or venue.
Specify the task before the interface
Write the essential action in plain terms: “choose one option and receive a result,” “find a product and send it to my phone,” or “enter a competition.” Then separate decorative actions from actions needed to complete that task. A visitor who cannot drag, reach, hear, or stand for long should still have a route to the essential result. That may mean an equivalent on-screen control, keyboard or switch input, a lower accessible station, or a staff-assisted route. The actual solution must be tested with the intended users and venue.
For web content, WCAG 2.2 requires keyboard operation for functionality unless the underlying function truly depends on the path of movement. Its Level AA dragging criterion asks for a single-pointer alternative to dragging where applicable. A “swipe to begin” screen should therefore also be examined as an action that could be started another way. W3C, keyboard operation; W3C, dragging movements.
Design controls for the event context
WCAG 2.2 Level AA includes a minimum target-size criterion of 24 by 24 CSS pixels, with specified exceptions and spacing rules. That is a web-content threshold, not a sensible default for a large public touchscreen viewed at arm's length. Specify generous physical targets, visible focus, readable contrast, and enough separation between “confirm” and “cancel,” then test at the installed screen size. W3C, target size minimum.
If the interaction advances or clears itself on a timer, decide whether the limit is essential. WCAG's timing criterion generally requires a way to turn off, adjust, or extend a time limit, subject to its exceptions. A public kiosk also needs a reset so the next visitor does not see the previous visitor's information. Those needs can conflict; test a session-warning and reset design rather than silently ending a task. W3C, timing adjustable.
Review the physical journey separately
Walk the real route from aisle to screen, not just the interface mockup. Check whether a seated visitor can approach, see content without glare, reach the controls, wait without blocking movement, and leave without crossing the queue. Check whether audio is the only way to understand the result and whether captions or visual equivalents are provided. The event organizer and venue should review the physical setup against applicable local requirements; this article cannot set a universal reach height or legal compliance standard.
The UK Health and Safety Executive's event guidance warns against attractions blocking pedestrian routes and emphasizes monitoring queues and movement. It is a useful planning prompt for the venue review, not an accessibility certification. HSE, crowd controls inside the venue.
Make acceptance observable
Ask the supplier to demonstrate the core task with touch and an alternative input, show the timer and reset behavior, and test the installed screen in real light and noise. Record which parts meet WCAG criteria for the web interface and which physical-access questions have been checked by the venue team. “Accessible” without a stated scope and test is too vague for an acceptance decision.
Archv's website and digital work and interactive-event work can meet in one kiosk. The brief should make both the digital and physical responsibilities visible before a visual concept is approved.