Introduction: why address accessibility from design

Accessibility for a reception AI avatar installed on a screen or kiosk must be considered an operational requirement, not an aesthetic option. Beyond regulatory considerations that vary by context, the aim is to ensure that people with low vision, hearing impairments or specific cognitive needs can access information and interact autonomously and respectfully.

This guide provides concrete, testable recommendations to design the experience, prepare content, test the avatar and organise its operation. It builds on UX principles applicable to any physical device and on SANIA’s configurable capabilities, such as hybrid touch/voice interaction, voice personalization and multilingual support.

Core UX principles for an accessible device

Start by defining accessibility priorities according to the audience frequenting the site. The objective is not universal technical perfection, but to identify the main barriers and address them pragmatically.

Adopt a multimodal approach: offering several access routes to information (voice, text, touch, video) provides alternatives in case of sensory or cognitive impairment. For a reception AI avatar, a hybrid touch/voice mode is often relevant because it lets users choose the interface that matches their abilities and preferences.

Prioritise readability and simplicity: short messages, plain language and structuring responses into steps when information is dense. Provide slow, adjustable speech sequences and a synchronized text version (captions) for people who are hard of hearing.

Interface design: touch, voice and multimodal alternatives

Decide in advance the functional scope that will be accessible. A touch screen may suit many users, but adding voice interaction serves people who find touch manipulation difficult. SANIA can be configured to operate in voice interaction, touch interface, or hybrid mode depending on the chosen setup.

For voice, provide accessible controls for volume, speed and pitch. Voice personalization is a configurable option useful to improve comprehensibility. Avoid long messages read in one go: structure responses into segments and offer the user the option to hear the next segment.

Consider non‑voice alternatives: enlarged text display, high contrast, large tactile buttons and step‑by‑step navigation. In some contexts, offering a QR code to an accessible web page or mobile app can be a complementary option, provided its use is clearly explained on screen.

Captions, transcription and sign language: technical options to configure

Real‑time captions and transcription are important levers for people with hearing impairments. SANIA can be configured to use voice‑to‑text engines to generate transcriptions or captions synchronized with speech, subject to integration of the chosen services.

Caption display must follow ergonomic principles: readable font size, good contrast, stable on‑screen position and coherent sentence breaks. It is important to allow users to enable/disable captions and to offer a persistent text version if needed.

For sign language, options exist but require specific integration: either displaying pre‑recorded interpreter videos for frequent responses, or triggering a remote interpreter via an external integration. Present these possibilities as functions to be configured according to the project and the site’s connectivity.

Preparing the knowledge base and content for accessibility

Clear, structured and up‑to‑date content facilitates accessibility. Write business responses in simple sentences, favouring direct phrasing and short alternatives. Identify frequent questions and prepare scripts readable both aloud and in text.

Organise content in reusable modules: a short answer for the screen, an expanded version for voice, and a condensed version for captions. SANIA’s knowledge base can consume these business contents. Indicate the textual variants intended for captions versus voice output.

Consider linguistic accessibility: SANIA’s multilingual capability allows responses in the user’s language, but content quality and accuracy in each language should be verified by native reviewers when possible.

Test protocols: users, scenarios and automation

User testing is essential. Recruit people with varied needs (visual impairment, low vision, deafness, cognitive disorders) to test representative journeys: accessing simple information, making a complex request, using the system in a noisy environment, or deliberately interrupting the speech.

Define concrete, measurable scenarios: for example, find information X within a given number of steps, understand the response without external help, or activate captions. During tests, observe friction points, tactile target sizes, message clarity and interface responsiveness.

Complement user tests with targeted automated checks: verify presence and readability of captions, screen contrast tests, validation of transcription files produced by the voice‑to‑text engine. Remember that automation can check for element presence, but cannot replace real user feedback.

Metrics and measurement method to manage accessibility

An organisation can choose operational indicators to track accessibility progress, but these measures require a collection method defined outside the avatar if no integration is planned. For example: separate post‑interaction surveys, observations during the pilot period, or centralised incident logs can be set up.

Relevant indicators may cover: the activation rate of captions or voice mode, the number of incidents reported by users with specific needs, the completeness of responses in priority languages, or the time required to update accessible content. Choose indicators according to project objectives and available measurement tools.

Plan regular reviews to analyse user feedback and prioritise fixes. Improving accessibility is an iterative process requiring governance commitment and resources to update content.

Runbook for operation: maintenance, SLAs and operational procedures

Anticipate routine operations related to accessibility: updating accessible scripts, periodic verification of captions and transcription flows, audio and microphone tests, and control of sign‑language videos if used. Document these tasks in an operational runbook.

Define clear responsibilities: who updates accessible content, who validates translations, who escalates a technical issue related to audio or voice capture. If integrations are planned to call a human operator or trigger assistance, note that these actions require specific integration and should be tested in real conditions.

Schedule checks before and after each major knowledge base update. Also verify voice personalization settings and availability of multimodal options on each deployed terminal.

Operational checklist for an accessible pilot

The checklist below gathers the priority items to validate before and during a pilot. It aims to make the device testable quickly and to provide a decision framework for adjustments.

  • Define priority audiences and accessible usage scenarios

  • Configure SANIA in voice, touch or hybrid mode according to the pilot

  • Enable and test a voice‑to‑text engine for captions (configurable option)

  • Prepare texts and scripts in spoken, written and captioned versions

  • Provide accessible voice adjustment options (volume, speed) via the interface

  • Validate contrasts, font sizes and tactile target sizes on selected screens/kiosks (refer to existing hardware specifications if applicable); run a real‑conditions test (lighting, noise). If sign language is required, plan pre‑recorded videos or integration of a remote interpreter (feature to configure).

Quick FAQ

Q: Does SANIA record conversations to produce captions? A: Recording and retention of data depend on the chosen configuration. Real‑time caption generation can be implemented via a voice‑to‑text engine configured by the project, but any retention or storage of transcriptions must be defined and documented separately according to the organisation’s policy.

Q: Can human assistance be triggered automatically when a user has a specific need? A: An organisation can design orientation scenarios towards staff. Triggering human assistance implies a specific integration (webhook or third‑party system) and operational procedures: these developments must be planned and workflows tested before commissioning.

Conclusion: moving from pilot to accessible operation

Making a reception AI avatar accessible requires a pragmatic approach combining UX design, adapted content, tests with affected users and organisation of operations. SANIA offers configurable capabilities useful for this work: multilingual interaction, voice and touch modes in hybrid configuration, voice personalization and possible integrations for transcription or external assistance. To assess these options in your context, request a SANIA demonstration and validate a pilot protocol focused on accessibility.