Acessibilidade digital é a diferença entre uma pessoa conseguir usar seu produto sozinha ou não conseguir. Não é um recurso extra nem um modo especial: é a propriedade de o mesmo produto funcionar para quem enxerga pouco, para quem não usa mouse, para quem não ouve o áudio e para quem processa informação de outro jeito.
No Brasil isso também é obrigação legal desde 2015, e continua sendo ignorado na maior parte dos projetos. Este texto cobre o que a norma pede, o que a lei exige, o que corrigir primeiro e como testar sem depender de chute.
O que é acessibilidade digital
Acessibilidade digital é o conjunto de decisões de design e de código que permite que sites, aplicativos e documentos sejam percebidos, operados e entendidos por qualquer pessoa, com ou sem deficiência, usando ou não uma tecnologia assistiva.
Tecnologia assistiva é o software ou equipamento que faz a ponte: leitor de tela, ampliador, teclado adaptado, controle por sopro, comando de voz, linha braille. Nenhum deles inventa informação. Se a imagem não tem descrição, o leitor de tela anuncia apenas que existe uma imagem. Se o botão foi feito com uma <div>, ele não é anunciado como botão nem recebe foco pelo teclado. A tecnologia assistiva só consegue expor o que o código declarou.
Vale separar dois termos que costumam ser confundidos. Inclusão digital é sobre acesso à internet e a dispositivos, um problema de infraestrutura e renda. Acessibilidade digital é sobre o produto funcionar depois que a pessoa já está conectada, e é um problema de projeto, que pertence a quem constrói.
Quem encontra barreira, e qual
Segundo a PNAD Contínua de 2022 do IBGE, cerca de 18,6 milhões de pessoas com 2 anos ou mais têm alguma deficiência no Brasil, aproximadamente 8,9% da população. É mais gente do que a soma dos habitantes de várias capitais, e é apenas a parte permanente do problema.
Boa parte das barreiras atinge também quem não tem deficiência alguma: pessoa idosa, quem quebrou o braço, quem está no sol forte, quem assiste ao vídeo sem som no transporte, quem usa uma conexão instável. Corrigir para o caso extremo melhora o caso comum, que é a razão prática de o assunto interessar mesmo a quem só olha conversão.
| Barreira | Como aparece na tela | O que resolve |
|---|---|---|
| Visual | Imagem sem descrição, texto de baixo contraste, informação dada só por cor | Texto alternativo, contraste adequado, rótulo além da cor |
| Auditiva | Vídeo e áudio sem legenda ou transcrição | Legenda sincronizada e transcrição do conteúdo |
| Motora | Ação que só funciona com mouse, alvo de clique minúsculo, foco invisível | Navegação completa por teclado, alvos maiores, foco visível |
| Cognitiva | Texto denso, formulário sem instrução, erro genérico, tempo limite curto | Linguagem simples, instrução antes do campo, erro que diz o que fazer |
WCAG: 4 princípios e 3 níveis
A referência técnica do mundo inteiro são as WCAG, Diretrizes de Acessibilidade para Conteúdo Web, publicadas pelo W3C. A versão atual é a 2.2, de outubro de 2023. Elas se organizam em quatro princípios, e a ordem importa porque funcionam em série:
- Perceptível. A informação precisa chegar por mais de um sentido. Imagem com descrição, vídeo com legenda, contraste suficiente, conteúdo que não depende só de cor ou só de forma.
- Operável. Tudo o que se faz com mouse precisa funcionar com teclado. Sem armadilha de foco, com tempo suficiente para concluir, sem animação que dispare crise em quem tem epilepsia fotossensível.
- Compreensível. Linguagem clara, comportamento previsível, formulário que explica o erro e como corrigir. Idioma da página declarado no código, para o leitor de tela pronunciar certo.
- Robusto. O código precisa ser interpretável por navegadores e tecnologias assistivas diferentes, hoje e depois. Na prática: HTML semântico, e ARIA só onde o HTML não dá conta.
São em série no sentido literal: cumprir três e falhar em um não entrega acesso parcial, entrega barreira. Um formulário perfeitamente perceptível e compreensível que não recebe foco pelo teclado é intransponível para quem não usa mouse.
Cada princípio se desdobra em critérios de sucesso, distribuídos em três níveis:
| Nível | O que significa |
|---|---|
| A | O mínimo. Abaixo disso há conteúdo simplesmente inacessível para grupos inteiros |
| AA | O alvo prático, adotado como referência por legislações no mundo todo. É o que se deve buscar |
| AAA | O mais rigoroso. O próprio W3C não recomenda exigi-lo para um site inteiro |
Na dúvida sobre onde mirar, a resposta é AA. Ela inclui, por exemplo, o contraste mínimo de 4,5 para 1 entre texto e fundo, que sozinho já reprova boa parte dos sites publicados.
O que a lei brasileira exige
O artigo 63 da Lei Brasileira de Inclusão, a Lei 13.146 de 2015, é direto:
É obrigatória a acessibilidade nos sítios da internet mantidos por empresas com sede ou representação comercial no País ou por órgãos de governo, para uso da pessoa com deficiência, garantindo-lhe acesso às informações disponíveis, conforme as melhores práticas e diretrizes de acessibilidade adotadas internacionalmente.
Três pontos costumam passar despercebidos nessa redação. O primeiro é que ela vale para empresa privada, e não apenas para governo. O segundo é que a expressão “melhores práticas e diretrizes adotadas internacionalmente” é o que traz as WCAG para dentro da obrigação legal, já que a lei não define critérios próprios. O terceiro é que sites de órgãos públicos federais seguem também o eMAG, o modelo de acessibilidade do governo eletrônico.
Como acontece com a proteção de dados, a obrigação existe há anos e o descumprimento vira risco jurídico concreto quando alguém reclama. O paralelo com o que a LGPD exige em segurança da informação é exato: uma prática que era recomendável virou dever com consequência.
O que corrigir primeiro
A distribuição das falhas é surpreendentemente concentrada. Um punhado de correções repetitivas resolve a maior parte dos problemas encontrados em auditoria:
- Texto alternativo em imagem. Descreva a função, não o arquivo. Imagem puramente decorativa leva
alt="", para o leitor de tela pular em vez de anunciar o nome do arquivo. - Contraste. Cinza-claro sobre branco é a falha mais comum, e costuma vir de uma decisão estética tomada sem verificar o número.
- Rótulo em campo de formulário. Todo campo precisa de
<label>associado. Texto dentro do campo como único rótulo desaparece quando a pessoa começa a digitar. - HTML semântico. Use
<button>para botão e<a>para link. A<div>com evento de clique não recebe foco, não responde ao Enter e não é anunciada como controle. - Foco visível. Remover o contorno de foco no CSS por achá-lo feio elimina a única pista de onde a pessoa está na página.
- Hierarquia de títulos. Um
<h1>por página e níveis em ordem. Quem usa leitor de tela navega pelos títulos como quem passa os olhos pela página. - Legenda em vídeo. Beneficia surdos e todo mundo que assiste sem som, que hoje é a maioria.
Nada disso é caro quando entra no começo, e todo caro quando entra no fim. Por isso o lugar dessa decisão é a definição de escopo do produto, junto com os outros requisitos, e não uma tarefa de ajuste depois do lançamento. Um design system ajuda muito aqui: contraste, foco e rótulo resolvidos uma vez no componente valem para todas as telas que o usarem.
Dois contextos merecem atenção extra. Em aplicações de página única, trocar conteúdo sem recarregar não avisa o leitor de tela nem move o foco, o que exige anúncio de rota explícito. E no celular, alvo de toque pequeno e zoom bloqueado são falhas frequentes, o que reforça a lógica de projetar primeiro para o celular.
Como testar de verdade
Existem ferramentas automáticas boas e gratuitas: axe DevTools, WAVE e o Lighthouse que já vem no Chrome. Elas encontram contraste insuficiente, imagem sem alt, campo sem rótulo e idioma não declarado, em segundos.
E aqui está a informação que quase nunca aparece: o teste automático detecta menos da metade dos problemas reais. Ele verifica se existe um texto alternativo, não se aquele texto descreve a imagem. Confere se há um rótulo, não se o rótulo faz sentido. Uma página pode marcar cem por cento no Lighthouse e continuar inutilizável.
Os dois testes que faltam custam pouco e valem mais:
- Guarde o mouse. Percorra a página inteira com Tab, Shift+Tab, Enter e Espaço. Você consegue chegar a todos os controles? Vê onde está o foco? Consegue sair de um menu ou de uma janela modal? Essa checagem sozinha revela a maioria das falhas de operabilidade.
- Ligue um leitor de tela. Todo sistema já traz um: VoiceOver no Mac e no iPhone, Narrador no Windows, TalkBack no Android, e o NVDA é gratuito. Ouvir a própria página por dez minutos costuma ser mais convincente do que qualquer relatório.
O passo final, quando o produto é crítico, é teste com pessoas com deficiência de verdade. Nenhuma simulação substitui alguém que usa leitor de tela todos os dias e navega rápido demais para o seu site acompanhar.
Por que o plugin mágico não resolve
Existe uma categoria de produto que promete acessibilidade com uma linha de JavaScript: o widget que adiciona um botão flutuante com opções de aumentar fonte, mudar contraste e ativar um modo de leitura. São os chamados overlays.
Eles são atraentes porque prometem transformar conformidade em compra, e a comunidade técnica de acessibilidade os critica de forma consistente, por três razões práticas:
- Não corrigem a origem. Um script rodando depois do carregamento não conserta HTML mal estruturado, botão que não é botão, nem fluxo que não funciona por teclado. Ele cobre a superfície.
- Atrapalham quem já tem sua configuração. Quem depende de tecnologia assistiva já ajustou o próprio sistema. Um widget que tenta assumir o controle costuma conflitar com o que a pessoa usa.
- Produzem falsa segurança. A empresa instala, considera o assunto resolvido, e para de investir no que resolveria de fato.
Recursos de ajuste na interface não são inúteis, e alguns ajudam. O erro é tratá-los como substituto do trabalho estrutural. Acessibilidade não é uma camada que se aplica por cima de um software aplicativo pronto: é uma propriedade de como ele foi construído, e o caminho curto continua sendo começar pelo HTML certo.
Perguntas frequentes
O que é acessibilidade digital?
É o conjunto de decisões de design e de código que permite que sites, aplicativos e documentos sejam percebidos, operados e entendidos por qualquer pessoa, com ou sem deficiência, usando ou não uma tecnologia assistiva. Não é um recurso extra nem um modo especial: é a propriedade de o mesmo produto funcionar para quem enxerga pouco, para quem não usa mouse e para quem não ouve o áudio.
Qual a diferença entre acessibilidade digital e inclusão digital?
Inclusão digital trata do acesso à internet e a dispositivos, um problema de infraestrutura e renda. Acessibilidade digital trata de o produto funcionar depois que a pessoa já está conectada, e é um problema de projeto, que pertence a quem constrói o produto.
O que é a WCAG?
São as Diretrizes de Acessibilidade para Conteúdo Web, publicadas pelo W3C e adotadas como referência técnica no mundo todo. A versão atual é a 2.2, de outubro de 2023. Elas se organizam em quatro princípios, perceptível, operável, compreensível e robusto, desdobrados em critérios de sucesso distribuídos em três níveis de conformidade.
Quais são os 4 princípios da WCAG?
Perceptível, que exige que a informação chegue por mais de um sentido. Operável, que exige que tudo o que funciona com mouse funcione com teclado. Compreensível, que pede linguagem clara, comportamento previsível e erros que expliquem como corrigir. E robusto, que pede código interpretável por navegadores e tecnologias assistivas diferentes. Eles funcionam em série: falhar em um bloqueia o acesso, mesmo cumprindo os outros três.
Qual nível da WCAG devo buscar: A, AA ou AAA?
AA. O nível A é o mínimo, e abaixo dele há conteúdo simplesmente inacessível para grupos inteiros. O AA é o alvo prático, adotado como referência por legislações no mundo todo, e inclui exigências como contraste mínimo de 4,5 para 1 entre texto e fundo. O AAA é o mais rigoroso, e o próprio W3C não recomenda exigi-lo para um site inteiro.
A lei brasileira obriga sites a serem acessíveis?
Sim. O artigo 63 da Lei Brasileira de Inclusão, a Lei 13.146 de 2015, torna obrigatória a acessibilidade nos sites mantidos por empresas com sede ou representação comercial no país ou por órgãos de governo, conforme as melhores práticas e diretrizes adotadas internacionalmente. Vale para empresa privada, não apenas para governo, e é essa expressão sobre diretrizes internacionais que traz a WCAG para dentro da obrigação legal.
Por onde começar a corrigir a acessibilidade de um site?
Pelas falhas mais concentradas: texto alternativo em imagem descrevendo a função e não o arquivo, contraste suficiente, rótulo associado em todo campo de formulário, HTML semântico usando button para botão e a para link, foco visível preservado no CSS, hierarquia de títulos em ordem, e legenda em vídeo. Essas correções resolvem a maior parte do que aparece em auditoria.
Ferramentas automáticas de acessibilidade são suficientes?
Não. axe DevTools, WAVE e Lighthouse encontram contraste insuficiente, imagem sem alt e campo sem rótulo em segundos, mas detectam menos da metade dos problemas reais. Elas verificam se existe um texto alternativo, não se ele descreve a imagem. Uma página pode marcar cem por cento no Lighthouse e continuar inutilizável.
Como testar acessibilidade sem ferramenta paga?
Dois testes gratuitos valem mais que qualquer relatório. Primeiro, guarde o mouse e percorra a página com Tab, Shift+Tab, Enter e Espaço: você chega a todos os controles, vê onde está o foco, consegue sair de um menu ou modal? Segundo, ligue um leitor de tela: VoiceOver no Mac e iPhone, Narrador no Windows, TalkBack no Android, ou o NVDA, que é gratuito.
Plugins e overlays de acessibilidade resolvem o problema?
Não resolvem a origem, e a comunidade técnica de acessibilidade os critica de forma consistente. Um script que roda depois do carregamento não conserta HTML mal estruturado, botão que não é botão nem fluxo que não funciona por teclado. Costumam também conflitar com a configuração de quem já usa tecnologia assistiva, e produzem falsa segurança: a empresa instala, considera o assunto resolvido e para de investir no que resolveria de fato.
