Melhorar a acessibilidade torna seu site mais acessível para todos.
É importante criar sites inclusivos e acessíveis a todos. Há pelo menos seis áreas principais de deficiência que podem ser otimizadas: visual, audição, mobilidade, cognição, fala e neural. Muitas ferramentas e recursos podem ajudar, mesmo que você seja totalmente novo na acessibilidade na Web.
Mais de um bilhão de pessoas vivem com algum tipo de deficiência.
Para serem acessíveis, os sites precisam funcionar em vários dispositivos com tamanhos de tela variados e tipos de entrada diferentes, como leitores de tela. Além disso, os sites precisam ser utilizáveis pelo maior número de usuários, incluindo pessoas com deficiência.
Aqui estão algumas deficiências que seus usuários podem ter:
| Visão | Audição | Questões de mobilidade |
|---|---|---|
|
|
|
| Cognição | Voz | Neural |
|
|
|
Os problemas visuais variam de incapacidade de distinguir cores até nenhuma visão.
- Verifique se o conteúdo de texto atende a um limite mínimo de taxa de contraste.
- Evite comunicar informações usando apenas cores e garanta que todo o texto seja resizable.
- Garanta que todos os componentes da interface do usuário possam ser usados com tecnologias adaptativas, como leitores de tela, lupas e linhas braille. Isso envolve garantir que os componentes da interface sejam marcados de modo que as APIs de acessibilidade possam determinar programaticamente papel, estado, valor e título de qualquer elemento.
Vivo pessoalmente com baixa visão e muitas vezes me vejo concentrando em sites, no DevTools e no terminal. O suporte ao zoom quase nunca está no topo das listas de tarefas dos desenvolvedores, mas ele pode fazer um mundo de diferença para usuários como eu.
Os problemas auditivos indicam que um usuário pode ter problemas para ouvir o som emitido por uma página.
- Forneça alternativas de texto para todo conteúdo que não seja estritamente texto.
- Teste se os componentes da interface ainda estão funcionando sem som.
Problemas de mobilidade podem incluir a incapacidade de operar um mouse, um teclado ou uma tela touchscreen.
- Torne o conteúdo dos componentes de interface funcionalmente acessível em um teclado para qualquer ação em que um mouse seria usado.
- Verifique se as páginas estão marcadas corretamente para tecnologias adaptativas, incluindo leitores de tela, software de controle de voz e controles de interruptor físicos, que tendem a usar as mesmas APIs.
Os problemas cognitivos significam que um usuário pode precisar de tecnologias adaptativas para ajudar na leitura de textos. Por isso, é importante garantir que haja alternativas para o texto.
Tenha cuidado ao usar animações. Evite vídeos e animações que se repetem ou flash, porque podem causar problemas para alguns usuários.
A consulta de mídia CSS
prefers-reduced-motionpermite limitar animações e vídeos com reprodução automática para usuários que preferem movimento reduzido:/* If the user expresses a preference for reduced motion, don't use animations on buttons. */ @media (prefers-reduced-motion: reduce) { button { animation: none; } }Evite interações baseadas no tempo.
Isso pode parecer uma série de bases a serem abordadas, mas vamos analisar o processo para avaliar e melhorar a acessibilidade dos componentes da interface.
Para oferecer mais suporte visual, a equipe de acessibilidade do GOV.UK criou uma série de pôsteres digitais sobre acessibilidade, que podem ser usados para compartilhar práticas recomendadas com sua equipe.
Medir a acessibilidade do componente da interface
Ao auditar a acessibilidade dos componentes da IU da página, pergunte-se:
Você pode usar o componente de interface apenas com o teclado?
O componente gerencia o foco e evita armadilhas? Ele consegue responder aos eventos apropriados de teclado?
É possível usar o componente de interface com um leitor de tela?
Você forneceu alternativas em texto para qualquer informação apresentada visualmente? Você adicionou informações semânticas usando ARIA?
O componente de interface funciona sem som?
Desligue os alto-falantes e analise seus casos de uso.
O componente de interface funciona sem cores?
Verifique se o componente de IU pode ser usado por alguém que não vê cores. Uma ferramenta útil para simular o daltonismo é uma extensão do Chrome chamada Colorblindly. Experimente as quatro formas de simulação de daltonismo disponíveis. A extensão Daltonize também pode ser útil, porque é igualmente útil.
O componente de IU funciona com o modo de alto contraste ativado?
Todos os sistemas operacionais modernos são compatíveis com o modo de alto contraste. O Alto contraste é uma extensão do Chrome que pode ajudar nesse caso.
Os controles padronizados (como <button> e <select>) têm acessibilidade
integrada ao navegador. Eles são focalizáveis usando a tecla Tab,
respondem a eventos do teclado (como Enter, Space e teclas de seta)
e têm funções, estados e propriedades semânticos usados pelas ferramentas de acessibilidade.
O estilo padrão também precisa atender aos requisitos de acessibilidade listados.
Os componentes de interface personalizados, exceto aqueles que estendem elementos
padrão, como <button>, não têm recursos integrados, incluindo
acessibilidade. Portanto, é necessário fornecê-los. Um bom ponto de partida ao
implementar a acessibilidade é comparar seu componente com um elemento padrão
análogo (ou uma combinação de vários elementos padrão, dependendo da complexidade
do componente).
A maioria das ferramentas para desenvolvedores de navegador oferece suporte à inspeção da árvore de acessibilidade de uma página. No Chrome DevTools, esse recurso está disponível na guia Acessibilidade do painel Elementos.
O Firefox também tem um painel de Acessibilidade.
O Safari expõe informações de acessibilidade na guia Nó do painel Elementos.
Confira a seguir uma lista de perguntas que você pode fazer a si mesmo ao tentar tornar os componentes da interface mais acessíveis.
Melhorar o foco do teclado
O ideal é garantir que todas as funcionalidades do componente de IU possam ser acessadas com um teclado. Ao projetar sua experiência do usuário, pense em como você usaria seu elemento apenas com o teclado e descubra um conjunto consistente de interações de teclado.
Primeiro, tenha um objetivo de foco sensato para cada componente. Por exemplo, um componente complexo, como um menu, pode ser um alvo de foco em uma página, mas precisa gerenciar o foco em si mesmo para que o item de menu ativo sempre tenha foco.
Usar tabindex
Você pode adicionar o foco do teclado para elementos e componentes de interface com o atributo
tabindex. Os usuários de tecnologias adaptativas e somente de teclado precisam poder colocar
o foco do teclado nos elementos para interagir com eles.
Elementos interativos integrados (como <button>) são implicitamente focalizáveis. Portanto, eles não precisam de um atributo tabindex, a menos que você precise mudar a posição deles
na ordem da tabulação.
Há três tipos de valores tabindex:
tabindex="0"é o mais comum e coloca o elemento na ordem de tabulação natural (definida pela ordem DOM).- Um valor de
tabindexmaior que 0 coloca o elemento em uma ordem de tabulação manual. Todos os elementos da página com um valortabindexpositivo são acessados em ordem numérica, antes dos elementos na ordem natural de tabulação. - Um valor
tabindexigual a -1 faz com que o elemento seja focalizável de maneira programática, mas não na ordem de tabulação.
Para componentes de interface personalizados, sempre use valores tabindex de 0 ou -1, já que não
é possível determinar a ordem dos elementos em uma determinada página com antecedência. Um
valor tabindex de -1 é particularmente útil para gerenciar o foco em componentes
complexos.
O foco precisa estar sempre visível, seja usando o estilo de anel de foco padrão ou aplicando um estilo de foco personalizado perceptível. Lembre-se de não capturar os usuários de teclado. Eles precisam ser capazes de tirar o foco de um elemento usando apenas o teclado.
Usar o autofoco
O atributo de autofoco em HTML permite que um autor especifique que um determinado
elemento precisa receber foco automaticamente
quando a página é carregada.
A autofocus já oferece suporte a
todos os controles de formulários da Web,
incluindo botões.
Para focar automaticamente os elementos nos seus componentes de interface personalizados,
chame o método focus(),
que oferece suporte a todos os elementos HTML que podem ser focados
(por exemplo, document.querySelector('myButton').focus()).
Adicionar interação do teclado
Quando o componente de interface estiver focalizável, forneça uma boa história de interação com o teclado
quando um componente estiver em foco, processando eventos apropriados do teclado.
Por exemplo, permita que o usuário use teclas de seta para selecionar opções de menu
e Space ou Enter para ativar botões.
O guia de padrões de design ARIA
fornece algumas orientações aqui.
Por fim, verifique se os atalhos do teclado são detectáveis. Uma prática comum é ter uma legenda de atalho do teclado (texto na tela) para informar ao usuário que existem atalhos. Por exemplo, "Pressione ? para os atalhos do teclado." Como alternativa, uma dica como essa pode ser usada para informar o usuário sobre um atalho.
A importância de gerenciar o foco não pode ser subestimada. Um exemplo importante é uma gaveta de navegação. Se você adicionar um componente de IU à página, será necessário direcionar o foco para um elemento dentro dela. Caso contrário, os usuários poderão precisar percorrer a página inteira para chegar lá. Essa experiência pode ser frustrante, por isso, teste o foco para todos os componentes navegáveis por teclado na sua página.
// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);
// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);
// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);
// toggle category by pressing Space
await page.keyboard.press('Space');
// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);
Garantir o uso bem-sucedido do leitor de tela
Cerca de 1% a 2% das pessoas usam um leitor de tela. Você consegue entender todas as informações importantes e interagir com o componente usando apenas o leitor de tela e o teclado?
As perguntas a seguir devem ajudar você a abordar a acessibilidade do leitor de tela.
Todos os componentes e imagens têm alternativas de texto significativas?
Sempre que as informações sobre o nome ou a finalidade de um componente interativo forem transmitidas visualmente, forneça uma alternativa de texto acessível.
Por exemplo, se o componente de interface <fancy-menu> mostrar apenas um ícone de engrenagem
para indicar que é um menu de configurações,
ele vai precisar de uma alternativa de texto acessível, como "settings",
que transmita as mesmas informações.
Dependendo do contexto,
é possível fornecer uma alternativa de texto usando um atributo alt,
um atributo aria-label, um atributo aria-labelledby
ou texto simples no Shadow DOM.
Encontre dicas técnicas gerais na Referência rápida do WebAIM.
Todo componente da IU que exibe uma imagem precisa fornecer um mecanismo
para fornecer texto alternativo para essa imagem, análogo ao atributo alt.
Seus componentes fornecem informações semânticas?
A tecnologia adaptativa transmite informações semânticas que são expressas de outra forma para usuários com deficiência visual por meio de indicações visuais, como formatação, estilo do cursor ou posição. Os elementos padronizados têm essas informações semânticas integradas ao navegador. No entanto, para componentes personalizados, é necessário usar ARIA para adicionar as informações.
Em geral, qualquer componente que ouça um evento de clique do mouse ou de passar o cursor precisa ter algum tipo de listener de eventos de teclado e um papel ARIA, possivelmente estados e atributos ARIA também.
Por exemplo, um componente de interface <fancy-slider> personalizado pode assumir uma função ARIA de controle deslizante,
que tem alguns atributos ARIA relacionados: aria-valuenow, aria-valuemin e aria-valuemax.
Ao vincular esses atributos às propriedades relevantes no seu componente personalizado,
você pode permitir que usuários de tecnologia adaptativa interajam com o elemento,
mudem o valor dele e até mesmo alterem a apresentação visual dele.
<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>
Os usuários conseguem entender tudo sem depender da cor?
A cor não deve ser usada como o único meio de transmitir informações, por exemplo, indicar um status, solicitar uma resposta ou visualizar dados. Por exemplo, se você tiver um gráfico de pizza, forneça rótulos e valores para cada fatia para que usuários com deficiência visual possam entender as informações, mesmo que não possam ver onde os pedaços começam e terminam:
Há contraste suficiente?
Todo conteúdo de texto exibido no componente precisa atender ao limite mínimo de contraste do nível AA das WCAG. Forneça um tema de alto contraste que atenda ao limite de AAA maior e garanta que as folhas de estilo do user agent possam ser aplicadas se os usuários exigirem um contraste personalizado ou cores diferentes. Você pode usar esse Verificador de contraste de cores como ajuda ao projetar seu componente.
O conteúdo em movimento ou piscando é seguro e pode ser interrompido?
Os usuários precisam conseguir pausar, parar ou ocultar conteúdo que se move, rola ou pisque por mais de cinco segundos. Em geral, evite a atualização flash do conteúdo.
Se algo precisar piscar, certifique-se de que ele pisca no máximo três vezes por segundo.
Ferramentas e testes de acessibilidade
Há mais de 100 ferramentas disponíveis para avaliar a acessibilidade do seu site e dos respectivos componentes. Algumas ferramentas são automatizadas, enquanto outras exigem testes manuais.
Veja alguns exemplos:
- O Axe oferece testes de acessibilidade automatizados para o framework ou o navegador de sua escolha. O Axe Puppeteer pode ser usado para escrever testes de acessibilidade automatizados.
Uma auditoria de acessibilidade do Lighthouse fornece insights úteis para descobrir problemas comuns de acessibilidade. A pontuação de acessibilidade é uma média ponderada de todas as auditorias de acessibilidade com base em avaliações de impacto do usuário do Axe. Para monitorar a acessibilidade com integração contínua, consulte Lighthouse CI.
O Tenon.io é útil para testar problemas comuns de acessibilidade. O Tenon oferece um forte suporte à integração em ferramentas de build, navegadores (usando extensões) e até mesmo editores de texto.
Existem muitas ferramentas específicas de biblioteca e framework para destacar problemas de acessibilidade com componentes. Por exemplo, use eslint-plugin-jsx-a11y para destacar problemas de acessibilidade de componentes do React no seu editor.
Se você usa o Angular, o codelyzer também oferece auditorias de acessibilidade no editor:
Trabalhar com tecnologias assistivas
- Você pode examinar a forma como as tecnologias adaptativas veem o conteúdo da Web usando o
Inspetor de acessibilidade (Mac)
ou as Ferramentas de teste da API Windows Automation
e o AccProbe (Windows).
Também é possível ver a árvore de acessibilidade completa que o Chrome cria
navegando até
about://accessibility. - A melhor maneira de testar a compatibilidade com leitores de tela em um Mac é usando o utilitário VoiceOver. Use
⌘F5para ativar ou desativar essa opção,Ctrl+Option ←→para navegar pela página eCtrl+Shift+Option + ↑↓para subir e descer na árvore de acessibilidade. Para instruções mais detalhadas, consulte a lista completa de comandos do VoiceOver e a lista de comandos da Web do VoiceOver. No Windows, o NVDA é um leitor de tela sem custo financeiro e de código aberto. No entanto, ele tem uma curva de aprendizado íngreme para usuários que não enxergam.
O ChromeOS tem um leitor de tela integrado.
Temos um longo caminho pela frente para melhorar a acessibilidade na Web. De acordo com o Almanaque da Web:
- Quatro em cada cinco sites têm texto que se mistura ao plano de fundo, o que os torna ilegíveis.
- 49,91% das páginas ainda não fornecem atributos
altpara algumas imagens. - Somente 24% das páginas que usam botões ou links incluem rótulos.
- Somente 22,33% das páginas fornecem rótulos para todas as entradas de formulário.
Podemos fazer muito para criar experiências mais acessíveis para todos.