Teste de acessibilidade automatizado

Até agora, neste curso, você aprendeu sobre o indivíduo, os negócios e aspectos jurídicos da acessibilidade digital e noções básicas de acessibilidade digital e conformidade. Você explorou tópicos específicos relacionados ao design inclusivo e codificação, incluindo quando usar ARIA versus HTML, como medir contraste de cor, quando JavaScript é essencial, entre outros.

Nos módulos restantes, vamos passar do design e da criação para o teste para acessibilidade. Utilizaremos um processo de teste de três etapas que inclui técnicas e ferramentas de teste de tecnologia assistiva, automatizadas e manuais. Vamos use a mesma demonstração ao longo desses módulos de teste para avançar a página da Web inacessíveis a acessíveis.

Cada teste (automatizado, manual e de tecnologia assistiva) é fundamental para atingir o produto mais acessível possível.

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

Como você sabe, a conformidade de acessibilidade não é o processo completo quando de apoiar pessoas com deficiência. Mas este é um bom ponto de partida porque ele fornece uma métrica que pode ser testada. Recomendamos que você faça ações adicionais fora do teste de conformidade de acessibilidade, como realizar testes de usabilidade com pessoas com deficiência, contratar pessoas com deficiências para trabalhar em sua equipe ou consultar um indivíduo ou empresa conhecimento em acessibilidade digital para ajudar você a criar produtos mais inclusivos.

Noções básicas de testes automatizados

Os testes automatizados de acessibilidade usam um software para verificar se há itens problemas de acessibilidade com padrões de conformidade predefinidos.

Prós 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
• Pouco conhecimento sobre acessibilidade é necessário para executar os testes ou entender os resultados

Contras 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 e funções de produtos

Os testes automatizados são uma ótima etapa inicial para verificar se há acessibilidade, 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 automatizadas on-line foi desenvolvida em de 1996 pelo Center for Applied Special Technology (CAST), chamado "The Bobby Report". Hoje, existem mais de 100 ferramentas de teste automatizadas para escolher

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

A escolha da ferramenta automatizada vai depender de muitos fatores, incluindo:

• Quais padrões e níveis de conformidade você está comparando? Isso pode incluem WCAG 2.1, WCAG 2.0, EUA Seção 508 ou uma lista modificada de regras de acessibilidade.
• Que tipo de produto digital você está testando? Pode ser um site, uma página da Web aplicativo, aplicativo nativo para dispositivos móveis, PDF, quiosque ou outro produto.
• Em que parte do ciclo de vida de 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, controle de qualidade etc.?
• Com que frequência você quer verificar a acessibilidade? Quais detalhes devem ser incluído no relatório? Caso os problemas estejam diretamente ligados a uma venda de passagens sistema operacional?
• Quais ferramentas funcionam melhor no seu ambiente? Para sua equipe?

Há muitos outros fatores a serem considerados também. Confira o artigo da WAI em "Seleção de ferramentas de avaliação de acessibilidade na Web" para mais informações sobre como escolher a melhor ferramenta para você e sua equipe.

Demonstração: teste automatizado

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

Nossa demonstração é um site criado para uma organização fictícia, a Medical Mysteries Clube Este site é intencionalmente inacessível para a demonstração. Parte disso inacessibilidade pode ser visível para você e alguns (mas não todos) serão capturados do teste automatizado.

Etapa 1

Usando o navegador Chrome, instale o Extensão do Lighthouse.

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

Etapa 2

Criamos uma demonstração no CodePen. Visualize-o no modo de depuração para continuar com o os próximos testes. Isso é importante porque remove o <iframe> ao redor da página da Web de demonstração, o que pode interferir em algumas ferramentas de teste. Saiba mais sobre Modo de depuração do CodePen.

Etapa 3

Abra o Chrome DevTools e acesse 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 que você está para executar os testes.

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 exibe uma pontuação que mede quanto acessíveis ao produto que você está testando. A Pontuação do Lighthouse é calculado pelo número de problemas, tipos de problema e impacto nos usuários do os problemas detectados.

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

Etapa 5

Agora, vamos ver um exemplo de cada problema de acessibilidade automatizada descobertos e corrigir os estilos e marcações relevantes.

Problema 1: papéis ARIA

O primeiro problema diz: "Elementos com um [papel] ARIA que exigem que os filhos contêm um [role] específico sem alguns ou todos os filhos obrigatórios. Algumas funções ARIA principais precisam ter funções filhas específicas para realizar funções de acessibilidade pretendidas”. Saiba mais sobre as regras de funções ARIA.

Em nossa demonstração, o botão de inscrição na newsletter não funciona:

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

Vamos corrigir isso.

A opção "inscrever-se" o botão ao lado do campo de entrada tem uma função ARIA incorreta aplicados a ela. 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. Focalizável descendentes em um elemento [aria-hidden="true"] impedem as interações que os elementos fiquem disponíveis para usuários de tecnologias assistivas como leitores. Saiba mais sobre aria-hidden regras.

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

Vamos corrigir isso.

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

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

Nesse caso, você deve remover esse atributo da entrada para permitir que as pessoas usando tecnologia assistiva 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 tiver um nome acessível, os leitores de tela o anunciam como "botão", o que o torna inutilizável para usuários que dependem de leitores de tela. 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 a função ARIA imprecisa do elemento botão na problema 1, a palavra "Inscrever-se" se torna o botão acessível nome. Essa funcionalidade é integrada ao elemento de botão HTML semântico. são opções de padrão adicionais a serem consideradas em 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 os atributos [alt]. Os elementos informativos precisam ter como objetivo para um texto alternativo curto e descritivo. Os elementos decorativos podem ser ignorados com um atributo alternativo vazio. Saiba mais sobre o texto alternativo de imagem regras.

<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 é chamado de um módulo imagem e exige informações de texto alternativas sobre a finalidade dela. Normalmente, a primeira imagem na página é um logotipo, então você pode presumir seus usuários de AT saberão isso, e você pode decidir não adicionar essa 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. Texto do link (e texto alternativo para imagens, quando usadas como links) que seja perceptível, única e focalizável melhora a experiência de navegação para usuários de leitores de tela. Saiba mais sobre as regras de texto para links.

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

Vamos corrigir isso.

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

Para os ícones de redes sociais, que usam tags <svg>, você pode usar um padrão alternativo de descrição diferente segmentando SVGs, adicione a informação entre as tags <a> e <svg> e, em seguida, escondê-la dos usuários, adicionar uma ARIA compatível ou outras opções. Depende nas restrições de ambiente e código, um método pode ser melhor outra. Vamos usar a opção de estampa mais simples com o modelo a cobertura de tecnologia, que é adicionar um role="img" à tag <svg> e incluindo um elemento <title>.

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

Problema 6: contraste de cor

As cores de primeiro e segundo planos 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 relatados.

.

Vamos corrigir isso.

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

Para o título da página, o texto azul-petróleo precisa atender ao contraste de cor de 3:1. porque o texto é de tamanho grande (24 px). No entanto, os botões azul-petróleo são considerados texto de tamanho normal em negrito de 16 px, portanto, precisam ter a cor 4.5:1 requisito de contraste.

Neste caso, poderíamos encontrar uma cor azul-petróleo que era escura o suficiente para atender a 4,5:1, ou podemos aumentar o tamanho do texto do botão para 18,5px em negrito e mudar o azul-petróleo um pouco. Os dois métodos vão seguir o design estética.

Todo o texto cinza no fundo branco também falha no contraste de cores, exceto para os dois maiores títulos da página. O texto precisa ser escurecido para atender a os requisitos de contraste de cor 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 pai. <ul> ou <ol> sejam anunciados 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 isso.

Usamos uma classe CSS nesta demonstração para simular a lista desordenada em vez de usando uma tag <ul>. Quando escrevemos esse código incorretamente, removemos a recursos HTML semânticos incorporados a essa tag. Ao substituir a classe por um modelo <ul> e modificando o CSS relacionado, vamos resolver 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 zero. Um valor maior que 0 implica uma ordem explícita de navegação. Embora isso seja tecnicamente válido, muitas vezes cria experiências frustrantes para usuários que dependem de 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 na Web página, não é necessário ter um número inteiro positivo em um atributo tabindex. Para manter a ordem natural da 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 automatizada, abra uma nova página do modo de depuração. Execute a auditoria de acessibilidade do Lighthouse novamente. Sua pontuação é muito melhor do que na primeira execução.

Aplicamos todas essas atualizações automáticas de acessibilidade a uma nova CodePen.

Próxima etapa

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

Teste seu conhecimento

Teste seus conhecimentos sobre testes de acessibilidade automatizados