Todo ano, o WebAIM analisa o um milhão de sites mais visitados do mundo em busca de conformidade com acessibilidade. Todo ano, os resultados são quase idênticos.

Em 2025, 94,8% das homepages tinham ao menos uma falha detectável pelo WCAG. Esse número vem de testes automatizados, que capturam apenas 30 a 40% dos problemas reais de acessibilidade. A taxa real de falhas é consideravelmente pior.

Seis categorias de erro respondem por 96% de todas as falhas detectadas. As mesmas seis. Todo ano. Desde 2019.

Nenhuma delas é difícil de corrigir. Todas elas são decididas antes de uma única linha de código ser escrita.

01

Contraste

1.1 A falha mais comum da web

Texto com contraste insuficiente aparece em 79,1% das homepages analisadas pelo WebAIM em 2025. É a principal falha de acessibilidade em todos os anos desde o início do estudo.

Essa é uma decisão estética, tomada por um designer que olhou para um cinza claro em fundo branco e achou refinado. Em um monitor calibrado, em ambiente controlado, com alta resolução, provavelmente estava. Para um usuário com baixa visão, lendo em uma tela barata sob a luz do sol, o texto desaparece.

Salvar alterações

2,8:1 · falha no AA (exige 4,5:1) 7,0:1 · passa no AAA

Mesmo texto, mesmo fundo. Só o cinza ficou mais escuro.

1.2 AA e AAA: o que significam e quando cada um se aplica

O WCAG define requisitos de contraste em dois níveis de conformidade.

Nível AA exige uma proporção mínima de contraste de 4,5:1 para texto normal e 3:1 para texto grande (18pt regular ou 14pt negrito). Esse é o padrão base para a maioria dos produtos digitais. Se a sua interface não atinge o AA, ela falha no critério legal e ético mais básico na maioria das jurisdições.

Nível AAA exige 7:1 para texto normal e 4,5:1 para texto grande. Esse é o alvo para interfaces onde o usuário depende criticamente da leitura, como sistemas médicos, plataformas financeiras ou ferramentas jurídicas.

A maioria das equipes de produto deveria projetar para AA em toda a interface. O AAA não é opcional quando as consequências de uma leitura errada são altas.

1.3 O problema do botão desabilitado

Existe um padrão específico que design systems repetem constantemente e ninguém questiona: o botão desabilitado com opacidade reduzida.

A convenção existe por um motivo. A opacidade comunica inatividade. Mas reduzir a opacidade também reduz o contraste, muitas vezes deixando o texto bem abaixo do mínimo de 4,5:1. O usuário com baixa visão não consegue ler o que o botão diz. Não consegue entender o que precisa fazer para ativá-lo. A interface falha exatamente no momento em que ele mais precisa de orientação.

A correção não exige abandonar a convenção. Exige adicionar um segundo canal de comunicação: um tooltip explicando por que a ação está indisponível, um texto abaixo do botão, um ícone sinalizando o que está faltando. A opacidade pode ficar. O texto precisa permanecer legível.

Ferramentas como o Colour Contrast Analyser, o plugin Able para Figma e o WebAIM Contrast Checker permitem verificar qualquer par de cores antes de chegar ao desenvolvedor. Isso é uma decisão de design. Deve ser testada na etapa de design.

A seguir: AA vs AAA, quando cada nível de contraste se aplica, e por que o seu botão desabilitado provavelmente está falhando nos dois. Em breve.

02

Cor como único indicador de estado

2.1 Uma história do daily standup

No início da minha carreira, trabalhei com um desenvolvedor back-end que codificava profissionalmente há anos. Descobrimos que ele era daltônico durante uma conversa completamente comum. Não durante uma revisão de design. Não durante um handoff. Durante um daily standup em que alguém mencionou a cor da camisa de futebol de um colega.

Comecei a prestar atenção em como ele experimentava meus handoffs. Estados de erro marcados com uma borda vermelha. Estados de sucesso em verde. Estados de aviso em amarelo. Três cores, três estados, contexto adicional zero. Para ele, dois desses três estados eram efetivamente invisíveis.

Ele tinha compensado em silêncio por anos. Trabalhando em volta da interface em vez de através dela.

A deuteranopia e a deuteranomalia, as formas mais comuns de daltonismo, afetam a percepção de vermelho e verde. Afetam aproximadamente 8% dos homens e 0,5% das mulheres. Em qualquer equipe de doze pessoas, estatisticamente uma tem algum grau de deficiência na visão de cores. Em qualquer produto com milhares de usuários, o número não é marginal.

Visão normal

Simulação de deuteranopia

Três campos de formulário, só com cor. Na simulação, erro e sucesso ficam quase da mesma cor.

2.2 A solução é sempre um segundo canal

A cor nunca deve ser a única forma que uma interface comunica estado. Campos com erro precisam de uma borda vermelha, um ícone de erro e uma mensagem de texto explicando o que está errado. Estados de sucesso precisam da confirmação verde e de uma confirmação escrita. Estados de aviso precisam da cor e de um rótulo explícito.

Nada disso exige redesenhar a linguagem visual. Exige adicionar mais uma camada que não depende da percepção de cores.

Antes de fechar qualquer design de estado, passe por um simulador de daltonismo. Quando comecei minha carreira, isso significava tirar um screenshot, abrir o Photoshop e dessaturar a imagem para verificar o contraste. Hoje, plugins como Stark ou Color Oracle fazem isso diretamente dentro da ferramenta de design. O processo manual era tedioso. O processo moderno leva dez segundos. Nenhum dos dois é difícil. Ambos exigem que o designer pense nisso em primeiro lugar.

Em breve: uma análise completa dos tipos de daltonismo, ferramentas de simulação e como auditar um design system existente em busca de falhas baseadas apenas em cor, em Projetando para daltonismo: por que vermelho e verde nunca são suficientes.

03

Navegação por teclado

3.1 Quem realmente usa o teclado

Navegação por teclado é a interface primária para usuários com deficiências motoras, usuários cegos navegando com leitores de tela, e um número significativo de usuários avançados que acham o teclado mais rápido que o mouse.

De acordo com a pesquisa de leitores de tela do WebAIM de 2024, 97,6% dos usuários de leitores de tela dependem da navegação por teclado. Deficiências motoras afetam aproximadamente 26 milhões de adultos somente nos Estados Unidos, muitos dos quais usam teclados ou dispositivos equivalentes como entrada primária.

78% das páginas analisadas pelo WebAIM em 2024 tinham problemas detectáveis com indicadores de foco. O indicador de foco é o contorno visual que mostra qual elemento tem o foco do teclado no momento. É, para usuários de teclado, o equivalente ao cursor do mouse. Sem ele, o usuário não sabe onde está na interface.

Sem indicador de foco

Indicador de foco visível

Pressione Tab nesses dois botões e compare o que acontece.

3.2 Como testar em dois minutos

Largue o mouse. Abra o seu produto. Pressione Tab.

Observe se você consegue ver qual elemento tem foco em cada etapa. Observe se consegue alcançar cada elemento interativo, completar cada ação e sair de cada modal ou dropdown sem tocar no mouse uma vez sequer. Observe se pressionar Tab segue uma ordem de leitura lógica ou pula de forma imprevisível pela tela.

Se você não consegue completar um fluxo central do usuário usando apenas o teclado, uma parcela significativa dos seus usuários também não consegue.

3.3 O skip link que nem o Google implementa

Todo site com navegação repetida entre páginas deveria ter um skip link. É um link, visualmente oculto por padrão, que se torna visível quando o usuário pressiona Tab pela primeira vez. Lê algo como "Pular para o conteúdo principal." Quando ativado, move o foco direto para além da navegação, até o conteúdo da página.

Sem ele, um usuário de teclado chegando a qualquer página precisa pressionar Tab em cada item de navegação antes de alcançar qualquer conteúdo. Em um site com um cabeçalho contendo oito links de navegação, quatro links secundários, um campo de busca e um seletor de idioma, são quinze ou mais Tab presses antes de chegar a algo útil.

A implementação é um link âncora e algumas linhas de CSS. E ainda assim, no momento em que este artigo foi escrito, o YouTube (um produto criado pelo Google, a organização que escreveu muitos dos padrões web que tornam a acessibilidade possível) não o implementa corretamente.

Se o Google não pega isso, o seu produto provavelmente também não tem. Adicione.

No próximo post: um guia prático para implementar navegação por teclado do zero, incluindo ordem de tab, gerenciamento de foco dentro de modais e skip links, em Navegação por teclado: como testar seu produto sem tocar no mouse.

04

ARIA: a ferramenta que a maioria dos designers nunca ouviu falar

4.1 O que é e por que você provavelmente não sabe que existe

ARIA significa Accessible Rich Internet Applications. É uma especificação publicada pelo W3C que define um conjunto de atributos HTML para comunicar o papel, estado e propriedades de elementos de interface para tecnologias assistivas.

aria-label dá um nome a um elemento que não tem texto visível. aria-expanded informa a um leitor de tela se um dropdown ou menu está aberto ou fechado. aria-describedby associa um campo de formulário à sua mensagem de erro para que o leitor de tela leia ambos juntos.

Isso é um detalhe de implementação técnica. A maioria dos designers nunca vai escrever um atributo ARIA diretamente. Eu não sabia que o acrônimo existia até vários anos de carreira, e isso não é incomum dado o quão específicos tendem a ser os contextos que o exigem.

Mas aqui está a parte que envolve o designer.

4.2 O que o designer especifica que torna o ARIA necessário

Quando você projeta um modal, está tomando decisões sobre como ele se comporta. Quando abre, o foco deve se mover para dentro dele. Quando fecha, o foco deve retornar ao elemento que o acionou. Enquanto está aberto, o foco do teclado deve ficar contido dentro dele para que o usuário não interaja acidentalmente com o conteúdo por trás do overlay.

Esse comportamento é especificado no design. Se o designer documenta isso, o desenvolvedor sabe que precisa implementar. Se o designer não documenta, o desenvolvedor muitas vezes não sabe que precisa existir.

O ARIA é o que torna esse comportamento legível para tecnologias assistivas. O designer não escreve o atributo. O designer decide o comportamento que exige o atributo. Essa distinção importa.

Páginas que usam ARIA têm em média 34% mais erros de acessibilidade do que páginas sem ele. O motivo não é que o ARIA seja ruim. É que o ARIA é frequentemente implementado de forma incorreta, muitas vezes porque ninguém especificou como ele deveria se comportar em primeiro lugar.

Uma nota prática para quem é desenvolvedor lendo isso: se o seu designer não especificou o comportamento de foco na documentação, isso é uma lacuna, mas não significa que você não pode implementar corretamente mesmo assim. O conhecimento viaja nas duas direções.

O próximo post aborda o que é ARIA, quando é necessário e como documentar comportamento interativo para que desenvolvedores tenham o que precisam para implementar corretamente, em O que é ARIA e por que designers de produto precisam entender.

05

O componente errado

5.1 A escolha de componente é uma decisão de acessibilidade

Um dropdown com duas opções é uma falha de acessibilidade, não apenas uma ineficiência de UX.

Um usuário de teclado abrindo um dropdown precisa navegar até o gatilho, abri-lo, mover entre as opções com as setas, selecionar uma e fechar. Um toggle cumpre o mesmo objetivo em uma única interação. O componente errado multiplica o trabalho para todo usuário que não consegue usar o mouse, e faz isso de forma invisível, porque ninguém testou o fluxo com o teclado.

5 interações de teclado para alternar

1 interação de teclado para alternar

Mesma escolha, mesmo resultado. Uma exige cinco teclas, a outra, uma.

A escolha do componente é feita no design. As consequências de acessibilidade também.

Outros casos comuns em que o componente errado quebra a acessibilidade antes que o desenvolvedor escreva uma linha de código:

  • Usar um <div> como botão. Um <div> não recebe foco do teclado por padrão. Um <button> recebe. Quando um designer especifica uma área clicável sem especificar que deve ser um elemento button semântico, desenvolvedores às vezes o constroem como um <div> com um evento de clique. O resultado parece idêntico na tela e é completamente inacessível pelo teclado.
  • Usar texto de placeholder como rótulo. Placeholders desaparecem quando o usuário começa a digitar. Um usuário que precisa verificar o que um campo está pedindo durante a entrada não tem como recuperar essa informação. Rótulos devem ser visíveis e persistentes.
  • Usar botões somente com ícone sem texto alternativo. Um botão de ícone sem rótulo é invisível para um leitor de tela. O usuário sabe que um botão existe. Não sabe o que ele faz. Todo elemento interativo somente com ícone precisa de uma alternativa textual, visível ou não.

Ainda por vir: uma análise componente por componente das falhas de acessibilidade comuns em design systems, e como escrever documentação de componentes que as previna na etapa de implementação, em Decisões de componente que quebram a acessibilidade antes do desenvolvedor escrever uma linha de código.

Os mesmos seis erros. Todo ano.

O WebAIM realiza sua análise do um milhão de sites mais visitados todos os anos desde 2019. Em seis anos, a taxa geral de falhas melhorou 3,1 pontos percentuais. Nesse ritmo, alcançar uma conformidade ampla de acessibilidade levaria décadas.

As seis categorias de erro que respondem por 96% de todas as falhas não são complexas. Não são casos extremos que exigem conhecimento especializado. São contraste, alt text faltando, rótulos de formulário faltando, links vazios, idioma do documento faltando e visibilidade do foco. Todos rastreáveis a decisões tomadas antes da primeira linha de código existir.

Acessibilidade é uma consequência do que foi decidido no arquivo de design, na biblioteca de componentes, na documentação do design system e nas especificações de comportamento entregues para a engenharia, não uma tarefa de QA ou uma responsabilidade do desenvolvedor de corrigir depois que o design está pronto.

As decisões são tomadas na etapa de design. As falhas aparecem em produção. A lacuna entre os dois é onde a maioria dos produtos vive permanentemente.

Fontes