Introduction: operational stakes
Deploying an AI avatar on a kiosk or screen in a public place requires ensuring access for people with visual, auditory, motor or cognitive impairments, without sacrificing multilingual quality or 24/7 availability. This guide aims to transform general principles into concrete elements to include in the specifications, the pilot and the operational runbook.
Project managers, IT leaders and accessibility teams will find here: the relevant regulatory framework, technical criteria to verify, UX recommendations for conversation and interface, a test protocol for users with disabilities and a ready-to-use audit checklist.
Regulatory framework and application of the WCAG
Web accessibility standards such as WCAG provide a relevant technical framework for kiosk interfaces. In practice, this means applying principles such as alternatives for media, keyboard operability, visual readability and robustness.
Before deployment, check which obligations apply locally to your project (national regulation, public procurement, internal policies). Concrete requirements may vary depending on the type of venue and the status of the organization. Consider WCAG as a technical guide that your interface must translate into design rules and acceptance criteria.
Essential technical criteria for the kiosk interface
Compatibility with assistive technologies depends as much on the interface software as on the hardware and integration. To ensure interoperability with screen readers and assistive technologies, require that the interface follows concrete principles: clear semantic structure, accessible labels, logical tab order and visible focus indication.
Other technical points to include in the specifications: full keyboard navigation support, resizable text without loss of functionality, visible contrast, text alternatives for non-text content and multiple input modes (touch, voice, keyboard entry).
Screen reader compatibility and response structure
For a screen reader to correctly announce the content produced by the avatar, the interface layer must expose textual elements and relevant ARIA attributes. Provide textual outputs equivalent to spoken messages so that a blind or low-vision user can access the same information.
During integration, test the readability of short responses and the clarity of labels. Avoid purely iconographic or animated presentations without a text alternative. The screen architecture should allow the visitor to quickly identify the session state (waiting, in progress, result).
Voice interaction, hard-of-hearing users and visual alternatives
Voice interaction is essential for many use cases, but it must always be accompanied by a visual alternative. Provide a visible text input field, a tactile virtual keyboard and clear control buttons to start, stop or repeat an interaction.
Captioning and real-time transcription improve accessibility for hard-of-hearing users. These functions generally require a specific integration with an STT/transcription service and a subtitle display component. It is therefore useful to anticipate these needs in the specifications and plan the necessary APIs or webhooks.
Physical ergonomics and kiosk placement
Physical accessibility depends on the choice of location and hardware ergonomics: positioning allowing wheelchair access, sufficient support surface, screen tilt, readability from different angles and glare protection. These aspects depend on the chosen hardware and site constraints.
Also consider seated vs standing use cases, the presence of an armrest or support surface for input, and clear signage to guide users to the kiosk. Microphone and speaker quality affects the smoothness of voice interaction and must be taken into account in tests under real conditions.
Cognitive accessibility and conversation design
Adapting conversational design for people with cognitive impairments involves plain language, short sentences, limited choices and step-by-step assistance. Provide simple confirmations and easy options to retry when the avatar did not understand.
The avatar persona should remain predictable and consistent. SANIA can be customized according to the client's activity and needs, enabling adjustments to tone, speech rate and vocabulary complexity according to the target audience.
User testing protocol with people with disabilities for an operational pilot
An accessible pilot includes user tests with people who have visual, auditory, motor and cognitive impairments. Define precise test objectives: validation of keyboard navigation, comprehension of spoken and textual responses, usage under real noise conditions and evaluation of physical signage.
Organize representative scenarios (examples: find a simple piece of information, ask for directions, change the language). During each session, collect qualitative observations, note interruption points and request feedback on ease of use and comprehension. Plan tests in several languages if the site receives a multilingual audience.
Operational audit checklist ready to use
This list can be integrated into the specifications and used during the pilot and operations. It covers interface, voice, hardware and testing.
Presence of an accessible text mode equivalent to every spoken message.
Complete keyboard navigation and logical tab order on the interface.
Clear labeling of controls with accessible attributes (ARIA) and visible labels.
Visible focus indication and explicit state feedback (playing, waiting).
Sufficient touch target sizes and easily reachable input zones.
Color contrast compliant with WCAG recommendations for main text and interactive elements or, failing that, highlighting of visual alternatives (icons accompanied by text). Note that precise ratios are defined by WCAG and should be consulted according to the conformity goal chosen by the organization. Here is an operational point: test the interface under varying lighting conditions to validate real readability.
SANIA configuration examples and items to specify in the requirements
Here are three illustrative configurations and the elements to specify in the requirements. Note: some functions require specific integration and are not automatically provided without development.
Configuration 1 - touch and accessible text interface: SANIA is deployed on an interactive screen/kiosk with a touch interface and full text outputs. Characteristics to define: keyboard navigation, ARIA labels, focus management, adaptable font sizes. Notes about SANIA: the avatar can be used with a touch and text interface and uses an organization-specific knowledge base.
Configuration 2 - adding voice interaction: SANIA provides voice interface and speech synthesis. Specify in the requirements the handling of voice interruptions, language switching in session and the required quality for microphones and speakers. Notes about SANIA: SANIA can communicate in more than 100 languages, can operate 24/7 and can handle interrupting a spoken response when the user speaks again.
Configuration 3 - enhanced accessibility (captioning and transcription): to offer captions or real-time transcription, plan a specific integration with an STT service and a subtitle display component. Specify APIs, acceptable latency and fallback modes if the transcription service is unavailable. This layer is an integration and requires defining responsibilities between stakeholders.
Watch-outs and common mistakes
Do not limit accessibility to voice interaction alone: a kiosk must always offer textual and tactile alternatives. Avoid considering speech recognition as a universal solution without planning fallback scenarios.
Do not confuse software accessibility with hardware accessibility. Inadequate hardware choices (screen unreadable in bright sunlight, poorly positioned microphone) can make a well-designed software interface ineffective.
Finally, do not assume compliance: include the concerned people in the pilot and document the choices made to be able to justify them in case of an audit.
In practice: preparing the pilot and the operational runbook
Integrate accessibility criteria from the drafting of the specifications and plan real-condition tests before general rollout. Define operational review points to verify the availability of voice and transcription services when these are integrated.
Document hardware and software maintenance procedures, contacts for third-party services (e.g. STT provider), and degraded-mode scenarios (text-only mode if voice is unavailable). Finally, provide a clear instruction to direct visitors to human assistance when the avatar cannot respond.