Como revisar a acessibilidade

Rob Dodson

Determinar se o site ou aplicativo está acessível pode parecer uma tarefa desanimadora. Se você está abordando a acessibilidade pela primeira vez, a amplitude do tópico pode fazer com que você se pergunte por onde começar. Afinal, trabalhar para acomodar uma gama diversificada de habilidades significa que há uma gama correspondentemente diversa de problemas a serem considerados.

Esta postagem divide esses problemas em um processo lógico e passo a passo para analisar um site existente quanto à acessibilidade.

Começar com o teclado

Para usuários que não podem ou optam por não usar um mouse, a navegação pelo teclado é o principal meio de alcançar tudo na tela. Esse público-alvo inclui usuários com deficiências motoras, como lesão por estresse repetitivo (RSI) ou paralisia, além de usuários de leitores de tela.

Para uma boa experiência com o teclado, tente usar uma ordem lógica de tabulação e estilos de foco claramente distinguíveis.

  • Comece navegando pelo site. A ordem em que os elementos são focados deve seguir a ordem do DOM. Se você não souber ao certo quais elementos precisam receber foco, consulte Conceitos básicos de foco para relembrar o assunto. A prática recomendada é que qualquer controle com que um usuário possa interagir ou fornecer entrada precisa ser focalizável e mostrar um indicador de foco, como um anel de foco.

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

  • Torne apenas o conteúdo interativo focalizável. A adição de tabindex a elementos não interativos, como cabeçalhos, desacelera os usuários de teclado que conseguem ver a tela e não ajuda os usuários de leitores de tela, porque o leitor já sabe que eles devem ser anunciados.

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

  • Crie seu site para que o usuário possa sempre focar o próximo elemento quando quiser. Cuidado com widgets de preenchimento automático e outros contextos que podem capturar o foco do teclado. Você pode capturar temporariamente o foco 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 de sair do modal. Consulte Modais e interceptações de teclado para conferir um exemplo.

Tornar seu 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 conhecer técnicas que podem melhorar o acesso ao teclado.

Gerenciar conteúdo fora da tela

Muitos sites têm conteúdo fora da tela que está presente no DOM, mas não visível, como links em um menu gaveta responsivo ou um botão dentro de uma janela modal que ainda não foi exibida. Deixar esses elementos no DOM pode criar uma experiência de teclado 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 ver dicas de como lidar com esses elementos.

Testar com um leitor de tela

A melhoria do suporte geral ao teclado cria uma base para a próxima etapa, que é verificar se a página tem a identificação 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 assistiva, leia Estrutura do conteúdo.

  • Verifique se todas as imagens têm texto de alt adequado. A exceção a essa prática é quando as imagens servem 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 marcador 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 ver exemplos.
  • Confira se todos os controles personalizados têm uma role adequada e todos os atributos ARIA obrigatórios que comunicam o estado. Por exemplo, uma caixa de seleção personalizada precisa de role="checkbox" e aria-checked="true|false" para transmitir corretamente o estado. Consulte Introdução a ARIA para ter uma visão geral de como ARIA pode fornecer semântica ausente para controles personalizados.
  • Faça com que o fluxo de informações pela sua página faça sentido. Como os leitores de tela navegam na página na ordem do DOM, eles anunciam todos os elementos que você reposicionaram visualmente usando o CSS em uma ordem sem sentido. Se você precisar que algo apareça mais cedo na página, mova-o fisicamente para a posição anterior no DOM.
  • Tente oferecer suporte à navegação do leitor de tela para todo o conteúdo da página. Verifique se nenhuma seção do site está permanentemente oculta ou bloqueada do acesso do leitor de tela.
    • Se o conteúdo precisa ser ocultado de um leitor de tela, por exemplo, se estiver fora da tela ou apenas de apresentação, defina-o como aria-hidden="true". Para uma explicação mais detalhada, consulte Como ocultar conteúdo.

Conhecer leitores de tela

Embora possa parecer complicado para usar um leitor de tela, na verdade eles são muito fáceis de usar. Em geral, a maioria dos desenvolvedores consegue com apenas alguns comandos de teclas simples.

Se você estiver em um Mac, confira este vídeo sobre o VoiceOver, o leitor de tela do Mac OS. Se você tiver um PC, confira este vídeo sobre o NVDA, um leitor de tela de código aberto compatível com doações.

aria-hidden não impede o foco do teclado

É importante entender que ARIA só pode afetar a semântica de um elemento. Ela não afeta o comportamento do elemento. É possível ocultar um elemento 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 realmente removido do fluxo do teclado. Para navegadores mais antigos, combine aria-hidden="true" com tabindex="-1".

Elementos interativos precisam indicar a finalidade e o estado.

Fornecer dicas visuais, ou affordances, sobre a função de um controle ajuda várias pessoas em uma grande variedade de dispositivos a operar e navegar no seu site.

  • Elementos interativos, como links e botões, precisam ser distinguíveis dos elementos não interativos. É difícil para os usuários navegar em um site ou app quando não conseguem dizer se um elemento é clicável. Há muitas maneiras válidas de indicar elementos interativos. Uma prática comum é sublinhar links para diferenciá-los do texto ao redor.
  • Assim como o 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.

Aproveitar cabeçalhos e pontos de referência

Os títulos e elementos de ponto de referência fornecem a estrutura semântica da sua página e aumentam consideravelmente a eficiência de navegação dos usuários de tecnologia adaptativa. Muitos usuários de leitores de tela relatam que, quando acessam uma página desconhecida, geralmente tentam navegar por cabeçalhos.

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 sua página pode ser usada para orientar a experiência do usuário.

  • Use a hierarquia h1-h6. Pense nos cabeçalhos como ferramentas para criar um contorno da página. Não dependa do estilo integrado de cabeçalhos. Em vez disso, trate-os como se fossem do mesmo tamanho e use o nível semanticamente apropriado para conteúdo primário, secundário e terciário. Em seguida, use CSS para que os cabeçalhos correspondam ao seu design.
  • Use funções e elementos de ponto de referência para que os usuários possam ignorar conteúdo repetitivo. Muitas tecnologias assistivas oferecem atalhos para pular para partes específicas da página, como as definidas por elementos <main> ou <nav>. Esses elementos têm funções de ponto de referência implícitas. Você também pode usar o atributo ARIA role para definir explicitamente as regiões na página, como em <div role="search">. Consulte Semântica e navegação de conteúdo para mais exemplos.
  • Evite role="application", a menos que você tenha experiência em trabalhar com ele. O papel de ponto de referência application instrui a tecnologia adaptativa a desativar os atalhos e transmitir todos os pressionamentos de tecla na página. Isso significa que as teclas do leitor de tela que os usuários normalmente usam para navegar pela página não funcionam mais, e você precisará implementar todo o tratamento do teclado.

Revisar cabeçalhos e pontos de referência com um leitor de tela

Leitores de tela, como VoiceOver e NVDA, oferecem um menu de contexto para pular para regiões importantes na 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 cabeçalho são adequados e quais pontos de referência estão em uso.

Para saber mais, consulte estes vídeos com instruções sobre os conceitos básicos do VoiceOver e do NVDA (links em inglês).

Automatizar o processo

Testar manualmente a acessibilidade de um site pode ser entediante e propenso a erros. É vantajoso automatizar os testes o máximo possível. Você pode usar extensões do navegador e pacotes de testes de acessibilidade de linha de comando.

  • A página passa em todos os testes das extensões de navegador aXe ou WAVE? Há outras opções disponíveis, mas essas extensões podem ser uma adição útil para qualquer processo de teste manual, porque podem detectar problemas sutis, como falhas nas taxas de contraste e atributos ARIA ausentes.
    • Caso prefira trabalhar na linha de comando, o axe-cli fornece os mesmos recursos que a extensão de navegador aXe, mas pode ser executado no seu 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 aciona 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. Aproveite as ferramentas disponíveis sempre que possível.

Usar o Lighthouse para testar PWAs

O Lighthouse é uma ferramenta que mede o desempenho do Progressive Web App (PWA). Além disso, ela usa a biblioteca axe-core para aprimorar os testes de acessibilidade.

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

Outros recursos