Noções básicas sobre testes manuais
O teste manual de acessibilidade usa testes de teclado, visuais e cognitivos, ferramentas e técnicas para encontrar problemas que as ferramentas automatizadas não conseguem. Como as ferramentas automatizadas não abrangem todos os critérios de sucesso identificados nas WCAG, é vital que você não execute testes de acessibilidade automatizados e depois interrompa os testes.
Com o avanço da tecnologia, mais testes podem ser cobertos apenas pelas ferramentas automatizadas. No entanto, atualmente, é necessário adicionar as verificações manuais e de tecnologia adaptativa aos protocolos de teste para abranger todos os checkpoints das WCAG aplicáveis.
Prós dos testes manuais de acessibilidade:
- Razoavelmente simples e rápido de executar
- Detectar uma porcentagem maior de problemas do que os testes automatizados sozinhos
- Poucas ferramentas e conhecimento necessários para o sucesso
Desvantagens dos testes de acessibilidade manuais:
- Mais complexos e demorados do que testes automatizados
- Pode ser difícil repetir em grande escala
- Exigem mais experiência em acessibilidade para executar testes e interpretar os resultados
Vamos comparar quais elementos e detalhes de acessibilidade podem ser detectados atualmente por uma ferramenta automatizada e quais não serão detectados.
Tipos de testes manuais
Existem muitas ferramentas e técnicas manuais a serem consideradas ao analisar sua página da Web ou app para acessibilidade digital. As três maiores áreas de foco nos testes manuais são a funcionalidade do teclado, as avaliações com foco visual e as verificações gerais de conteúdo.
Abordaremos cada um desses tópicos de maneira detalhada neste módulo, mas os testes abaixo não são uma lista completa de todos os testes manuais que podem ou precisam ser executados. Recomendamos que você comece com uma lista de verificação manual de acessibilidade de uma fonte respeitável e desenvolva sua própria lista de verificação manual focada para as necessidades específicas do seu produto digital e da sua equipe.
Verificações do teclado
Estima-se que cerca de 25% de todos os problemas de acessibilidade digital estejam relacionados à falta de suporte ao teclado. Como aprendemos no módulo de foco do teclado, isso afeta todos os tipos de usuários, incluindo usuários que só usam teclado, usuários com deficiência visual ou leitores de tela cegos e pessoas que usam software de reconhecimento de voz que também usa tecnologia baseada no conteúdo acessível pelo teclado.
Os testes de teclado respondem a perguntas como:
- A página da Web ou recurso exige um mouse para funcionar?
- A ordem da tabulação é lógica e intuitiva?
- O indicador de foco do teclado está sempre visível?
- Você consegue ficar preso em um elemento que não deveria capturar o foco?
- É possível navegar para trás ou ao redor de um elemento que deveria estar capturando o foco?
- Ao fechar um elemento que recebeu foco, o indicador de foco voltou a um lugar lógico?
Embora o impacto da funcionalidade do teclado seja enorme, o procedimento de teste é bastante simples. Basta separar o mouse ou instalar um pequeno pacote do JavaScript e testar o site usando apenas o teclado. Os comandos a seguir são essenciais para testar o teclado.
Verificações visuais
As verificações visuais se concentram nos elementos visuais da página e usam ferramentas como ampliação da tela ou zoom do navegador para verificar a acessibilidade do site ou app.
As verificações visuais podem informar:
- Há problemas de contraste de cores que uma ferramenta automatizada não conseguiu detectar, como texto em um gradiente ou imagem?
- Há elementos que parecem cabeçalhos, listas e outros elementos estruturais, mas não estão codificados dessa forma?
- Os links de navegação e as entradas de formulários são consistentes em todo o site ou app?
- Alguma animação intermitente, estroboscópica ou animação excede as recomendações?
- O conteúdo tem espaçamento adequado? Para letras, palavras, linhas e parágrafos?
- Você consegue ver todo o conteúdo usando uma lupa ou o zoom do navegador?
Verificações de conteúdo
Ao contrário dos testes visuais que se concentram em layouts, movimento e cores, as verificações de conteúdo focam nas palavras da página. Você deve analisar a cópia em si e revisar o contexto para garantir que ela faça sentido para outras pessoas.
As verificações de conteúdo respondem a perguntas como:
- Os títulos das páginas, cabeçalhos e rótulos de formulários são claros e descritivos?
- As alternativas de imagem são concisas, precisas e úteis?
- A cor é usada sozinha como a única maneira de transmitir significado ou informações?
- Os links são descritivos ou você usa texto genérico, como “leia mais” ou “clique aqui?”.
- Há alguma mudança no idioma de uma página?
- A linguagem simples é usada, e todas as siglas são escritas na primeira referência?
Algumas verificações de conteúdo podem ser automatizadas em parte. Por exemplo, você pode criar um linter de JavaScript que verifica "Clique aqui" e sugere que você faça uma mudança. No entanto, essas soluções personalizadas geralmente ainda precisam de uma pessoa para alterar a cópia para algo contextual.
Demonstração: teste manual
Até o momento, fizemos testes automatizados na nossa página da Web de demonstração e encontramos e corrigimos oito tipos de problemas. Agora estamos prontos para fazer verificações manuais para descobrir ainda mais problemas de acessibilidade.
Etapa 1
Nossa demonstração do CodePen atualizada tem todas as atualizações de acessibilidade automatizadas aplicadas.
Confira-o no modo de depuração para continuar com os
próximos testes. Isso é importante, porque remove a <iframe>
ao redor da
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
Inicie seu processo de teste manual colocando o mouse ou o trackpad de lado e navegue para cima e para baixo no DOM usando somente o teclado.
Problema 1: indicador de foco visível
O primeiro problema com o teclado vai aparecer imediatamente, ou não, porque o indicador de foco visível foi removido. Ao verificar o CSS na demonstração, você deve encontrar o temido "outline: none" foi adicionado à base de código.
:focus {
outline: none;
}
Como você aprendeu no módulo de foco do teclado, é necessário remover essa linha de código para permitir que os navegadores da Web adicionem um foco visível para os usuários. Você pode dar um passo adiante e criar um indicador de foco com estilo que combine com a estética do seu produto digital.
:focus {
outline: 3px dotted #008576;
}
Problema 2: ordem de foco
Depois de modificar o indicador de foco e ele ficar visível, percorra a guia da página. Ao fazer isso, o campo de entrada do formulário usado para assinar a newsletter não recebe foco. Ele foi removido da ordem de foco natural por um tabindex negativo.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
Como queremos que as pessoas usem esse campo para se inscrever na nossa newsletter, basta remover o tabindex negativo ou definir como zero para que a entrada volte a ser focalizável pelo teclado.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>
Etapa 3
Depois que o foco do teclado é verificado, passamos para as verificações visuais e de conteúdo.
Problema 3: contraste de cores do link
Ao fazer os testes de teclado usando as guias da página de demonstração para cima e para baixo, você provavelmente percebeu que o teclado focou em três links visualmente ocultos nos parágrafos sobre as diferentes condições médicas.
Para que nossa página seja acessível, os links precisam se destacar do texto ao redor e incluir uma mudança de estilo sem cor ao passar o cursor e no foco do teclado.
Uma solução rápida é adicionar um sublinhado aos links dentro dos parágrafos para destacá-los. Isso resolveria o problema de acessibilidade, mas pode não ser adequado para a estética geral de design que você espera alcançar.
Se você optar por não adicionar um sublinhado, será necessário modificar as cores a fim de atender aos requisitos de plano de fundo e cópia.
Ao observar a demonstração usando uma ferramenta de verificação de contraste de links, você verá que a cor do link atende ao requisito de contraste de cores 4.5:1 entre o texto de tamanho normal e o plano de fundo. No entanto, os links não sublinhados também precisam atender ao requisito de contraste de cor de 3:1 em relação ao texto ao redor.
Uma opção é mudar a cor do link para combinar com os outros elementos da página. Mas se você alterar a cor do link para verde, o corpo do texto também deverá ser modificado para atender aos requisitos gerais de contraste de cores entre os três elementos: links, plano de fundo e texto ao redor.
![A captura de tela do WebAIM para texto de link mostra que o link para o texto do corpo falha no nível WCAG A.](https://web.dev/static/learn/accessibility/test-manual/image/screenshot-webaim-link-d6607ee51a7f9.png?authuser=5&hl=pt-br)
![A captura de tela do WebAIM mostra que todos os testes são aprovados quando a cor do link é verde.](https://web.dev/static/learn/accessibility/test-manual/image/screenshot-webaim-shows-a6f42f1c49134.png?authuser=5&hl=pt-br)
Problema 4: contraste de cor de ícones
Outro problema que falta de contraste de cores são os ícones de redes sociais. No módulo de cor e contraste, você aprendeu que os ícones essenciais precisam ter um contraste de cor de 3:1 com o plano de fundo. No entanto, na demonstração, os ícones de redes sociais têm uma taxa de contraste de 1,3:1.
Para atender aos requisitos de contraste de cores 3:1, os ícones de redes sociais são alterados para um cinza mais escuro.
![Captura de tela da demonstração com o analisador de cores mostrando o contraste de cores do ícone com falha.](https://web.dev/static/learn/accessibility/test-manual/image/a-screenshot-the-demo-t-ea0c1b4ef7bcb.png?authuser=5&hl=pt-br)
Problema 5: layout do conteúdo
Se você observar o layout do conteúdo do parágrafo, o texto vai estar totalmente justificado. Como você aprendeu no módulo de Tipografia, isso cria "rios de espaço", o que pode dificultar a leitura do texto.
p.bullet {
text-align: justify;
}
Para redefinir o alinhamento do texto na demonstração, atualize o código para text-align: left;
ou remova essa linha totalmente do CSS, já que o alinhamento padrão para navegadores está à esquerda. Não deixe de testar o código, caso outros
estilos herdados removam o alinhamento de texto padrão.
p.bullet {
text-align: left;
}
Etapa 4
![Captura de tela do site de demonstração do Medical Mysteries Club.](https://web.dev/static/learn/accessibility/test-manual/image/screenshot-the-medical-m-6a48ef85663f8.png?authuser=5&hl=pt-br)
Depois que você identificar e corrigir todos os problemas manuais de acessibilidade descritos nas etapas anteriores, sua página ficará parecida com a captura de tela.
É possível que você encontre mais problemas de acessibilidade nas verificações manuais do que o abordado neste módulo. Vamos descobrir muitos desses problemas no próximo módulo.
Próxima etapa
Muito bem! Você concluiu os módulos de teste automatizado e manual. Confira nosso CodePen atualizado, com todas as correções de acessibilidade automatizadas e manuais aplicadas.
Agora, vá para o último módulo de teste focado em testes de tecnologia assistiva.
Teste seu conhecimento
Teste seus conhecimentos sobre testes manuais de acessibilidade
Quais elementos precisam atender aos padrões WCAG de contraste de cores?