Introductie: operationele aandachtspunten

Het inzetten van een AI‑avatar op een kiosk of scherm in de openbare ruimte vereist dat mensen met visuele, auditieve, motorische of cognitieve beperkingen toegang hebben, zonder verlies van meertalige kwaliteit of 24/7‑beschikbaarheid. Deze gids heeft als doel algemene principes te vertalen naar concrete elementen die in het bestek, de pilot en het runbook voor exploitatie opgenomen kunnen worden.

Projectleiders, IT‑managers en toegankelijkheidsteams vinden hier: het relevante wettelijke kader, technische verificatiecriteria, UX‑aanbevelingen voor conversatie en interface, een testprotocol voor gebruikers met een beperking en een kant en klare auditchecklist.

Wettelijk kader en toepassing van WCAG

Toegankelijkheidsreferenties zoals WCAG bieden een technisch kader dat ook voor kioskapparaten relevant is. In de praktijk gaat het om het toepassen van principes rond mediaalternatieven, toetsenbordbediening, visuele leesbaarheid en robuustheid.

Controleer vóór uitrol welke verplichtingen lokaal voor uw project gelden (nationale regelgeving, aanbestedingen, interne beleidsregels). Concrete eisen kunnen variëren naar gelang type locatie en status van de organisatie. Beschouw WCAG als technische leidraad die uw interface moet vertalen naar ontwerpregels en acceptatiecriteria.

Essentiële technische criteria voor de kioskinterface

Compatibiliteit met ondersteunende technologieën hangt zowel van de interface‑software als van hardware en integratie af. Om interoperabiliteit met schermlezers en assistieve technologieën te waarborgen, eis dat de interface concrete principes volgt: duidelijke semantische structuur, toegankelijke labels, logische tabvolgorde en zichtbare focusindicator.

Andere technische punten voor het bestek: volledige toetsenbordnavigatie, schaalbare tekst zonder functieverlies, zichtbare contrasten, tekstalternatieven voor niet‑tekstuele elementen en meerdere invoermodi (touch, spraak, toetsenbord).

Compatibiliteit met schermlezers en opbouw van antwoorden

Zodat een schermlezer de door de avatar geproduceerde inhoud correct aankondigt, moet de interface‑laag tekstuele elementen en relevante ARIA‑attributen blootleggen. Zorg voor tekstuele outputs die equivalent zijn aan de gesproken meldingen, zodat blinde of slechtziende gebruikers dezelfde informatie krijgen.

Test bij integratie de leesbaarheid van korte antwoorden en de helderheid van labels. Vermijd louter iconografische of geanimeerde presentaties zonder tekstalternatief. De schermopbouw moet de bezoeker in staat stellen snel de sessiestatus (wachten, bezig, resultaat) te herkennen.

Spraakinteractie, slechthorenden en visuele alternatieven

Spraakinteractie is voor veel toepassingen essentieel, maar moet altijd vergezeld gaan van een visueel alternatief. Voorzie een zichtbaar tekstinvoerveld, een virtueel toetsenbord en duidelijke knoppen om interactie te starten, te stoppen of te herhalen.

Ondertiteling en realtime transcriptie verbeteren de toegankelijkheid voor slechthorenden. Deze functies vergen doorgaans specifieke integratie met een STT/transcriptiedienst en een component voor de weergave van ondertitels. Neem deze behoeften daarom op in het bestek en definieer de benodigde APIs of webhooks.

Fysieke ergonomie en plaatsing van de kiosk

Fysieke toegankelijkheid hangt af van locatiekeuze en hardware‑ergonomie: positionering die rolstoelinvoer mogelijk maakt, voldoende steunvlak, scherm‑hoek, leesbaarheid onder verschillende invalshoeken en bescherming tegen schittering. Deze aspecten zijn afhankelijk van de gekozen hardware en de locatiecondities.

Denk ook aan zittend versus staand gebruik, een armsteun of schrijflade voor invoer en duidelijke bewegwijzering om gebruikers naar de kiosk te leiden. Microfoon‑ en luidsprekerkwaliteit beïnvloeden de vloeiendheid van spraakinteractie en moeten in reële omstandigheden getest worden.

Cognitieve toegankelijkheid en ontwerp van de conversatie

Conversatieontwerp voor mensen met cognitieve beperkingen vraagt om duidelijke taal, korte zinnen, beperkte keuzemogelijkheden en stapsgewijze hulp. Voorzie eenvoudige bevestigingen en gemakkelijke opties om opnieuw te beginnen wanneer de avatar niet begrepen heeft.

De persona van de avatar moet voorspelbaar en consistent blijven. SANIA kan gepersonaliseerd worden op basis van de activiteit en de behoeften van de opdrachtgever, waardoor toon, spreektempo en woordkeuze aan het beoogde publiek aangepast kunnen worden.

Testprotocol met gebruikers met beperkingen voor een pilot

Een toegankelijke pilot omvat tests met personen met visuele, auditieve, motorische en cognitieve beperkingen. Definieer duidelijke testdoelen: validatie van toetsenbordnavigatie, begrip van gesproken en tekstuele antwoorden, gebruik bij daadwerkelijk omgevingsgeluid en evaluatie van fysieke bewegwijzering.

Organiseer representatieve scenario's (bijv.: eenvoudige informatie vinden, route vragen, taal wijzigen). Verzamel tijdens elke sessie kwalitatieve observaties, noteer onderbrekingspunten en vraag feedback over gebruiksgemak en begrip. Plan meertalige tests als de locatie een meertalig publiek ontvangt.

Kant‑en‑klare auditchecklist voor de operatie

Deze lijst kan in het bestek worden opgenomen en gebruikt tijdens pilot en exploitatie. Ze bestrijkt interface, spraak, hardware en tests.

  • Voor elk gesproken bericht is een toegankelijk tekstalternatief aanwezig.

  • Volledige toetsenbordnavigatie en logische tabvolgorde in de interface.

  • Duidelijke labeling van besturingselementen met toegankelijke attributen (ARIA) en zichtbare labels.

  • Zichtbare focusindicator en expliciete statusfeedback (bezig met lezen, wachtend).

  • Voldoende grote touch‑doelen en gemakkelijk bereikbare invoervelden.

  • Kleurcontrast van hoofdtekst en interactieve elementen voldoet aan de WCAG‑aanbevelingen of, indien niet mogelijk, zijn visuele alternatieven benadrukt (pictogrammen met tekst). Let op: de exacte contrastverhoudingen zijn in de WCAG beschreven en dienen te worden geraadpleegd afhankelijk van het beoogde conformiteitsniveau. Praktisch punt: test de interface bij verschillende lichtomstandigheden om de daadwerkelijke leesbaarheid te valideren.

Voorbeelden van SANIA‑configuraties en op te nemen punten in het bestek

Hier drie illustratieve configuraties en de elementen om in het bestek te specificeren. Let op: sommige functies vragen om specifieke integratie en worden niet automatisch geleverd zonder ontwikkeling.

Configuratie 1 – touchinterface en toegankelijk tekst‑output: SANIA wordt ingezet op een interactief scherm/kiosk met touchinterface en volledige tekstuele outputs. Te specificeren kenmerken: toetsenbordnavigatie, ARIA‑labels, focusbeheer, aanpasbare lettergroottes. Opmerking bij SANIA: de avatar kan met een touch‑ en tekstinterface worden gebruikt en maakt gebruik van een organisatiedomeinspecifieke kennisbasis.

Configuratie 2 – toevoeging van spraakinteractie: SANIA levert spraakinterface en spraaksynthese. Specificeer in het bestek hoe met spraakonderbrekingen om te gaan is, taalwisseling tijdens een sessie en de vereiste kwaliteit van microfoons en luidsprekers. Opmerking bij SANIA: SANIA kan in meer dan 100 talen communiceren, 24/7 draaien en onderbrekingen in een gesproken antwoord verwerken wanneer de gebruiker weer spreekt.

Configuratie 3 – uitgebreide toegankelijkheid (ondertiteling en transcriptie): voor ondertitels of realtime transcriptie is een specifieke integratie met een STT‑dienst en een component voor ondertitelweergave nodig. Specificeer APIs, aanvaardbare latentie en omschakelmodi als de transcriptiedienst niet beschikbaar is. Deze laag is een integratie en vereist afspraken over verantwoordelijkheden tussen de betrokken partijen.

Aandachtspunten en veelgemaakte fouten

Beperk toegankelijkheid niet tot alleen spraakinteractie: een kiosk moet altijd tekstuele en tactiele alternatieven bieden. Vermijd de aanname dat spraakherkenning een universele oplossing is zonder back‑upscenario's.

Verschil softwaretoegankelijkheid niet met hardwaretoegankelijkheid. Onjuiste hardwarekeuzes (bijv. scherm dat buiten niet leesbaar is, slecht geplaatst microfoon) kunnen een goed ontworpen softwareinterface onbruikbaar maken.

Tenslotte: ga niet uit van conformiteit; betrek betrokken personen bij de pilot en documenteer gemaakte keuzes om ze bij een audit te kunnen onderbouwen.

In de praktijk: de pilot en het runbook voorbereiden

Neem toegankelijkheidscriteria op bij het opstellen van het bestek en plan tests onder reële omstandigheden voordat u breed uitrolt. Definieer operationele reviewmomenten om de beschikbaarheid van spraak‑ en transcriptiediensten te verifiëren wanneer deze zijn geïntegreerd.

Documenteer onderhoudsprocedures voor hardware en software, contacten voor externe diensten (bijv. STT‑leverancier) en de‑escalatiescenario's (bijv. alleen tekstmodus als de spraakfunctie niet beschikbaar is). Voorzie ten slotte een duidelijke instructie om bezoekers te verwijzen naar menselijke hulp wanneer de avatar niet kan antwoorden.