Teste de acessibilidade automatizado

Até agora neste curso, você aprendeu sobre os aspectos individuais, comerciais e legais da acessibilidade digital e os fundamentos da conformidade com a acessibilidade digital. Você explorou tópicos específicos relacionados a design e codificação inclusivos, incluindo quando usar ARIA ou HTML, como medir o contraste de cores, quando JavaScript é essencial, entre outros tópicos.

Nos demais módulos, vamos mudar de assunto, passando do design e da criação para o teste de acessibilidade. Vamos utilizar um processo de teste de três etapas que inclui ferramentas e técnicas de teste automatizado, manual e de tecnologia adaptativa. Vamos usar a mesma demonstração em todos esses módulos de teste para transformar a página da Web de inacessível em acessível.

Cada teste, seja automatizado, manual ou com tecnologia adaptativa, é essencial para alcançar o produto mais acessível possível. Nossos testes se baseiam nas Diretrizes de Acessibilidade de Conteúdo da Web (WCAG, na sigla em inglês) 2.1 níveis de conformidade A e AA como padrões.

Lembre-se de que seu setor, tipo de produto, leis e políticas locais e nacionais ou metas de acessibilidade gerais determinam quais diretrizes seguir e os níveis a serem atendidos. Se você não precisar de um padrão específico para seu projeto, a recomendação é seguir a versão mais recente do WCAG. Consulte "Como a acessibilidade digital é medida?" para informações gerais sobre auditorias de acessibilidade, tipos/níveis de conformidade, WCAG e POUR.

Como você sabe, a conformidade de acessibilidade não é o objetivo final quando se trata de apoiar pessoas com deficiência. No entanto, é um bom ponto de partida, porque fornece uma métrica que pode ser testada. Recomendamos que você tome outras medidas 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 na sua equipe ou consultar uma pessoa ou empresa com experiência em acessibilidade digital para ajudar a criar produtos mais inclusivos.

Noções básicas de testes automatizados

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

Vantagens dos testes de acessibilidade automatizados:

  • Testes fáceis de repetir em diferentes estágios do ciclo de vida do produto.
  • Faltam apenas algumas etapas e resultados muito rápidos.
  • É necessário ter pouco conhecimento sobre acessibilidade para realizar os testes ou entender os resultados.

Desvantagens dos testes de acessibilidade automatizados:

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

O teste automatizado é uma ótima primeira etapa para verificar 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 testes manuais de acessibilidade.

Tipos de ferramentas automatizadas

Uma das primeiras ferramentas de teste de acessibilidade automatizado on-line foi desenvolvida em 1996 pelo Centro de Tecnologia Aplicada (CAST, na sigla em inglês), chamada "The Bobby Report". Atualmente, há mais de 100 ferramentas de teste automatizado para escolher.

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

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

  • Quais padrões e níveis de conformidade você está testando? Isso pode incluir WCAG 2.1, WCAG 2.0, Seção 508 dos EUA 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 qual parte do ciclo de vida de desenvolvimento de software você está testando seu produto?
  • Quanto tempo leva para configurar e usar a ferramenta? Para uma pessoa, equipe ou empresa?
  • Quem está conduzindo o teste: designers, desenvolvedores, controle de qualidade ou outra pessoa?
  • Com que frequência você quer verificar a acessibilidade? Quais detalhes devem ser incluídos no relatório? Os problemas precisam estar diretamente vinculados a um sistema de bilhetagem?
  • Quais ferramentas funcionam melhor no seu ambiente? Para sua equipe?

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

Demonstração: teste automatizado

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

Nossa demonstração é um site criado para uma organização fictícia, o Medical Mysteries Club. Este site foi intencionalmente inacessível para a demonstração. Parte dessa inacessibilidade pode ser visível para você, e parte dela (mas não toda) será detectada no nosso teste automatizado.

Etapa 1

No navegador Chrome, instale a extensão do Lighthouse.

muitas maneiras de integrar o Lighthouse ao seu fluxo de trabalho de testes. Vamos usar a extensão do Chrome para esta demonstração.

Etapa 2

Site do Medical Mystery Club.

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

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

Site do Médico Mystery Club, com o painel DevTools do relatório do Lighthouse aberto.

Etapa 4

Clique em Analisar carregamento de página e dê tempo para o Lighthouse executar os testes.

Após a conclusão dos testes, o Lighthouse mostra uma pontuação que mede o nível de acessibilidade do produto que você está testando. A pontuação do Lighthouse é calculada pelo número de problemas, tipos de problema e impacto sobre os usuários dos problemas detectados.

Além de uma pontuação, o relatório do Lighthouse inclui informações detalhadas sobre os problemas detectados e links para recursos para saber mais sobre como corrigir esses problemas. 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.

O site do Medical Mysteries Club recebeu uma pontuação de 62 na pontuação do Lighthouse no nosso teste de dezembro de 2022.

Etapa 5

Agora, analise um exemplo de cada problema de acessibilidade automatizada descoberto e corrija os estilos e marcações relevantes.

Problema 1: papéis ARIA

O primeiro problema afirma: "Elementos com uma [role] ARIA que exigem que os filhos contenham uma [role] específica não têm alguns ou nenhum dos filhos obrigatórios. Algumas funções ARIA mães precisam ter funções filhas específicas para cumprir as tarefas de acessibilidade pretendidas." Saiba mais sobre as regras de funções ARIA.

Na nossa demonstração, o botão de inscrição na newsletter falha:

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

O botão "Assinar" ao lado do campo de entrada tem uma função ARIA incorreta. Nesse caso, a função pode ser removida completamente.

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

Problema 2: ARIA hidden

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 sejam disponibilizados para usuários de tecnologias adaptativas, como leitores de tela. Saiba mais sobre as regras de 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 o que está aninhado abaixo dele) da tecnologia adaptativa.

<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 acessem e insiram 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 enunciam como "botão", o que o torna inutilizável para usuários que dependem desses leitores.

Saiba mais sobre as regras de nomes de botões.

<button role="list" type="submit" tabindex="1">Subscribe</button>
Vamos corrigir isso.

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

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

Problema 4: atributos alternativos da imagem

Os elementos de imagem não têm atributos [alt]. O texto de elementos informativos precisa ser alternativo, curto e descritivo. Elementos decorativos podem ser ignorados com um atributo alternativo vazio. Saiba mais sobre as regras de texto alternativo de imagens.

<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 pelo módulo de imagem que ela é chamada de imagem acionável e requer informações de texto alternativo sobre a finalidade da imagem. Normalmente, a primeira imagem na página é um logotipo. Assim, é possível supor que os usuários de AT saibam disso. Você pode decidir não adicionar essas 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>

Os links não têm um nome compreensível. Textos de link (e textos alternativos de imagens, quando utilizados como links) compreensíveis, únicos 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 isso.

Todas as imagens acionáveis na página precisam incluir informações sobre para onde o link envia 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. 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 segmentar SVGs, adicionar as informações entre as tags <a> e <svg> e, em seguida, ocultá-las visualmente dos usuários, adicionar uma ARIA compatível ou outras opções. Dependendo do ambiente e das restrições de código, um método pode ser preferido em vez de outro.

Use a opção de padrão mais simples com a maior cobertura de tecnologia assistiva, 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 cor.

Dois exemplos foram informados.

O Medical Mysteries Club tem um valor hexadecimal de cor de #01aa9d e o valor hexadecimal de plano de fundo de #ffffff. A proporção de contraste de cores é 2,9:1.
Pontuação do Lighthouse para o texto da síndrome da sereia.
A síndrome da sereia tem um valor hexadecimal de texto de #7c7c7c, enquanto a cor hexadecimal do plano de fundo é #ffffff. A taxa de contraste de cores é 4,2:1.
Vamos corrigir isso.

Foram detectados muitos problemas de contraste de cores na página da Web. Como você aprendeu no módulo cor e contraste, o texto de tamanho normal (menos de 18 pt / 24 px) tem um requisito de contraste de cor de 4,5:1, enquanto o texto 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 de cor azul-esverdeado precisa atender ao requisito de contraste de cores de 3:1, já que é um texto grande de 24 px. No entanto, os botões azul-esverdeado são considerados textos de tamanho normal com 16 px em negrito. Portanto, eles precisam atender ao requisito de contraste de cores de 4,5:1.

Nesse caso, poderíamos encontrar uma cor azul-esverdeado escura o suficiente para atender a 4,5:1 ou aumentar o tamanho do texto do botão para 18,5 px em negrito e mudar o valor da cor azul-esverdeado um pouco. Qualquer um dos métodos permanece alinhado com a estética do design.

Todo o texto cinza no plano de fundo branco também falha no contraste de cores, exceto nos dois títulos maiores da página. Esse texto precisa ser escurecido para atender aos requisitos de contraste de cores de 4,5:1.

O azul-petróleo foi corrigido e não falha mais.
O nome do clube, Medical Mysteries Club, recebeu um valor de cor de #008576, e o plano de fundo continua #ffffff. A proporção de contraste de cores atualizada é de 4,5:1. Clique na imagem para conferir o tamanho original.
O cinza foi corrigido.
Agora, a síndrome da sereia tem um valor de cor de #767676, e o plano de fundo permanece #ffffff. A taxa de contraste de cores é 4,5:1.

Problema 7: estrutura de lista

Os 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 enunciados corretamente.

Saiba mais sobre regras de listas.

<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 desordenada em vez de usar uma tag <ul>. Quando escrevemos esse código incorretamente, removemos os recursos semânticos HTML inerentes integrados a essa tag. Resolvemos esse problema de acessibilidade substituindo a classe por uma tag <ul> real e modificando o CSS relacionado.

<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 de tabindex maior que 0. Um valor maior que 0 implica uma ordem explícita de navegação. Embora tecnicamente válido, isso costuma criar experiências frustrantes para os usuários que dependem de tecnologias adaptativas. Saiba mais sobre as regras de tabindex.

<button type="submit" tabindex="1">Subscribe</button>
Vamos corrigir isso.

A menos que haja um motivo específico para interromper a ordem natural de navegaçã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 de tabulação natural, 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.

Sucesso.
A pontuação do Lighthouse agora é 100, o que significa que você resolveu todos os problemas do Lighthouse.

Aplicamos todas essas atualizações automáticas de acessibilidade a um novo CodePen.

Próxima etapa

Bom trabalho! Você já fez muito, mas ainda não acabou! Em seguida, vamos passar para as verificações manuais, conforme detalhado no módulo teste de acessibilidade manual.

Teste seu conhecimento

Testar seus conhecimentos sobre testes automatizados de acessibilidade

Que tipo de teste você precisa fazer para garantir que seu site seja acessível?

Teste manual
Testes de usuários
Testes automatizados
Testes de tecnologia adaptativa

Quais erros são detectados nos testes automatizados?

Texto alternativo ausente
Rótulos descritivos do formulário
Erros ARIA
Problemas de contraste de cores
Linguagem inclusiva