Como revisar a acessibilidade

Rob Dodson

Determinar se o site ou aplicativo é acessível pode parecer uma tarefa difícil. Se você está se aproximando da acessibilidade pela primeira vez, a amplitude do tema pode fazer você se perguntar por onde começar. Afinal, trabalhar para acomodar uma variedade de habilidades significa que há uma gama correspondentemente diversificada de problemas a serem considerados.

Esta postagem detalha esses problemas em um processo lógico e passo a passo para analisar um site existente em relação à acessibilidade.

Começar com o teclado

Para usuários que não podem ou não querem usar um mouse, a navegação por teclado é a principal forma de acessar tudo na tela. Esse público-alvo inclui usuários com deficiências motoras, como lesão por esforço repetitivo (LER) ou paralisia, além de usuários de leitores de tela.

Para uma boa experiência com o teclado, tente ter uma ordem de guias lógica e estilos de foco claramente discerníveis.

  • Comece navegando pelo site. A ordem em que os elementos são focados deve seguir a ordem do DOM. Se você não tiver certeza de quais elementos devem receber foco, consulte o módulo do curso Acessibilidade do Google A11y. A prática recomendada é que qualquer controle com que o usuário possa interagir ou fornecer entrada deve ser focado e mostrar um indicador de foco, como um anel de foco.

  • Os controles interativos personalizados precisam ser focalizáveis. Se você usar o JavaScript para transformar um <div> em um menu suspenso sofisticado, ele não será inserido automaticamente na ordem de guias. Para tornar um controle personalizado com foco, atribua a ele um tabindex="0". Valores de tabindex maiores que 0 mudam a ordem das guias e podem confundir os usuários de leitores de tela.

  • Deixe apenas o conteúdo interativo com foco. Adicionar tabindex a elementos não interativos, como títulos, retarda os usuários de teclado que podem ver a tela e não ajuda os usuários de leitores de tela, porque o leitor de tela já sabe como anunciá-los.

  • Se você adicionar novo conteúdo a uma página, direcione o foco do usuário para esse conteúdo primeiro para que ele possa realizar uma ação. Consulte Como gerenciar o foco no nível da página para conferir exemplos.

  • Projete seu site para que o usuário sempre possa focar o próximo elemento quando quiser. Cuidado com widgets de preenchimento automático e outros contextos que podem prender o foco do teclado. Você pode prender o foco temporariamente quando quiser que o usuário interaja com um modal e não com o restante da página, mas sempre forneça uma maneira acessível pelo teclado para sair do modal. Consulte Modals e armadilhas de teclado para conferir um exemplo.

Tornar o controle de foco utilizável

Se você criou um controle personalizado, permita que os usuários acessem todos os recursos usando apenas o teclado. Leia Como gerenciar o foco em componentes para conferir técnicas de melhoria do acesso por teclado.

Gerenciar conteúdo fora da tela

Muitos sites têm conteúdo fora da tela que está presente no DOM, mas não está visível, como links em um menu de gaveta responsivo ou um botão em uma janela modal que ainda não foi mostrada. Ao manter esses elementos no DOM, você pode acabar gerando uma experiência confusa, especialmente para os leitores de tela, que anunciam o conteúdo fora da tela como se ele fizesse parte da página.

Consulte Como lidar com conteúdo fora da tela para saber o que fazer com esses elementos.

Testar com um leitor de tela

Melhorar o suporte geral ao teclado prepara o terreno para a próxima etapa, que é verificar se a página tem rotulagem e semântica adequadas e se há obstruções na navegação do leitor de tela.

Se você não sabe como a marcação semântica é interpretada pela tecnologia auxiliar, leia Estrutura do conteúdo.

  • Verifique se todas as imagens têm o texto alt correto. A exceção a essa prática é quando as imagens são usadas principalmente para fins de apresentação e não são partes essenciais do conteúdo. Para indicar que os leitores de tela precisam pular uma imagem, defina o valor como uma string vazia: alt="".
  • Verifique se há um rótulo em todos os controles. Para controles personalizados, isso pode exigir o uso de aria-label ou aria-labelledby. Consulte Rótulos e relacionamentos ARIA para conferir exemplos.
  • Verifique todos os controles personalizados para um role adequado e todos os atributos ARIA necessários que comunicam o estado deles. Por exemplo, uma caixa de seleção personalizada precisa de role="checkbox" e aria-checked="true|false" para transmitir corretamente o estado dela. Consulte Introdução à ARIA para ter uma visão geral geral de como a ARIA pode fornecer semântica ausente para controles personalizados.
  • Faça com que o fluxo de informações na página faça sentido. Como os leitores de tela navegam pela página na ordem do DOM, eles anunciam todos os elementos que você recolocou visualmente usando CSS em uma ordem sem sentido. Se você precisar que algo apareça mais cedo na página, mova-o fisicamente mais cedo no DOM.
  • Tenha como objetivo oferecer suporte à navegação do leitor de tela para todo o conteúdo na página. Verifique se nenhuma seção do site está permanentemente oculta ou bloqueada para o acesso do leitor de tela.
    • Se o conteúdo precisa ser oculto de um leitor de tela, por exemplo, se ele estiver fora da tela ou apenas na apresentação, defina esse conteúdo como aria-hidden="true". Para uma explicação mais detalhada, consulte Como ocultar conteúdo.

Conheça os leitores de tela

Embora possa parecer difícil aprender a usar um leitor de tela, eles são bem fáceis de usar. Em geral, a maioria dos desenvolvedores utiliza apenas alguns comandos de tecla simples.

Se você estiver usando um Mac, confira este vídeo sobre o VoiceOver, o leitor de tela que vem com o Mac OS. Caso esteja usando um PC, confira este vídeo sobre o NVDA, um leitor de tela de código aberto sem custos financeiros compatível com Windows.

aria-hidden não impede o foco do teclado

É importante entender que a ARIA só pode afetar a semântica de um elemento. Ela não tem efeito sobre o comportamento do elemento. É possível fazer com que um elemento fique oculto para leitores de tela com aria-hidden="true", mas isso não muda o comportamento de foco desse elemento. Para conteúdo interativo fora da tela, use o atributo inert para garantir que ele seja removido do fluxo do teclado. Para navegadores mais antigos, combine aria-hidden="true" com tabindex="-1".

Os elementos interativos precisam indicar a finalidade e o estado deles.

Fornecer dicas visuais, ou affordances, sobre o que um controle vai fazer ajuda uma grande variedade de pessoas em uma grande variedade de dispositivos a operar e navegar pelo seu site.

  • Elementos interativos, como links e botões, precisam ser distinguíveis de elementos não interativos. É difícil para os usuários navegar em um site ou app quando não conseguem saber se um elemento é clicável. Há muitas maneiras válidas de indicar elementos interativos. Uma prática comum é sublinhar links para diferenciar do texto ao redor.
  • Semelhante ao requisito de foco, elementos interativos, como links e botões, exigem um estado hover para informar aos usuários do mouse quando o ponteiro está sobre algo clicável. No entanto, para tornar esses elementos acessíveis a outros métodos de entrada, eles precisam ser distinguíveis sem um estado hover.

Aproveite os títulos e pontos de referência

Os títulos e elementos de referência dão estrutura semântica à sua página e aumentam muito a eficiência de navegação dos usuários de tecnologias adaptativas. Muitos usuários de leitores de tela relatam que, quando chegam a uma página desconhecida, geralmente tentam navegar pelos títulos.

Da mesma forma, os leitores de tela também oferecem a capacidade de pular para pontos de referência importantes, como <main> e <nav>. Por esses motivos, é importante considerar como a estrutura da página pode ser usada para orientar a experiência do usuário.

  • Use a hierarquia h1-h6. Pense nos títulos como ferramentas para criar um esboço da página. Não dependa do estilo integrado dos títulos. Em vez disso, trate-os como se tivessem o mesmo tamanho e use o nível semanticamente apropriado para conteúdo primário, secundário e terciário. Em seguida, use o CSS para fazer com que os cabeçalhos correspondam ao seu design.
  • Use elementos e funções de marco para que os usuários possam pular o conteúdo repetitivo. Muitas tecnologias adaptativas oferecem atalhos para pular para partes específicas da página, como aquelas definidas por elementos <main> ou <nav>. Esses elementos têm papéis de marco implícitos. Também é possível usar o atributo ARIA role para definir explicitamente regiões na página, como em <div role="search">. Consulte Semântica e navegação de conteúdo para mais exemplos.
  • Evite usar role="application", a menos que você tenha experiência com ele. O papel de marco application informa à tecnologia adaptativa para desativar os atalhos e transmitir todas as teclas pressionadas para a página. Isso significa que as teclas que os usuários de leitores de tela normalmente usam para se mover pela página não funcionam mais, e você vai precisar implementar todo o processamento do teclado.

Revisar títulos e pontos de referência com um leitor de tela

Os leitores de tela, como o VoiceOver e o NVDA, oferecem um menu de contexto para pular para regiões importantes da página. Ao testar a acessibilidade, você pode usar esses menus para ter uma visão geral da página e determinar se os níveis de título são adequados e quais pontos de referência estão em uso.

Para saber mais, assista estes vídeos instrutivos sobre os conceitos básicos de VoiceOver e NVDA.

Automatizar o processo

Testar manualmente a acessibilidade de um site pode ser tedioso e propenso a erros. É benéfico automatizar os testes o máximo possível. É possível usar extensões de navegador e pacotes de teste de acessibilidade de linha de comando.

  • A página passou em todos os testes das extensões do navegador aXe ou WAVE? Há outras opções disponíveis, mas essas extensões podem ser uma adição útil a qualquer processo de teste manual, porque podem detectar problemas sutis, como taxas de contraste inadequadas e atributos ARIA ausentes.
    • Se você preferir trabalhar na linha de comando, axe-cli oferece os mesmos recursos que a extensão do navegador aXe, mas pode ser executada no terminal.
  • Para evitar regressões, especialmente em um ambiente de integração contínua, incorpore uma biblioteca como axe-core ao seu pacote de testes automatizados. O axe-core é o mesmo mecanismo que alimenta a extensão aXe do Chrome, mas em um utilitário de linha de comando.
  • Se você estiver usando um framework ou biblioteca, ele oferece as próprias ferramentas de acessibilidade? Por exemplo, o protractor-accessibility-plugin para Angular. Use as ferramentas disponíveis sempre que possível.

Usar o Lighthouse para testar PWAs

O Lighthouse é uma ferramenta que mede o desempenho do seu Progressive Web App (PWA). E usa a biblioteca axe-core para executar os testes de acessibilidade.

Se você já usa o Lighthouse, procure testes de acessibilidade com falhas no seu relatório. Corrija os erros para melhorar a experiência geral do usuário no seu site.

Outros recursos