Introdução: desafios operacionais
Desdobrar um avatar IA num quiosque ou ecrã em espaço público exige garantir o acesso a pessoas com deficiências visuais, auditivas, motoras ou cognitivas, sem comprometer a qualidade multilingue nem a disponibilidade 24/7. Este guia pretende transformar princípios gerais em elementos concretos a integrar no caderno de encargos, no piloto e no runbook de exploração.
Responsáveis de projeto, direções de sistemas de informação e equipas de acessibilidade encontrarão aqui: o quadro regulamentar aplicável, os critérios técnicos a verificar, recomendações de UX para a conversação e interface, um protocolo de testes com utilizadores com deficiência e uma checklist de auditoria pronta a usar.
Quadro regulamentar e aplicação das WCAG
Referenciais de acessibilidade web como as WCAG oferecem um quadro técnico pertinente para as interfaces de quiosques interativos. Na prática, trata‑se de aplicar os princípios de alternativas aos meios, operacionalidade por teclado, legibilidade visual e robustez.
Antes do desdobramento, verifique quais as obrigações locais que se aplicam ao seu projeto (regulação nacional, concursos públicos, políticas internas). Os requisitos concretos podem variar conforme o tipo de local e o estatuto da entidade. Considere as WCAG como um guia técnico que a sua interface terá de traduzir em regras de conceção e critérios de aceitação.
Critérios técnicos essenciais para a interface do quiosque
A compatibilidade com tecnologias de apoio depende tanto do software da interface quanto do hardware e da integração. Para garantir a interoperabilidade com leitores de ecrã e tecnologias assistivas, exija que a interface cumpra princípios concretos: estrutura semântica clara, legendas acessíveis, ordem lógica de tabulação e indicação visível do foco.
Outros pontos técnicos a incluir no caderno de encargos: suporte a navegação completa por teclado, textos redimensionáveis sem perda de funcionalidade, contrastes visíveis, alternativas textuais para elementos não textuais e modos múltiplos de entrada (tátil, voz, introdução por teclado).
Compatibilidade com leitores de ecrã e estrutura das respostas
Para que um leitor de ecrã anuncie corretamente os conteúdos produzidos pelo avatar, a camada de interface deve expor elementos textuais e atributos ARIA pertinentes. Preveja saídas textuais equivalentes às mensagens vocais para que um utilizador cego ou com baixa visão aceda às mesmas informações.
Durante a integração, teste a legibilidade de respostas curtas e a clareza das legendas. Evite apresentações exclusivamente icónicas ou animadas sem alternativa textual. A arquitetura do ecrã deve permitir ao visitante identificar rapidamente o estado da sessão (espera, em curso, resultado).
Interação por voz, pessoas com perda auditiva e alternativas visuais
A interação por voz é essencial para muitos casos de uso, mas deve ser sempre acompanhada por uma alternativa visual. Preveja um campo de introdução de texto visível, um teclado virtual tátil e botões de comando claros para iniciar, parar ou repetir uma interação.
A legendagem e a transcrição em tempo real melhoram a acessibilidade para pessoas com perda auditiva. Estas funções exigem tipicamente uma integração específica com um serviço de STT/transcrição e um componente de exibição de legendas. É portanto útil antecipar estas necessidades no caderno de encargos e prever as APIs ou webhooks necessários.
Ergonomia física e implantação do quiosque
A acessibilidade física depende da escolha do local e da ergonomia do equipamento: posicionamento que permita o acesso em cadeira de rodas, superfície de apoio suficiente, inclinação do ecrã, legibilidade sob diferentes ângulos e proteção contra ofuscamento. Estes aspetos dependem do material escolhido e das restrições do sítio.
Pense também em situações de uso sentado vs. em pé, na presença de um apoio de braço ou de uma superfície de apoio para introdução e numa sinalética clara para orientar os utilizadores para o quiosque. A qualidade do microfone e do altifalante afeta a fluidez da interação por voz e deve ser considerada nos testes em condição real.
Acessibilidade cognitiva e conceção da conversação
Adaptar a conceção conversacional a pessoas com dificuldades cognitivas passa por uma redação clara, frases curtas, opções limitadas e uma ajuda passo a passo. Preveja confirmações simples e opções de retoma fácil quando o avatar não compreendeu.
A persona do avatar deve permanecer previsível e coerente. A SANIA pode ser personalizada consoante a atividade e as necessidades do cliente, permitindo ajustar tom, velocidade de fala e complexidade do vocabulário ao público‑alvo.
Protocolo de testes com utilizadores com deficiência para um piloto operacional
Um piloto acessível integra testes com pessoas com deficiências visuais, auditivas, motoras e cognitivas. Defina objetivos de teste precisos: validação da navegação por teclado, compreensão das respostas vocais e textuais, uso em condições de ruído real e avaliação da sinalética física.
Organize cenários representativos (ex.: encontrar uma informação simples, pedir orientação, mudar a língua). Durante cada sessão, recolha observações qualitativas, registe pontos de interrupção e peça feedback sobre a facilidade de uso e a compreensão. Prevê‑se testes em várias línguas se o local receber um público multilingue.
Checklist de auditoria operacional pronta a usar
Esta lista pode ser integrada no caderno de encargos e usada durante o piloto e a exploração. Cobre interface, voz, hardware e testes.
Presença de um modo texto acessível equivalente a cada mensagem vocal.
Navegação completa por teclado e ordem lógica de tabulação na interface.
Rotulagem clara dos controlos com atributos acessíveis (ARIA) e legendas visíveis.
Indicação visual do foco e feedbacks de estado explícitos (a ler, em espera).
Tamanhos de alvo táteis suficientes e áreas de introdução fáceis de alcançar.
Contraste de cores conforme as recomendações WCAG para o texto principal e elementos interativos ou, em falta, destaque de alternativas visuais (ícones acompanhados de texto). Note que as razões precisas estão definidas nas WCAG e devem ser consultadas consoante o objetivo de conformidade da organização. Um ponto prático: teste a interface em condições de luminosidade variadas para validar a legibilidade real.
Exemplos de configurações SANIA e pontos a clarificar no caderno de encargos
Abaixo três configurações ilustrativas e os elementos a especificar no caderno de encargos. Atenção: algumas funções requerem integração específica e não são fornecidas automaticamente sem desenvolvimento.
Configuração 1 – interface tátil e texto acessível: a SANIA é implementada num ecrã/quiosque interativo com interface tátil e saídas textuais completas. Características a definir: navegação por teclado, labels ARIA, gestão do foco, tamanhos de letra adaptáveis. Observação sobre a SANIA: o avatar pode ser utilizado com interface tátil e textual e explora uma base de conhecimento própria da organização.
Configuração 2 – adição de interação por voz: a SANIA fornece a interface vocal e a síntese de voz. Especificar no caderno de encargos a gestão de interrupções vocais, a comutação de idioma em sessão e a qualidade exigida para microfones e altifalantes. Observação sobre a SANIA: a SANIA pode comunicar em mais de 100 idiomas, pode funcionar 24 horas por dia e consegue gerir a interrupção de uma resposta vocal quando o utilizador volta a falar.
Configuração 3 – acessibilidade aumentada (legendas e transcrição): para oferecer legendas ou transcrição em tempo real, preveja integração específica com um serviço de STT e um componente de apresentação das legendas. Especifique as APIs, latência aceitável e modos de fallback caso o serviço de transcrição não esteja disponível. Esta camada é uma integração e exige definição de responsabilidades entre as partes interessadas.
Pontos de atenção e erros frequentes
Não limite a acessibilidade apenas à interação por voz: um quiosque deve sempre oferecer alternativas textuais e táteis. Evite considerar o reconhecimento de voz como solução universal sem prever cenários de contingência.
Não confunda acessibilidade de software com acessibilidade de hardware. Escolhas de hardware inadequadas (ecrã ilegível ao sol, microfone mal posicionado) podem tornar inútil uma interface software bem concebida.
Por fim, não presuma conformidade: envolva as pessoas afetadas no piloto e documente as opções tomadas para poder justificá‑las em caso de auditoria.
Na prática: preparar o piloto e o runbook de exploração
Inclua critérios de acessibilidade desde a redação do caderno de encargos e preveja testes em condições reais antes da generalização. Defina pontos de revisão operacionais para verificar a disponibilidade dos serviços de voz e de transcrição quando estes estiverem integrados.
Documente procedimentos de manutenção de hardware e software, contactos para serviços terceiros (ex.: fornecedor STT) e os cenários de degradação (modo só texto se a função vocal estiver indisponível). Preveja ainda uma instrução clara para encaminhar visitantes para ajuda humana quando o avatar não conseguir responder.