Teste de acessibilidade automatizado

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

Nos módulos restantes, vamos mudar o foco do design e da criação para os testes de acessibilidade. Vamos compartilhar um processo de teste de três etapas que inclui ferramentas e técnicas de teste automatizadas, manuais e de tecnologia assistiva. Vamos usar a mesma demonstração em todos esses módulos de teste para progredir a página da Web de inacessível para acessível.

Cada teste, automatizado, manual e de tecnologia assistiva, é fundamental para alcançar o produto mais acessível possível. Nossos testes dependem do nível de conformidade A e AA das Diretrizes de Acessibilidade para Conteúdo Web (WCAG) 2.1 como nossos padrões.

Lembre-se de que seu setor, tipo de produto, leis e políticas locais e nacionais ou metas gerais de acessibilidade ditam quais diretrizes seguir e quais níveis atender. Se você não exigir um padrão específico para seu projeto, a recomendação é seguir a versão mais recente da 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ê já sabe, a conformidade de acessibilidade não é a história completa quando se trata de oferecer suporte a pessoas com deficiência. No entanto, é um bom ponto de partida, pois fornece uma métrica que você pode testar. Recomendamos que você realize as seguintes ações além dos testes de conformidade para ajudar a criar produtos mais inclusivos:

• Faça testes de usabilidade com pessoas com deficiência.
• Contrate pessoas com deficiência para trabalhar na sua equipe.
• Consulte uma pessoa ou empresa com experiência em acessibilidade digital.

Noções básicas de testes automatizados

Os testes de acessibilidade automatizados usam 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:

• Repita rapidamente os testes em diferentes estágios 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 no seu produto.
• Falsos positivos informados (um problema é informado que não é uma violação real da WCAG)
• Várias ferramentas podem ser necessárias para diferentes tipos e funções de produtos.

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

Tipos de ferramentas automatizadas

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

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

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

• Quais padrões e níveis de conformidade você está testando? Isso pode incluir WCAG 2.2, WCAG 2.1, 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, um app da Web, um app nativo para dispositivos móveis, um PDF, um 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, QA ou outra pessoa?
• Com que frequência você quer que a acessibilidade seja verificada? Quais detalhes devem ser incluídos no relatório? Os problemas devem ser vinculados diretamente a um sistema de tickets?
• 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 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 de testes de acessibilidade automatizados, 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 por meio de 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. Esse site foi intencionalmente tornado inacessível para a demonstração. Parte dessa inacessibilidade pode ser visível para você, e parte (mas não tudo) será detectada no nosso teste automatizado.

Etapa 1

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

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

Etapa 2

Criamos uma demonstração no CodePen. Visualize-a no modo de depuração para continuar com os próximos testes. Isso é importante, pois 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 navegue até a guia Lighthouse. Limpe todas as opções de categoria, exceto "Acessibilidade". Mantenha o modo como padrão e escolha o tipo de dispositivo em que você está executando os testes.

Etapa 4

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

Quando os testes forem concluídos, o Lighthouse vai mostrar uma pontuação que mede a acessibilidade do produto que você está testando. A pontuação do Lighthouse é calculada pelo número de problemas, tipos de problemas e o impacto nos 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 corrigi-los. O relatório também inclui testes aprovados ou não aplicáveis e uma lista de outros itens a serem verificados manualmente.

Etapa 5

Agora, confira um exemplo de cada problema de acessibilidade automatizado descoberto e corrija os estilos e a marcação relevantes.

Problema 1: funções ARIA

O primeiro problema afirma: "Elementos com uma ARIA [role] 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ção 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 isso.

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

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

Problema 2: ARIA oculto

"[aria-hidden="true"] elementos 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 assistivas, por exemplo, 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 isso.

O campo de entrada tinha um aria-hidden="true" atributo aplicado a ele. A adição desse atributo oculta o elemento (e tudo aninhado abaixo dele) 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 assistiva 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 inutiliza 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 isso.

Quando você remove a função ARIA imprecisa do elemento de botão no problema 1, a palavra "Inscrever-se" 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 de imagem

Os elementos de imagem estão sem atributos [alt]. 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 isso.

Como a imagem do logotipo também é um link, você sabe pelo módulo de imagem que ela é chamada de imagem acionável e exige informações de texto alternativo sobre a finalidade da imagem. Normalmente, a primeira imagem na página é um logotipo. Portanto, você pode presumir que os usuários de tecnologia assistiva vão saber disso e pode decidir não adicionar essas informações contextuais extras à 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 de imagens, quando utilizados como link) 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 do 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 corrigir esse problema é adicionar 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 <svg> tags não podem usar esse método.

Para os ícones de mídia social, que usam tags <svg>, você pode usar um padrão de descrição alternativa diferente direcionado a 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 seu ambiente e das restrições de código, um método pode ser preferível a 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 cores.

Dois exemplos foram informados.

Vamos corrigir isso.

Há muitos problemas de contraste de cores detectados na página da Web. Como você aprendeu em o módulo de cor e contraste, o texto de tamanho normal (menor que 18 pt / 24 px) tem um requisito de contraste de cores de 4,5:1, enquanto o texto 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-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-esverdeados são considerados texto de tamanho normal em negrito de 16 px, portanto, precisam atender ao requisito de contraste de cores de 4,5:1.

Nesse caso, podemos encontrar uma cor azul-esverdeada 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 ligeiramente o valor da cor azul-esverdeada. Qualquer um dos métodos está de acordo com a estética do design.

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

Problema 7: estrutura da lista

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

Saiba mais sobre as regras de 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 isso.

Usamos uma classe CSS nesta demonstração para simular a lista não ordenada em vez de usar uma <ul> tag. Quando escrevemos esse código de maneira inadequada, removemos os recursos HTML semânticos inerentes integrados a essa tag. Ao substituir a classe por uma tag real <ul> 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 de tabindex maior que 0. Um valor maior que 0 indica uma ordem explícita de navegação. Embora tecnicamente válido, isso costuma gerar experiências frustrantes para os usuários que utilizam tecnologias assistivas. 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 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 de tabulação, 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á fez muito, mas ainda não terminamos. Em seguida, vamos passar para as verificações manuais, conforme detalhado no módulo de testes de acessibilidade manual.