Como revisar a acessibilidade

Rob Dodson

Determinar se um site ou aplicativo é acessível pode parecer uma esmagadora. Se você está abordando a acessibilidade pela primeira vez, o o tema pode fazer com que você se pergunte por onde começar. Afinal, trabalhar para acomodar uma gama diversificada de habilidades significa que há que precisa considerar uma gama correspondentemente diversificada.

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

Começar pelo teclado

Para usuários que não podem ou escolhem não usar um mouse, a navegação pelo teclado é é a principal forma 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, bem como usuários de leitores de tela.

Para uma boa experiência com o teclado, use uma ordem lógica de tabulação e clareza e discerníveis.

  • Comece navegando pelo site. A ordem em que os elementos são focados devem seguir a ordem do DOM. Se você não tiver certeza de quais elementos devem receber consulte o módulo do curso "Aprenda sobre acessibilidade" sobre foco. Os melhores a prática é que qualquer controle com o qual o usuário possa interagir ou fornecer entrada precisa ser focalizável e exibir 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 em ordem de tabulação. Para tornar um controle personalizado focalizável, atribua a ele um tabindex="0". Valores de tabindex maiores que 0 alteram a ordem da tabulação e podem ser confusos para para usuários de leitores de tela.

  • Torne apenas o conteúdo interativo focalizável. Adicionando tabindex a elementos que não são do elementos interativos, como cabeçalhos, atrasam os usuários do teclado, que podem ver o tela e não ajuda os usuários do leitor de tela porque ele já sabe divulgá-los.

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

  • Projete seu site para que o usuário possa sempre focar o próximo elemento quando quiser. Cuidado com os widgets de preenchimento automático e outros contextos que podem interceptar o foco do teclado. Você pode capturar o foco temporariamente quando quiser que o usuário interagir com um modal e não com o resto da página, mas você deve sempre fornecem uma maneira de escapar do modal, acessível pelo teclado. Consulte Modais e armadilhas de teclado como exemplo.

Tornar seu controle de foco utilizável

Se você criou um controle personalizado, permita que seus usuários acessem todos os recursos usando apenas o teclado. Lida Como gerenciar o foco em componentes e conhecer técnicas para melhorar o acesso ao teclado.

Gerenciar conteúdo fora da tela

Muitos sites têm conteúdo fora da tela presente no DOM, mas que não é visível. como links dentro de um menu de gaveta responsiva ou um botão em uma janela modal que ainda não foi exibida. Ao deixar esses elementos no DOM, confusa, especialmente para leitores de tela, que anunciar o conteúdo fora da tela como se fizesse parte da página.

Consulte Como lidar com conteúdo fora da tela para 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 a página quanto à rotulagem e semântica adequadas e quaisquer obstruções para à navegação do leitor de tela.

Se você não souber como a marcação semântica é interpretada por assistivos tecnologia, leia Estrutura de conteúdo.

  • Verifique se todas as imagens têm texto alt adequado. A exceção a essa prática é quando as imagens servem principalmente para fins de apresentação e não são peças essenciais conteúdo. Para indicar que os leitores de tela devem pular uma imagem, defina o para uma string vazia: alt="".
  • Verifique se há um marcador em todos os controles. Para controles personalizados, isso pode exigir a uso de aria-label ou aria-labelledby. Consulte Rótulos e Relações ARIA para ver exemplos.
  • Marque todos os controles personalizados para um role apropriado e qualquer ARIA necessária atributos que comunicam o estado. Por exemplo, uma caixa de seleção personalizada precisa um role="checkbox" e um aria-checked="true|false" para transmitir corretamente estado. Consulte Introdução a ARIA para informações gerais visão geral de como ARIA pode fornecer semântica ausente para controles personalizados.
  • Faça sentido no fluxo de informações na sua página. Porque a tela os leitores navegarem pela página na ordem DOM, eles anunciarão os elementos que você reposicionado visualmente usando CSS em uma ordem sem sentido. Se você precisar que apareça mais cedo na página, mova-a fisicamente para mais cedo no DOM.
  • Procure oferecer suporte à navegação do leitor de tela para todo o conteúdo da página. Garanta nenhuma seção do site está permanentemente oculta ou bloqueada na tela o acesso de leitor.
    • Se o conteúdo deve ficar oculto para um leitor de tela, por exemplo, se for fora da tela ou apenas de apresentação, defina esse conteúdo como aria-hidden="true". Para uma explicação mais detalhada, consulte Ocultação de conteúdo.

Conhecer os leitores de tela

Pode parecer difícil aprender um leitor de tela, mas eles são bem fáceis de usar. Em geral, a maioria dos desenvolvedores pode conseguir comandos de teclas.

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

O aria-hidden não impede o foco do teclado

É importante entender que ARIA só pode afetar a semântica de uma element; ele não afeta o comportamento do elemento. É possível fazer um elemento oculto para leitores de tela com aria-hidden="true", mas isso não mudar o comportamento de foco desse elemento. Para conteúdo interativo fora da tela, Para conteúdo interativo fora da tela, use o atributo inert. para garantir que ela seja realmente removida do fluxo do teclado. Em navegadores mais antigos, combinar aria-hidden="true" com tabindex="-1".

Elementos interativos precisam indicar a finalidade e o estado

Fornecer dicas visuais, ou affordances, sobre o que um controle fará ajuda uma grande variedade de pessoas em uma ampla variedade de dispositivos operam e navegam em seu site.

  • Elementos interativos, como links e botões, devem ser distinguíveis dos elementos não interativos. É difícil para os usuários navegar em um site ou aplicativo 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 diferenciá-los 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, elas precisam ser distinguíveis sem um estado hover.

Aproveitar cabeçalhos e pontos de referência

Títulos e elementos de ponto de referência dão a estrutura semântica da página, e aumentam muito a eficiência de navegação dos usuários de tecnologia assistiva. Muitas usuários de leitores de tela relatam que, ao acessar pela primeira vez uma página desconhecida, ela normalmente tenta navegar por cabeçalhos.

Da mesma forma, 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 os 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 para sua página. Não dependa do estilo integrado dos títulos. Em vez disso, trate-os como se fossem todos do mesmo tamanho e usem o nível semanticamente apropriado para conteúdo primário, secundário e terciário. Em seguida, use CSS para tornar os cabeçalhos correspondem ao seu design.
  • Use funções e elementos de referência para que os usuários possam ignorar conteúdo repetitivo. Muitas as tecnologias assistivas oferecem atalhos para pular para partes específicas da página, como aqueles definidos pelos elementos <main> ou <nav>. Esses elementos têm pontos de referência implícitos. Também é possível usar o atributo ARIA role para defina explicitamente as regiões na página, como em <div role="search">. Consulte Consulte Semântica e navegação pelo conteúdo para saber mais exemplos.
  • Evite role="application", a menos que você tenha experiência com ele. O papel de ponto de referência application instrui a tecnologia adaptativa a desativar atalhos de teclado e passar por todas as teclas pressionadas na página. Isso significa que as chaves os leitores de tela que os usuários costumam usar para navegar pela página não funcionam mais, e você terá que implementar todo o processamento do teclado por conta própria.

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

Leitores de tela, como VoiceOver e NVDA, oferecem um menu de contexto para pular 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 o cabeçalho níveis são apropriados e quais pontos de referência estão em uso.

Para saber mais, consulte estes vídeos com instruções sobre as noções básicas do VoiceOver e NVDA

Automatizar o processo

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

  • A página foi aprovada em todos os testes da aXe ou WAVE extensões de navegador? Há outras opções disponíveis, mas essas extensões podem ser uma adição útil a qualquer processo de teste manual, porque podem identifique problemas sutis, como falhas nas taxas de contraste e ausência de ARIA atributos.
    • Se preferir trabalhar na linha de comando, axe-cli oferece os mesmos recursos como a extensão de navegador aXe, mas pode ser executado no seu terminal.
  • Para evitar regressões, principalmente em um ambiente de integração contínua, incorporar uma biblioteca como axe-core ao seu pacote de testes automatizados. a axe-core é a mesma motora da aXe do Chrome, mas em um utilitário de linha de comando.
  • Se você usa um framework ou biblioteca, ele tem recursos de acessibilidade próprios? ferramentas? 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 avalia o desempenho do seu Progressive Web App (PWA). Além disso, ele usa a biblioteca axe-core para aprimorar os testes de acessibilidade.

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

Outros recursos