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. 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 nesses módulos de teste para tornar a página da Web inacessível e 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 para Conteúdo Web (WCAG) 2.1 nível de conformidade A e AA como nossos padrões. Lembre-se de que seu setor, tipo de produto, leis locais e do país e políticas ou metas gerais de acessibilidade determinam quais diretrizes seguir e os níveis a serem cumpridos. Se você não precisa 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ê já sabe, a conformidade com a acessibilidade não é o suficiente para ajudar 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 com conhecimento em acessibilidade digital para ajudar você a criar produtos mais inclusivos.
Noções básicas de testes automatizados
O teste automatizado de acessibilidade usa software para verificar se há problemas de acessibilidade em relação aos padrões de conformidade 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 automatizados de acessibilidade:
- As ferramentas automatizadas não detectam todos os erros de acessibilidade no produto.
- Falsos positivos relatados (um problema é relatado que não é uma violação real do 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 automatizada foi desenvolvida em 1996 pelo Center for Applied Special Technology (CAST), chamado "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 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, um app da Web, um app nativo para dispositivos móveis, um PDF, um quiosque ou outro produto.
- 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 que a acessibilidade seja verificada? Quais detalhes devem ser incluídos 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 do WAI sobre como selecionar ferramentas de avaliação de acessibilidade da 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 teste de acessibilidade automatizado, vamos usar o Lighthouse do Chrome. 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 dessa inacessibilidade pode ser visível para você, e parte dela (mas não toda) será detectada no nosso teste automatizado.
Etapa 1
Usando o navegador Chrome, instale o Extensão do Lighthouse.
Há muitas maneiras de integrar o Lighthouse ao seu fluxo de trabalho de teste. Vamos usar a extensão do Chrome para esta demonstração.
Etapa 2
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> 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". Limpe 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 o carregamento da 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. O Pontuação do Lighthouse é calculado pelo número de problemas, tipos de problema e impacto sobre os usuários do os 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 os testes aprovados ou não aplicáveis e um lista de itens adicionais para verificar manualmente.
Etapa 5
Agora, confira um exemplo de cada problema de acessibilidade automático descoberto e corrija os estilos e marcações relevantes.
Problema 1: funções 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 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>
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, 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 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 nomes de botões.
<button role="list" type="submit" tabindex="1">Subscribe</button>
Quando você remove o papel incorreto da ARIA do elemento do botão no problema 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 o texto alternativo de imagem
regras.
<a href="index.html">
<img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>
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, 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. 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>
Todas as imagens interativas na página precisam incluir informações sobre para onde
o link direciona os usuários. Um método para resolver esse problema é adicionar um texto alternativo
à imagem sobre o propósito, 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 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. Dependendo
nas restrições de ambiente e código, um método pode ser melhor
para outra.
Use a opção de padrão mais simples com a cobertura de
tecnologia de assistência, 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 cor
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.
#01aa9d e o valor hexadecimal de plano de fundo de #ffffff. A taxa de contraste de cores é 2,9:1. 
#7c7c7c, enquanto a cor hexadecimal do plano de fundo é #ffffff. A taxa de contraste de cores é 4,2:1.
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 regular (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 se trata de 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.
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. Qualquer um dos métodos permanece alinhado com a estética do design.
Todo o texto cinza sobre o fundo branco também falha no contraste de cores, exceto para os dois maiores títulos da página. Esse texto precisa ser escurecido para atender aos requisitos de contraste de cores de 4,5:1.
#008576, e o plano de fundo continua #ffffff. A proporção de contraste de cores atualizada é 4,5:1. Clique na imagem para visualizá-la no tamanho original.
#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>
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. 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 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>
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 deve ser muito melhor do que na primeira execução.
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
Teste seus conhecimentos sobre testes de acessibilidade automatizados
Que tipo de teste você deve fazer para garantir que seu site seja acessível?
Quais erros são detectados nos testes automatizados?