Z8.02.2Public terminal reachabilitydesignresearch

Public terminals must accommodate different heights and physical abilities

Aliases: kiosk accessibility · accessible self-service

What it is

Public terminals — self-service check-in, ticket machines, information kiosks, self-checkout — serve an unspecified population. The design input is not "the average user" but the population's bodily distribution: stature from children through seated eye height of wheelchair users to tall adults; upper-limb reach and fine-motor capability; the full range of vision and cognition. For a public terminal, accessibility is not an add-on but the base function: a ticket machine whose card reader a wheelchair user cannot reach does not exist for that part of the population — and public service is defined precisely by not presupposing exclusion.

The difference from personal devices is that the users cannot be pre-screened. A personal device is bought by a particular person; a public terminal is installed for everyone who comes by. The notion of a "target user" collapses in the public context.

Why it happens

  • Physical geometry decides who can use it at all: screen height, control-panel depth and reader position define the reach envelope. A wheelchair user's seated eye height and reach range (roughly below seated shoulder level, within close forward depth) differ from standing design parameters; lateral approach usually tolerates more variance than head-on. Children and wheelchair users share nearly the same viewing height — a low screen and low camera serve both at once, a free win from geometry.
  • Channel redundancy decides who can understand it: a single "vision + touchscreen" channel excludes blind users, presbyopic users, and everyone facing glare; headphone jacks, physical keys, audio output and height adjustability are channel redundancies — each to be validated independently (a headphone jack does not guarantee a working screen reader).
  • The one-shot user structure decides who can learn it: public terminals accumulate no returning-user learning curve; every use is a first use. Instructions must be self-explanatory, one task per screen, errors recoverable — cognitive accessibility is an axis parallel to physical accessibility, and testing only the physical one misses half the exclusion.

Studying it

  • Anthropometrics and ergonomics data: design data for wheelchair reach bands, seated/standing eye height and reach depth are mature in accessibility engineering standards (public-facility accessibility dimensions, universal-design guidance) and serve directly as design constraints.
  • Accessibility audits: evaluations of transit and municipal self-service terminals commonly use the standard-task method — members of different ability groups (wheelchair users, blind and low-vision users, older adults, children) complete core tasks while completion rate, time, assistance requests and sticking points are recorded.
  • Compliance mapping: item-by-item checks against accessibility regulations and standards (signage, heights, clear floor space, audio output) producing a gap list.

Methodological caution: proxy testing does not replace real groups — lowering a screen to "simulate a wheelchair" tests geometry, not the compound constraints of a real user's approach path, transfer and one-handed operation. Completion rates must come from real groups at real terminals.

Where it stops holding

  • Adjustable mechanisms are not a universal answer: a height-adjustable screen serves the stature distribution but adds failure surfaces, lengthens each use, and fares worse unattended outdoors; a fixed low primary screen with audio redundancy is often more robust in rough environments. Adjustability is an option, not the default answer.
  • Audio redundancy is bound by ambient acoustics: in noisy public space the audio channel itself is unreliable and cannot be the sole alternative counted on.
  • No single machine serves the full spectrum: pushing one terminal to satisfy everyone drives its parameters into mutual conflict (low enough for wheelchair reach vs high enough for standing readability). A terminal cluster at the space level — several machines at different heights plus one staffed position — usually beats loading one machine with functions.
  • The cognitive and perceptual mechanisms of accessibility in general (screen readers, contrast principles) have their own entries in the accessibility domain and are not repeated here; this entry stays with the geometry, redundancy and deployment structure specific to public terminals.

Applying it

  • Place key operating parts (card reader, confirm key, emergency stop, ticket slot) within the wheelchair reach band; split the main sightline between seated eye height and standing overcast angle — a screen tilted slightly forward serves seated users and cuts glare at once.
  • Provide at least one non-touchscreen channel: physical-key navigation, audio plus a physical confirm key, or a staffed assist bell; mark redundant channels in fixed, blind-findable positions.
  • Follow the one-shot user assumption: one task per screen, visible progress, errors step back rather than reset, timeouts give explicit help directions rather than silent restarts.
  • How to check: have wheelchair users, low-stature children (or seated simulation), and presbyopic or low-vision users each complete core tasks, recording completion, assistance and sticking points; test screen legibility once in harsh daylight and once at night. Any group completing markedly below baseline is the evidence of exclusion on that axis.

Related

  • Same group: Z8.02.1 Touchless interaction reduces contact transmission and queuing costs · Z8.02.3 Voice and gesture recognition degrade in noisy public settings · Z8.02.4 A missing human fallback channel turns failure into total service outage
  • Nearby: Z8.06 Accessibility requirements for public facilities · the accessibility domain for general mechanisms
  • Search terms: kiosk accessibility · reach range · universal design · accessible self-service

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Z8.02.2