Este módulo se concentra no uso de tecnologia adaptativa (TA) para testes de acessibilidade. Uma pessoa com deficiência pode usar a TA para ajudar a aumentar, manter ou melhorar as capacidades de realizar uma tarefa.
No espaço digital, as TAs podem ser:
- Não/pouco tecnologia: baquetas de cabeça/boca, lupas de mão, dispositivos com botões grandes
- Alta tecnologia: dispositivos ativados por voz, dispositivos de rastreamento ocular, teclados/ratos adaptáveis
- Hardware: botões de interruptor, teclados ergonômicos, dispositivo braille com atualização automática
- Software: programas de conversão de texto em voz, legendas instantâneas, leitores de tela
Recomendamos que você use 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 um dos leitores de tela digitais mais conhecidos. 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 voz ou saída em braille para o usuário.
Leitores de tela são essenciais para pessoas cegas e surdas, mas também podem beneficiar pessoas com baixa visão, distúrbios de leitura ou deficiências cognitivas.
Compatibilidade com navegadores
Há várias opções de leitor de tela disponíveis. Os leitores de tela mais usados atualmente são o JAWS, o NVDA e o VoiceOver para computadores desktop, e o VoiceOver e o 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 é criada considerando hardwares 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 comportamento inesperado. Os leitores de tela funcionam melhor quando usados nas combinações abaixo.
Comandos do leitor de tela
Depois de configurar corretamente o software leitor de tela no seu computador ou dispositivo móvel, consulte a documentação do leitor de tela (link na tabela anterior) e execute alguns comandos essenciais do leitor de tela para se familiarizar com a tecnologia. Se você já usou um leitor de tela antes, tente 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 aplicativo, não emular a experiência de um usuário de leitor de tela. Dessa forma, é possível fazer muita coisa com alguns conhecimentos básicos, alguns comandos do leitor de tela e um pouco (ou muita prática).
Se você precisar entender melhor a experiência do usuário das pessoas que usam leitores de tela e outras TAs, você pode interagir com muitas organizações e indivíduos para obter esse insight valioso. Lembre-se de que usar uma TA para testar o código em relação a um conjunto de regras e perguntar aos usuários sobre a experiência deles costuma gerar resultados diferentes. Ambos são aspectos importantes para criar produtos totalmente inclusivos.
Principais comandos para leitores de tela de computador
Principais comandos para leitores de tela de dispositivos móveis
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 essas etapas usando qualquer leitor de tela, mas a forma como você encontra alguns erros pode ser diferente da descrita neste módulo.
Etapa 1
Acesse o CodePen atualizado, tenha todas as atualizações de acessibilidade automáticas e manuais aplicadas.
Visualize-o no modo de depuração para continuar com o
os próximos testes. Isso é importante porque remove o <iframe> ao redor da
o que pode interferir em algumas ferramentas de teste. Saiba mais sobre
Modo de depuração do CodePen.
Etapa 2
Ative seu leitor de tela e acesse a página de demonstração. É recomendável navegar por toda a página, de cima para baixo, antes de se concentrar em problemas específicos.
Registramos o leitor de tela para cada problema, antes e depois da aplicação das correções à demonstração. Recomendamos que você faça a demonstração com seu próprio leitor de tela.
Problema 1: estrutura do conteúdo
Títulos e pontos de referência são uma das principais formas 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 um dos elementos na demonstração, 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ê atualizou tudo corretamente, não haverá mudanças visuais, mas sua experiência com o leitor de tela terá uma melhora significativa.
Vamos corrigir isso.
Alguns elementos inacessíveis não podem ser observados apenas olhando para 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. Uma parte do conteúdo pode parecer um título, mas, na verdade, é agrupada em um <div> estilizado.
Para corrigir o problema com títulos e pontos de referência, primeiro identifique cada elemento que 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ê atualizou tudo corretamente, não haverá mudanças visuais, mas sua experiência com o leitor de tela terá uma melhora significativa.
Problema 2: contexto do link
É importante fornecer aos usuários do leitor de tela conteúdo sobre a finalidade de um link e se o link está redirecionando-os 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á alguns links adicionais sobre as diversas doenças raras que poderiam se beneficiar de um contexto adicional, especialmente porque redirecionam para um novo local.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
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 as que têm transtornos de leitura e cognição, podemos adicionar mais texto visual.
Há muitos padrões diferentes que podemos considerar para adicionar outras informações de link. Com base no nosso ambiente simples que aceita 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 original do link, por isso, não deixe de incluir essa informação na sua 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>
Problema 3: Imagem decorativa
Em nosso módulo de teste automatizado, o Lighthouse não conseguiu selecionar o SVG inline que atua como a imagem de apresentação principal na nossa página de demonstração, mas o leitor de tela o encontra e o anuncia como "imagem". sem informações adicionais. Isso acontece mesmo sem adicionar explicitamente o atributo role="img" ao SVG.
<div class="section-right">
<svg>...</svg>
</div>
Para corrigir esse problema, primeiro precisamos decidir se a imagem é informativa ou decorativa. Com base nessa decisão, precisamos adicionar o texto alternativo da imagem adequado (imagem informativa) ou ocultar a imagem dos usuários de leitores de tela (decorativo).
Consideramos os prós e contras da melhor forma de categorizar a imagem e decidimos que ela era decorativa, o que significa que queremos adicionar ou modificar o código para ocultá-la. Um método rápido é adicionar um role="presentation" diretamente à imagem SVG. Isso envia um sinal para o leitor de tela pular essa imagem e não listá-la no grupo de imagens.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
Problema 4: decoração de marcador
Você pode ter notado que o leitor de tela lê a imagem de marcador CSS em nas seções de doenças raras. Embora não seja o tipo tradicional de imagem no módulo "Imagens", a imagem ainda precisa ser modificada, já que prejudica o fluxo do conteúdo e pode distrair ou confundir o usuário de um leitor de tela.
<p class="bullet">...</p>
Assim como no exemplo de imagem decorativa discutido anteriormente, é possível adicionar uma role="presentation" ao HTML com a classe de marcador para ocultá-la do leitor de tela. Da mesma forma, uma role="none" funcionaria. Só não use aria-hidden: true para não 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 Formulários, aprendemos que todos os formulários campos também devem ter um rótulo visual e programático. O marcador precisa permanecer visíveis o tempo todo.
Na demonstração, está faltando um rótulo visual e programático no campo de e-mail de inscrição na newsletter. Há um elemento de marcador de posição de texto, mas isso não substitui o rótulo, já que 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>
Para corrigir esse problema, substitua o marcador de posição de texto por um elemento de rótulo parecido. Esse elemento de rótulo é conectado de maneira programática ao campo do 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>
Resumo
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 e apps.
O objetivo de todos esses testes de acessibilidade é abordar o máximo possível problemas que um usuário pode encontrar. No entanto, isso não significa que seu site ou app será perfeitamente acessível quando você terminar. Você terá mais sucesso projetar seu site ou app com acessibilidade durante todo o processo e incorporando esses testes com seus outros testes de pré-lançamento.
Teste seu conhecimento
Teste seus conhecimentos sobre testes de acessibilidade automatizados
Qual é o melhor leitor de tela para testar a acessibilidade?
Qual é a finalidade dos testes com tecnologia assistiva?