Como auditar o acesso por teclado e leitor de tela em um widget WebChat

Audite a página, o widget e a transição entre eles

Um widget de chat não funciona isoladamente. Seu botão de abertura fica na página que o contém, enquanto a conversa aberta pode ser exibida em um painel, diálogo ou outra interface. Teste a experiência incorporada real: a página ao redor do botão, o próprio widget e o que acontece quando as pessoas entram nele ou saem dele.

Antes de testar, registre o URL da página, a configuração do widget, o navegador e o sistema operacional, a tecnologia assistiva e os estados da interface incluídos. Considere o botão de abertura, o chat aberto, qualquer formulário pré-chat, a troca de mensagens, os erros de validação e os estados minimizado e fechado, quando esses recursos estiverem presentes. Não presuma que todo widget usa um diálogo modal; determine como este se comporta.

• Escopo: integração com a página que contém o widget, controles do widget e estados relevantes da conversa.
• Amostra: escolha páginas e fluxos representativos, incluindo um formulário ou estado de erro, se disponível.
• Ambiente: registre o navegador, o sistema operacional, o leitor de tela e o método de entrada.
• Responsáveis: anote quais partes são controladas pela equipe do site, pelo fornecedor do widget ou pelo fornecedor do canal.

Prepare um plano de testes pequeno e repetível

Combine testes apenas com teclado e testes com leitor de tela. Verificações automatizadas de acessibilidade podem ajudar a identificar alguns problemas, mas não comprovam que um widget é acessível. A WAI observa que nenhuma ferramenta de avaliação isolada pode determinar se um site atende aos padrões de acessibilidade; é necessária uma avaliação humana feita por pessoas com conhecimento.

Escolha um pequeno conjunto de jornadas de usuário que sua equipe possa repetir após as mudanças. Por exemplo: abrir o widget, acessar e preencher os campos, enviar uma mensagem, perceber uma resposta, fechar o widget e continuar usando a página. Inclua etapas apenas com teclado e uma verificação com leitor de tela para a mesma jornada.

• Use Tab e Shift+Tab para percorrer os controles; use Enter e Espaço para ativar botões.
• Use os comandos habituais de leitura e navegação por formulários do leitor de tela para verificar nomes, funções, instruções e atualizações.
• Execute uma verificação automatizada quando apropriado, depois confira manualmente os resultados e teste comportamentos que a ferramenta não consegue avaliar.
• Use dados de teste não confidenciais; não envie informações reais de clientes durante uma auditoria.

Teste a abertura, o fechamento e o retorno do foco

Navegue até o botão de abertura sem usar o mouse. Verifique se ele tem um nome acessível útil, se recebe foco visível e se pode ser ativado com Enter ou Espaço. Depois de abrir o chat, determine para onde o foco vai e se esse destino deixa clara a próxima ação.

Se o chat funcionar como um diálogo modal, compare seu comportamento de teclado com o padrão de diálogo modal das Práticas de Autoria ARIA da WAI: o foco vai para dentro do diálogo, Tab e Shift+Tab permanecem nele, Escape o fecha e o foco normalmente retorna ao controle que o abriu. Aplique esse padrão apenas quando a interface for realmente modal. Em um painel não modal, verifique se os usuários conseguem alternar entre o painel e a página sem ficarem presos ou perderem o ponto em que estavam.

Feche o chat usando o teclado e confirme que o foco volta para um local lógico, geralmente o botão de abertura, e continua visível. Abra-o novamente e verifique se o estado anterior da conversa e o comportamento do foco são compreensíveis.

• É possível acessar e ativar pelo teclado o botão de abertura e o controle de fechamento?
• O foco fica visível antes e depois de abrir, fechar e reabrir o widget?
• Quando o widget abre, o foco vai para um ponto inicial útil?
• Os usuários conseguem sair do widget sem usar um ponteiro e sem encontrar uma armadilha de foco inesperada?
• Depois de fechar o widget, os usuários conseguem continuar em um ponto sensato da página?

Verifique a ordem, os controles e as instruções dos formulários

Percorra com Tab o widget aberto e os controles próximos na página. O foco deve seguir uma ordem que preserve o sentido e permita operar a interface. Observe se o foco passa para trás de uma sobreposição, pula um controle, entra em conteúdo oculto ou sai do widget inesperadamente. Verifique se todos os controles em foco têm um indicador visível.

Inspecione botões, links, campos e outros componentes interativos com um leitor de tela. Os nomes e as funções devem explicar o que são e que ação realizam; mudanças de estado, como expandido, selecionado ou desativado, devem ser comunicadas quando aplicável. Um ícone visual, por si só, pode não fornecer um nome útil.

Para cada campo, verifique se os usuários conseguem entender quais informações são esperadas e se o rótulo ou a instrução está associado ao campo de forma programática, quando necessário. Teste também o fluxo de erro, além do preenchimento bem-sucedido: provoque um erro de validação seguro e previsível e, em seguida, verifique se o campo com erro e o problema são identificados em texto. Se houver uma correção conhecida e apropriada, confira se ela é explicada.

• Verifique a ordem de navegação por teclado entre o botão de abertura, a conversa, o campo de mensagem, o controle de envio e qualquer formulário pré-chat.
• Confirme a visibilidade do foco e um comportamento sensato quando o conteúdo aparece ou os controles mudam de estado.
• Use um leitor de tela para verificar os nomes, as funções e os estados dos controles; não se baseie apenas na aparência.
• Confirme que cada campo tem um rótulo ou uma instrução clara e associada.
• Envie dados de teste inválidos e verifique se o erro é identificado e se, quando apropriado, há orientações úteis para corrigi-lo.

Verifique os anúncios de mensagens e status

Envie uma mensagem de teste e verifique como o leitor de tela a apresenta. Depois, faça uma resposta ou outra atualização aparecer enquanto o foco permanece em outro lugar. Os usuários devem conseguir perceber que chegou uma informação relevante sem precisar procurar na conversa nem fazer com que o foco se mova inesperadamente.

Verifique também mudanças de status que não movem o foco, como avisos de validação ou uma mensagem sobre o estado da conexão, quando esse estado fizer parte da experiência testada. O Critério de Sucesso 4.1.3 das WCAG 2.2 trata de mensagens de status que podem ser determinadas programaticamente, para que tecnologias assistivas as apresentem sem receber foco. Evite anunciar cada pequena mudança visual; o anúncio deve ser útil, sem sobrecarregar a conversa.

• Uma pessoa que usa leitor de tela consegue identificar as mensagens recebidas e quem as enviou?
• Atualizações importantes são anunciadas enquanto o foco permanece no lugar?
• Mensagens de validação e outros avisos de status chegam à tecnologia assistiva sem exigir uma busca visual?
• Os anúncios são compreensíveis, oportunos e livres de repetições desnecessárias?

Documente os problemas e atribua cada um à equipe responsável

Descreva cada constatação de modo que outra pessoa consiga reproduzi-la. Inclua a página e o estado do widget, o ambiente de teste, o ponto de partida, as etapas exatas com teclado ou leitor de tela, o resultado observado e o resultado esperado. Descreva o impacto em termos práticos — por exemplo, “a pessoa que usa teclado não consegue acessar o botão de envio” — em vez de registrar apenas uma referência a um padrão.

Diferencie problemas provavelmente relacionados à integração na página daqueles relacionados ao widget, mas considere a experiência incorporada como o resultado que importa para os usuários. Se não estiver claro quem é responsável, peça à equipe do site e ao fornecedor do widget que reproduzam o problema em conjunto. Uma constatação que cruza essa fronteira, como o foco passar para conteúdo oculto da página quando o painel abre, pode exigir a investigação das duas equipes.

• Registre: ID do problema, URL, data, navegador/sistema operacional, tecnologia assistiva, etapas, resultado observado e resultado esperado.
• Acrescente: impacto para o usuário, captura de tela ou gravação curta, quando apropriado, e provável responsável.
• Classifique: página que contém o widget, widget, integração ou responsabilidade compartilhada/incerta.
• Após a correção, repita as mesmas etapas e registre o resultado na página com o widget incorporado — não apenas em uma prévia local do componente.

Use as orientações WCAG e WAI e volte a testar após as mudanças

Use as WCAG 2.2 como referência de avaliação para operação por teclado, ordem e visibilidade do foco, rótulos e instruções, identificação de erros, nomes e funções de componentes e mensagens de status. As Práticas de Autoria ARIA da WAI oferecem orientações úteis de interação para diálogos modais e botões; aplique os padrões de acordo com o comportamento real da interface, não apenas com sua aparência visual.

As orientações de avaliação da WAI recomendam avaliar desde o início e ao longo de todo o desenvolvimento. Repita as verificações relevantes após mudanças na configuração do widget, nos estilos do site, no código de integração ou em atualizações do widget. Mantenha uma lista curta de regressão e preserve as constatações para que as equipes consigam identificar se um problema voltou.

• WCAG 2.2: https://www.w3.org/TR/wcag/
• Visão geral da avaliação de acessibilidade da WAI: https://www.w3.org/WAI/test-evaluate/
• Padrão de diálogo modal das Práticas de Autoria ARIA da WAI: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
• Padrão de botão das Práticas de Autoria ARIA da WAI: https://www.w3.org/WAI/ARIA/apg/patterns/button/
• Metodologia de avaliação WCAG-EM: https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/

Ofereça uma alternativa humana quando o widget impedir o acesso

Se uma pessoa não conseguir acessar ou usar o chat, não faça do widget inacessível o único canal de suporte. Ofereça uma forma alternativa de contato que também seja acessível e deixe claro como a pessoa pode falar com alguém. Equipes que usam o webchat.vip podem organizar conversas e configurar fluxos que as transferem ou encaminham para pessoas; essa possibilidade, por si só, não comprova que um widget ou fluxo específico passe em uma auditoria de acessibilidade.

Designe uma equipe ou função nominal para receber constatações de acessibilidade, coordenar com as pessoas responsáveis pelo site e pelo widget e confirmar as correções. Se a causa não estiver clara, mantenha o problema em aberto e reproduza-o em conjunto, em vez de pedir à pessoa afetada que diagnostique a divisão técnica de responsabilidades.

• Informe aos usuários como entrar em contato com o suporte por uma alternativa acessível quando não conseguirem usar o chat.
• Encaminhe problemas de acesso não resolvidos a uma pessoa de contato do suporte e a uma equipe responsável pelo site ou pela acessibilidade.
• Verifique a alternativa e a experiência incorporada corrigida usando testes com teclado e leitor de tela.