Teste de acessibilidade automatizado

Até agora neste curso, você aprendeu sobre os aspectos individuais, comerciais e jurídicos da acessibilidade digital e os conceitos básicos de conformidade com a acessibilidade digital. Você explorou tópicos específicos relacionados a design e programação inclusivos, incluindo quando usar ARIA em comparação com HTML, como medir o contraste de cores, quando o JavaScript é essencial, entre outros tópicos.

Nos módulos restantes, mudamos o foco da criação e da criação para testes de acessibilidade. Usaremos um processo de teste em três etapas que inclui ferramentas e técnicas de teste de tecnologia automatizada, manual e adaptativa. Vamos usar a mesma demonstração em todos esses módulos de teste para que a página da Web passe de inacessível para acessível.

Cada teste (automático, manual e tecnologia adaptativa) é fundamental para alcançar o produto mais acessível possível.

Nossos testes dependem das Diretrizes de Acessibilidade para Conteúdo da Web (WCAG, na sigla em inglês) 2.1 nível de conformidade A e AA como nossos padrões. Lembre-se de que o setor, o tipo de produto, as leis e políticas locais/do país ou as metas gerais de acessibilidade vão determinar quais diretrizes seguir e quais níveis você precisa cumprir. Se você não precisa de um padrão específico para o projeto, a recomendação é seguir a versão mais recente das WCAG. Consulte "Como a acessibilidade digital é medida?" para ver informações gerais sobre auditorias de acessibilidade, tipos/níveis de conformidade, WCAG e POUR.

Como você sabe agora, a conformidade com a acessibilidade não é a história completa quando se trata de apoiar pessoas com deficiência. Mas é um bom ponto de partida, porque fornece uma métrica que você pode testar. Recomendamos que você tome outras ações além dos testes de conformidade de acessibilidade, como realizar testes de usabilidade com pessoas com deficiência, contratar pessoas com deficiência para trabalhar em sua equipe ou consultar uma pessoa ou empresa com experiência em acessibilidade digital para criar produtos mais inclusivos.

Noções básicas sobre testes automatizados

O teste de acessibilidade automatizado usa software para verificar se há problemas de acessibilidade no seu produto digital em relação a padrões de conformidade de acessibilidade predefinidos.

Prós dos testes de acessibilidade automatizados:

• Testes fáceis de repetir em diferentes etapas do ciclo de vida do produto
• Apenas algumas etapas para executar e resultados muito rápidos
• É necessário pouco conhecimento de acessibilidade para executar os testes ou entender os resultados

Desvantagens dos testes de acessibilidade automatizados:

• As ferramentas automatizadas não detectam todos os erros de acessibilidade do seu produto
• Falsos positivos informados (um problema foi relatado que não é uma violação verdadeira das WCAG)
• Várias ferramentas podem ser necessárias para diferentes tipos de produtos e funções

Os testes automatizados são uma ótima etapa inicial para conferir a acessibilidade do seu site ou app, mas nem todas as verificações podem ser automatizadas. Entraremos em mais detalhes sobre como verificar a acessibilidade de elementos que não podem ser automatizados no módulo de teste manual de acessibilidade.

Tipos de ferramentas automatizadas

Uma das primeiras ferramentas de teste de acessibilidade automatizadas on-line foi desenvolvida em 1996 pelo Center for Applied Special Technology (CAST), chamado "The Bobby Report". Hoje, há mais de 100 ferramentas de teste automatizadas para você escolher.

A implementação automatizada de ferramentas varia de extensões de navegador de acessibilidade a linters de código, aplicativos para computador e dispositivos móveis, painéis on-line e até APIs de código aberto que podem ser usadas para criar suas próprias ferramentas automatizadas.

A ferramenta automatizada que você decide usar depende de muitos fatores, incluindo:

• Com quais padrões e níveis de conformidade você está fazendo o teste? Isso pode incluir as WCAG 2.1, WCAG 2.0, Seção dos EUA 508 ou uma lista modificada de regras de acessibilidade.
• Que tipo de produto digital você está testando? Pode ser um site, app da Web, app nativo para dispositivos móveis, PDF, quiosque ou outro produto.
• Em que parte do ciclo de vida do desenvolvimento de software você está testando seu produto?
• Quanto tempo leva para configurar e usar a ferramenta? Para um indivíduo, equipe ou empresa?
• Quem está conduzindo o teste: designers, desenvolvedores, QA etc.?
• Com que frequência você quer que a acessibilidade seja verificada? Quais detalhes devem ser incluídos no relatório? Os problemas precisam estar diretamente vinculados a um sistema de tíquetes?
• Quais ferramentas funcionam melhor no seu ambiente? Para sua equipe?

Há muitos outros fatores a serem considerados. Confira o artigo da WAI sobre Como selecionar as ferramentas de avaliação de acessibilidade da Web para mais informações sobre como escolher a melhor ferramenta para você e sua equipe.

Demonstração: teste automatizado

Para a demonstração automatizada do teste de acessibilidade, usaremos o Lighthouse do Chrome. O Lighthouse é uma ferramenta automatizada de código aberto criada para melhorar a qualidade das páginas da Web por meio de diferentes tipos de auditoria, como desempenho, SEO e acessibilidade.

Nossa demonstração é um site criado para uma organização moldada, o Medical Mysteries Club. Este site foi intencionalmente inacessível durante a demonstração. Algumas dessas inacessibilidades podem ser visíveis, e outras (mas não todas) serão detectadas pelo nosso teste automatizado.

Etapa 1

Usando o navegador Chrome, instale a extensão Lighthouse.

Há muitas maneiras de integrar o Lighthouse ao seu fluxo de trabalho de teste. Usaremos a extensão do Chrome nesta demonstração.

Etapa 2

Criamos uma demonstração no CodePen. 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 3

Abra o Chrome DevTools e navegue até a guia Lighthouse. Desmarque todas as opções de categoria, exceto "Acessibilidade". Mantenha o modo como o padrão e escolha o tipo de dispositivo em que você está executando os testes.

Etapa 4

Clique no botão "Analisar o carregamento de página" e aguarde um tempo para que o Lighthouse execute os testes.

Após a conclusão dos testes, o Lighthouse exibe uma pontuação que mede o quanto o produto está sendo testado. A pontuação do Lighthouse é calculada com base no número, nos tipos de problemas e no impacto dos problemas detectados para os usuários.

Além de uma pontuação, o relatório do Lighthouse inclui informações detalhadas sobre os problemas detectados e links para recursos com mais informações sobre como resolvê-los. O relatório também inclui testes que foram aprovados ou não aplicáveis e uma lista de outros itens a serem verificados manualmente.

Etapa 5

Agora, vamos conferir um exemplo de cada problema de acessibilidade automatizado encontrado e corrigir os estilos e a marcação relevantes.

Problema 1: papéis ARIA

O primeiro problema diz: "Elementos com um [papel] ARIA que exigem que os filhos contenham um [papel] específico não têm alguns ou todos esses filhos obrigatórios. Alguns papéis ARIA pais precisam conter papéis filhos específicos para executar as funções de acessibilidade pretendidas." Saiba mais sobre as regras de função ARIA.

Na nossa demonstração, ocorre um erro no botão de inscrição da newsletter:

<button role="list" type="submit" tabindex="1">Subscribe</button>

Vamos corrigir.

O botão "Assinar" ao lado do campo de entrada tem um papel ARIA incorreto aplicado a ele. Nesse caso, o papel pode ser removido completamente.

<button type="submit" tabindex="1">Subscribe</button>

Problema 2: ARIA oculto

Os elementos "[aria-hidden="true"] contêm descendentes focalizáveis. Os descendentes focalizáveis dentro de um elemento [aria-hidden="true"] impedem que esses elementos interativos estejam disponíveis para usuários de tecnologias adaptativas, como leitores de tela. Saiba mais sobre as regras aria-hidden.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

Vamos corrigir.

O campo de entrada tinha um atributo aria-hidden="true" aplicado a ele. Adicionar esse atributo oculta o elemento (e tudo que estiver aninhado nele) da tecnologia assistiva.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

Nesse caso, remova esse atributo da entrada para permitir que as pessoas que usam tecnologia adaptativa para acessar e inserir informações no campo do formulário.

Problema 3: nome do botão

Os botões não têm um nome acessível. Quando um botão não tem um nome acessível, os leitores de tela o anunciam como "botão", o que o torna inutilizável para usuários que dependem desses leitores. Saiba mais sobre as regras de nome de botão.

<button role="list" type="submit" tabindex="1">Subscribe</button>

Vamos corrigir.

Quando você remove o papel ARIA impreciso do elemento de botão no problema 1, a palavra "Assinar" se torna o nome do botão acessível. Essa funcionalidade é incorporada ao elemento de botão HTML semântico. Há outras opções de padrão a serem consideradas em situações mais complexas.

<button type="submit" tabindex="1">Subscribe</button>

Problema 4: atributos alternativos de imagem

Faltam atributos [alt] nos elementos de imagem. O texto de elementos informativos precisa ser alternativo, breve e descritivo. Elementos decorativos podem ser ignorados com um atributo alternativo vazio. Saiba mais sobre as regras de texto alternativo de imagem.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

Vamos corrigir.

Como a imagem do logotipo também é um link, você sabe no módulo de imagem que ela é chamada de imagem acionável e requer informações de texto alternativas sobre a finalidade da imagem. Normalmente, a primeira imagem na página é um logotipo. Assim, é possível presumir que os usuários de AT saberão disso, e você pode decidir não adicionar outras informações contextuais à descrição da imagem.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

Problema 5: texto do link

Os links não têm um nome compreensível. Textos de link (e textos alternativos para imagens, quando usados como links) perceptíveis, exclusivos e focalizáveis melhoram a experiência de navegação para usuários de leitores de tela. Saiba mais sobre as regras de texto de link.

<a href="#!"><svg><path>...</path></svg></a>

Vamos corrigir.

Todas as imagens acionáveis na página precisam incluir informações sobre para onde o link levará os usuários. Um método para resolver esse problema é adicionar um texto alternativo à imagem sobre a finalidade, como você fez na imagem do logotipo no exemplo acima. Isso funciona muito bem para uma imagem que usa uma tag <img>, mas as tags <svg> não podem usar esse método.

Para os ícones de mídias sociais, que usam tags <svg>, é possível usar um padrão de descrição alternativo diferente para SVGs, adicionar as informações entre as tags <a> e <svg> e ocultá-las visualmente dos usuários, adicionar um ARIA com suporte, entre outras opções. Dependendo do ambiente e das restrições de código, um método pode ser preferível em relação a outro. Vamos usar a opção de padrão mais simples com a maior cobertura de tecnologia adaptativa, que é adicionar um role="img" à tag <svg> e incluir um elemento <title>.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

Problema 6: contraste de cores

As cores de primeiro e segundo plano não têm uma taxa de contraste suficiente. Para muitos usuários, é difícil ou impossível ler textos com baixo contraste. Saiba mais sobre as regras de contraste de cores.

Dois exemplos foram informados.

Vamos corrigir isso.

Foram detectados muitos problemas de contraste de cores na página da Web. Como você aprendeu no módulo de cor e contraste, o texto com tamanho normal (menos de 18 pt / 24 px) tem um requisito de contraste de cor de 4.5:1, enquanto textos de tamanho grande (pelo menos 18 pt / 24 px ou 14 pt / 18,5 px em negrito) e os ícones essenciais precisam atender ao requisito de 3:1.

Para o título da página, o texto azul-petróleo precisa atender ao requisito de contraste de cores 3:1, já que é um texto de tamanho grande com 24 px. No entanto, os botões na cor azul-petróleo são considerados texto de tamanho normal com 16 px em negrito e precisam atender ao requisito de contraste de cores 4.5:1.

Nesse caso, podemos encontrar uma cor azul-petróleo escura o suficiente para atingir 4.5:1 ou aumentar o tamanho do texto do botão para 18, 5 px em negrito e mudar um pouco o valor da cor azul-petróleo. Os dois métodos vão permanecer alinhados com a estética do design.

Todo o texto cinza sobre o fundo branco também apresenta falhas no contraste de cores, exceto pelos dois maiores cabeçalhos na página. Esse texto precisa ser escurecido para atender aos requisitos de contraste de cor 4.5:1.

Problema 7: estrutura da lista

Itens de lista (<li>) não estão contidos nos elementos pai <ul> ou <ol>. Os leitores de tela exigem que os itens de lista (<li>) estejam contidos em um <ul> ou <ol> pai para serem anunciados corretamente.

Saiba mais sobre as regras da lista.

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

Vamos corrigir.

Usamos uma classe CSS nesta demonstração para simular a lista não ordenada em vez de usar uma tag <ul>. Quando escrevemos esse código incorretamente, removemos os recursos HTML semânticos inerentes criados nessa tag. Ao substituir a classe por uma tag <ul> real e modificar o CSS relacionado, resolvemos esse problema de acessibilidade.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

Problema 8: tabindex

Alguns elementos têm um valor [tabindex] maior que 0. Um valor maior que 0 implica uma ordem explícita de navegação. Embora tecnicamente válido, isso muitas vezes cria experiências frustrantes para usuários que dependem de tecnologias adaptativas. Saiba mais sobre as regras do tabindex.

<button type="submit" tabindex="1">Subscribe</button>

Vamos corrigir.

A menos que haja um motivo específico para interromper a ordem natural de tabulação em uma página da Web, não é necessário ter um número inteiro positivo em um atributo tabindex. Para manter a ordem natural das tabulações, podemos mudar o tabindex para 0 ou remover o atributo completamente.

<button type="submit">Subscribe</button>

Etapa 6

Agora que você corrigiu todos os problemas de acessibilidade automatizados, abra uma nova página do modo de depuração. Execute a auditoria de acessibilidade do Lighthouse novamente. Sua pontuação deve ser muito melhor do que na primeira execução.

Aplicamos todas essas atualizações de acessibilidade automatizadas a um novo CodePen.

Próxima etapa

Bom trabalho! Você já conquistou muitas coisas, mas ainda não terminamos! Em seguida, passaremos para as verificações manuais, conforme detalhado no módulo de teste manual de acessibilidade.

Teste seu conhecimento

Teste seus conhecimentos sobre testes de acessibilidade automatizados