Testes de tecnologia assistiva

Este módulo se concentra no uso de tecnologia adaptativa (AT) para testes de acessibilidade. Uma pessoa com deficiência pode usar uma AT para aumentar, manter ou melhorar as capacidades de realizar uma tarefa.

No espaço digital, as ATs podem ser:

  • Sem tecnologia ou com pouca tecnologia: palitos para cabeça e boca, lupas de mão, dispositivos com botões grandes
  • Alta tecnologia: dispositivos ativados por voz, dispositivos de rastreamento ocular, teclados e mouses adaptáveis
  • Hardware: botões de interruptor, teclados ergonômicos, dispositivo Braille de atualização automática
  • Software: programas de conversão de texto em voz, legendas ao vivo, leitores de tela

Recomendamos o uso de vários tipos de ATs no fluxo de trabalho geral de testes.

Noções básicas de testes de leitores de tela

Neste módulo, vamos nos concentrar em uma das AA digitais mais conhecidas, os leitores de tela. Um leitor de tela é um software que lê o código subjacente de um site ou app. Em seguida, ele converte essas informações em saída de voz ou Braille para o usuário.

Os leitores de tela são essenciais para pessoas cegas e com surdoceficiencia, mas também podem beneficiar pessoas com baixa visão, distúrbios de leitura e deficiências cognitivas.

Compatibilidade com navegadores

Há várias opções de leitor de tela disponíveis. Os leitores de tela mais conhecidos são JAWS, NVDA e VoiceOver para computadores e VoiceOver e Talkback para dispositivos móveis.

Dependendo do sistema operacional (SO), do navegador favorito e do dispositivo usado, um leitor de tela pode se destacar como a melhor opção. A maioria dos leitores de tela é desenvolvida pensando em hardware e navegadores da Web específicos. Ao usar um leitor de tela com um navegador para o qual ele não foi calibrado, você pode encontrar mais "bugs" ou comportamentos inesperados. Os leitores de tela funcionam melhor quando usados nas seguintes combinações.

Leitor de tela SO Compatibilidade com navegadores
Job Access With Speech (JAWS) Windows Chrome, Firefox e Edge
Acesso não visual ao computador (NVDA) Windows Chrome e Firefox
Narrador Windows Edge
VoiceOver macOS Safari
Orca (em inglês) Linux Firefox
TalkBack Android Chrome e Firefox
VoiceOver (para dispositivos móveis) iOS Safari
ChromeVox ChromeOS Chrome

Comandos do leitor de tela

Depois de configurar corretamente o software de leitor de tela para seu computador ou dispositivo móvel, consulte a documentação do leitor de tela (vinculada na tabela anterior) e execute alguns comandos essenciais para se familiarizar com a tecnologia. Se você já usou um leitor de tela antes, experimente um novo.

Ao usar um leitor de tela para testes de acessibilidade, o objetivo é detectar problemas no código que interfiram no uso do site ou app, não emular a experiência de um usuário de leitor de tela. Assim, há muito que você pode fazer com alguns conhecimentos básicos, alguns comandos do leitor de tela e um pouco (ou muito) de prática.

Se você precisar entender melhor a experiência do usuário de pessoas que usam leitores de tela e outras AAs, entre em contato com muitas organizações e indivíduos para obter esse insight valioso. Lembre-se de que usar um AT para testar o código com base em um conjunto de regras e perguntar aos usuários sobre a experiência deles geralmente gera resultados diferentes. Ambos são aspectos importantes para criar produtos totalmente inclusivos.

Principais comandos para leitores de tela de computador

Elemento NVDA (Windows) VoiceOver (macOS)
Chaves de comando gerais Inserir Control+Option
Interromper o áudio Controle Controle
Ler próximo/anterior ou Control+Option+ ou
Começar a ler Inserir Control+Option+A
Lista de elementos/rotor NVDA + F7 Control+Option+U
Pontos de referência D Ctrl+Option+U
Títulos H Control+Option+Command+H
Links K Control+Option+Command+L
Controles de formulário S Control+Option+Command+J
Tabelas T Control+OptionCommand+T
Dentro das tabelas InsertAlt + Control+Option+

Principais comandos para leitores de tela de dispositivos móveis

Elemento TalkBack (Android) VoiceOver (iOS)
Explorar Arraste um dedo pela tela Arraste um dedo pela tela
Selecionar ou ativar Tocar duas vezes Tocar duas vezes
Mover para cima ou para baixo Deslize para cima ou para baixo com dois dedos Deslize para cima ou para baixo com três dedos
Alterar páginas Deslize para a esquerda ou direita com dois dedos Deslize para a esquerda ou direita com três dedos
Próxima/anterior Deslize para a esquerda ou direita com um dedo Deslize para a esquerda ou direita com um dedo

Demonstração de teste do leitor de tela

Para testar nossa demonstração, usamos um Safari em um laptop com macOS e capturamos o som. Você pode seguir estas etapas usando qualquer leitor de tela, mas a forma como alguns erros são encontrados pode ser diferente da descrita neste módulo.

Etapa 1

Acesse o CodePen atualizado, que tem todas as atualizações de acessibilidade automáticas e manuais aplicadas.

Confira no modo de depuração para continuar com os próximos testes. Isso é importante, porque remove o <iframe> que envolve a página da Web de demonstração, o que pode interferir em algumas ferramentas de teste. Saiba mais sobre o modo de depuração do CodePen.

Etapa 2

Ative o leitor de tela que você preferir e acesse a página de demonstração. Navegue por toda a página, de cima para baixo, antes de se concentrar em problemas específicos.

Gravamos nosso leitor de tela para cada problema, antes e depois que as correções foram aplicadas à demonstração. Recomendamos que você faça a demonstração com seu próprio leitor de tela.

Problema 1: estrutura do conteúdo

Os títulos e os pontos de referência são uma das principais maneiras de navegar usando leitores de tela. Se eles não estiverem presentes, um usuário de leitor de tela terá que ler a página inteira para entender o contexto. Isso pode levar muito tempo e causar frustração.

Se você tentar navegar por qualquer elemento na demonstração, vai descobrir rapidamente que eles não existem.

  • Exemplo de ponto de referência: <div class="main">...</div>
  • Exemplo de título: <p class="h1">Join the Club</p>

Se você tiver atualizado tudo corretamente, não haverá mudanças visuais, mas a experiência do leitor de tela vai melhorar muito.

Ouça o leitor de tela navegar por esse problema.
Vamos corrigir isso.

Alguns elementos inacessíveis não podem ser observados apenas olhando o site. Talvez você se lembre da importância dos níveis de cabeçalho e do HTML semântico no módulo Estrutura de conteúdo. Um conteúdo pode parecer um título, mas na verdade está envolvido em um <div> estilizado.

Para corrigir o problema com títulos e pontos de referência, primeiro identifique cada elemento que precisa ser marcado como tal e atualize o HTML relacionado. Não se esqueça de atualizar o CSS relacionado também.

  • Exemplo de ponto de referência: <main>...</main>
  • Exemplo de título: <h1>Join the Club</h1>

Se você tiver atualizado tudo corretamente, não haverá mudanças visuais, mas a experiência do leitor de tela vai melhorar muito.

Agora que corrigimos a estrutura do conteúdo, ouça o leitor de tela navegar pela demonstração novamente.

É importante fornecer conteúdo aos usuários de leitores de tela sobre a finalidade de um link e se ele está redirecionando para um novo local fora do site ou app.

Na nossa demonstração, corrigimos a maioria dos links quando atualizamos o texto alternativo da imagem ativa, mas há mais alguns links sobre as várias doenças raras que podem se beneficiar de mais contexto, especialmente porque redirecionam para um novo local.

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
  Maple syrup urine disease (MSUD)
</a>
Ouça o leitor de tela navegar por esse problema.
Vamos corrigir isso.

Para corrigir esse problema para usuários de leitores de tela, atualizamos o código para adicionar mais informações sem afetar o elemento visual. Ou, para ajudar ainda mais pessoas como pessoas com transtornos de leitura e cognição, podemos adicionar mais texto visual.

Há muitos padrões diferentes que podemos considerar para adicionar mais informações de link. Com base no nosso ambiente que oferece suporte a apenas um idioma, um rótulo ARIA é uma opção simples nessa situação. Você pode notar que o rótulo ARIA substitui o texto do link original. Portanto, inclua essa informação na atualização.

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
  aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
  Maple syrup urine disease (MSUD)
</a>
Agora que corrigimos o contexto do link, ouça o leitor de tela navegar pela demonstração novamente.

Problema 3: imagem decorativa

No nosso módulo de teste automatizado, o Lighthouse não conseguiu detectar o SVG inline que atua como a imagem de abertura principal na nossa página de demonstração. No entanto, o leitor de tela encontra e anuncia o elemento como "imagem" sem outras informações. Isso acontece mesmo sem adicionar explicitamente o atributo role="img" ao SVG.

<div class="section-right">
  <svg>...</svg>
</div>
Ouça o leitor de tela navegar por esse problema.
Vamos corrigir isso.

Para corrigir esse problema, primeiro precisamos decidir se a imagem é informativa ou decorativa. Com base nessa decisão, precisamos adicionar o texto alternativo adequado (imagem informativa) ou ocultar a imagem dos usuários de leitores de tela (decorativa).

Pesamos as vantagens e desvantagens de como categorizar melhor a imagem e decidimos que ela era decorativa, o que significa que queremos adicionar ou modificar o código para ocultar a imagem. Um método rápido é adicionar um role="presentation" à imagem SVG diretamente. Isso envia um sinal para o leitor de tela pular essa imagem e não a listar no grupo de imagens.

<div class="section-right">
  <svg role="presentation">...</svg>
</div>
Agora que corrigimos a imagem decorativa, ouça o leitor de tela navegar pela demonstração.

Problema 4: decoração de marcadores

Você pode ter notado que o leitor de tela lê a imagem de marcador CSS nas seções de doenças raras. Embora não seja o tipo tradicional de imagem que discutimos no módulo Imagens, ela ainda precisa ser modificada, porque interrompe o fluxo do conteúdo e pode distrair ou confundir um usuário de leitor de tela.

<p class="bullet">...</p>
O leitor de tela navega por esse problema.
Vamos corrigir isso.

Assim como no exemplo de imagem decorativa discutido anteriormente, é possível adicionar um role="presentation" ao HTML com a classe de marcador para ocultá-lo do leitor de tela. Da mesma forma, um role="none" funcionaria. Não use aria-hidden: true, ou você vai ocultar todas as informações do parágrafo dos usuários de leitores de tela.

<p class="bullet" role="none">...</p>

Problema 5: campo "Formulário"

No módulo Forms, aprendemos que todos os campos do formulário também precisam ter um rótulo visual e programático. Esse rótulo precisa permanecer visível o tempo todo.

Na nossa demonstração, falta um rótulo visual e programático no campo de e-mail de inscrição na newsletter. Há um elemento de espaço reservado de texto, mas ele não substitui o rótulo, porque não é visualmente persistente e não é totalmente compatível com todos os leitores de tela.

<form>
  <div class="form-group">
    <input type="email" placeholder="Enter your e-mail address" required>
    <button type="submit">Subscribe</button>
  </div>
</form>
O leitor de tela navega por esse problema.
Vamos corrigir isso.

Para corrigir esse problema, substitua o marcador de posição de texto por um elemento de rótulo semelhante. Esse elemento de rótulo é conectado programaticamente ao campo de formulário, e o movimento foi adicionado com JavaScript para manter o rótulo visível mesmo quando o conteúdo é adicionado ao campo.

<form>
  <div class="form-group">
    <input type="email" required id="youremail" name="youremail" type="text">
    <label for="youremail">Enter your e-mail address</label>
    <button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
  </div>
</form>
Agora que corrigimos o formulário, ouça o leitor de tela navegar pela demonstração.

Conclusão

Parabéns! Você concluiu todos os testes desta demonstração. Veja todas essas mudanças no Codepen atualizado para esta demonstração.

Agora, você pode usar o que aprendeu para revisar a acessibilidade dos seus próprios sites e apps.

O objetivo de todos esses testes de acessibilidade é resolver o maior número possível de problemas que um usuário pode encontrar. No entanto, isso não significa que seu site ou app possa ser acessado perfeitamente depois que você terminar. Você vai ter mais sucesso projetando seu site ou app com acessibilidade ao longo do processo e incorporando esses testes aos outros testes de pré-lançamento.

Teste seu conhecimento

Testar seus conhecimentos sobre testes automatizados de acessibilidade

Qual é o melhor leitor de tela para testar a acessibilidade?

JAWS
Embora o JAWS seja um dos leitores de tela mais conhecidos, ele não é necessariamente a melhor escolha.
VoiceOver
O VoiceOver é uma ferramenta para usuários do macOS e iOS. Se você estiver usando um PC Windows, vai precisar usar uma ferramenta diferente.
Orca
O Orca é para usuários do Firefox no Linux, o que pode significar que você precisa usar uma ferramenta diferente.
Não há um
Cada leitor de tela é criado para um dispositivo, sistema operacional ou navegador específico. Portanto, o melhor para você depende de como você está testando. Se você tiver análises ou pesquisas que informem mais sobre seus usuários que usam leitores de tela, pode ser útil testar com os mesmos leitores de tela que eles usam.

Qual é a finalidade dos testes com tecnologia adaptativa?

Para ter a mesma experiência que as pessoas que usam tecnologia adaptativa.
Você não pode imitar a experiência de alguém que usa AT. Um teste em uma situação não será igual ao de outras experiências.
Testar falhas no seu site ou app.
Os testes de acessibilidade ajudam os desenvolvedores a encontrar e corrigir problemas que os usuários com AT podem ter no site ou app.