A Lei Brasileira de Inclusão da Pessoa com Deficiência — Lei 13.146/2015, conhecida como LBI ou Estatuto da Pessoa com Deficiência — estabelece que sites de empresas e de órgãos públicos devem ser acessíveis a pessoas com deficiência. Além da obrigação legal e do risco de ação civil pública, acessibilidade melhora a usabilidade para todos, ajuda o SEO e amplia o público que consegue usar o seu produto.

Este artigo explica a base legal, a referência técnica que se deve seguir, o conjunto de práticas que resolve a maior parte dos problemas e por que acessibilidade não é um item que se resolve uma vez.

A base legal

A LBI, no artigo 63, determina a obrigatoriedade de acessibilidade nos sites mantidos por empresas com sede ou representação comercial no país e por órgãos do governo, para garantia de acesso à informação. O Decreto 5.296/2004 e a norma técnica de acessibilidade da ABNT complementam. Para o setor público, o eMAG (Modelo de Acessibilidade em Governo Eletrônico) é a referência oficial.

Na prática, o descumprimento pode gerar notificação de órgãos de defesa do consumidor, ação do Ministério Público e condenação por dano moral coletivo. Já houve decisões nesse sentido contra empresas de vários setores.

A referência técnica: WCAG

A norma internacional de acessibilidade para conteúdo web é o WCAG (Web Content Accessibility Guidelines), publicado pelo W3C. A versão de referência atual é a 2.1 (com a 2.2 já disponível), organizada em três níveis: A (mínimo), AA (recomendado e adotado como alvo pela maioria das legislações) e AAA (mais rigoroso, nem sempre viável para todo o conteúdo).

O alvo realista para a maioria dos projetos é o nível AA da WCAG 2.1. Ele cobre os obstáculos que realmente impedem o uso, sem exigir o que seria impraticável em um site grande.

Os quatro princípios do WCAG

  • Perceptível — a informação precisa poder ser percebida por diferentes sentidos: texto alternativo em imagens, legendas em vídeos, contraste suficiente.
  • Operável — tudo deve funcionar pelo teclado, sem depender do mouse; o usuário deve ter tempo suficiente e não ser exposto a conteúdo que pisca.
  • Compreensível — texto legível, comportamento previsível, ajuda para evitar e corrigir erros em formulários.
  • Robusto — o código deve funcionar com tecnologias assistivas (leitores de tela) hoje e no futuro.

O que resolve a maior parte dos casos

Uma parcela grande dos problemas de acessibilidade se concentra em poucos pontos. Endereçar esta lista já coloca o site em uma situação muito melhor:

  • Texto alternativo em imagens que comunicam informação; imagens puramente decorativas devem ter alt vazio.
  • Contraste de pelo menos 4,5:1 entre texto e fundo (3:1 para texto grande).
  • Navegação por teclado completa, com indicador de foco sempre visível e ordem de tabulação lógica.
  • Estrutura de títulos coerente: um único h1, seguido de h2 e h3 encadeados sem pular níveis.
  • Formulários com rótulos associados a cada campo, instruções claras e mensagens de erro que dizem o que corrigir.
  • Links com texto descritivo — “baixar o relatório de 2025”, não “clique aqui”.
  • Legendas e transcrições em conteúdo de áudio e vídeo.
  • Landmarks e HTML semântico — usar cabeçalho, navegação, conteúdo principal e rodapé como elementos, não apenas divs.

O que não substitui um trabalho real

Existem “overlays” de acessibilidade — scripts que prometem tornar qualquer site acessível com uma linha de código, adicionando um menu flutuante de ajustes. Órgãos e especialistas de acessibilidade são amplamente críticos a essas ferramentas: elas não corrigem os problemas de fundo, às vezes atrapalham quem já usa tecnologia assistiva própria e podem dar uma falsa sensação de conformidade que não protege juridicamente.

Acessibilidade de verdade está no HTML, no CSS e no comportamento das interações — não em uma camada por cima.

Componentes interativos: onde a acessibilidade costuma quebrar

Texto e imagens são a parte mais simples. Os problemas se concentram nos componentes que o time constrói: menus suspensos, abas, acordeões, modais, carrosséis, tabelas com ordenação, campos com autocomplete. Para cada um deles, é preciso garantir:

  • Que funciona inteiramente pelo teclado, com uma ordem de foco previsível.
  • Que o estado (aberto, selecionado, expandido) é comunicado para tecnologias assistivas com os atributos corretos.
  • Que o foco é gerenciado — ao abrir um modal, o foco vai para dentro dele; ao fechar, volta para onde estava.
  • Que não há armadilhas de foco: o usuário sempre consegue sair de um componente.

Reutilizar componentes acessíveis já testados, em vez de construir cada um do zero, reduz muito o risco.

Acessibilidade e SEO andam juntas

Boa parte do que torna um site acessível também o torna mais fácil de entender para os mecanismos de busca: HTML semântico, estrutura de títulos coerente, texto alternativo em imagens, links descritivos, legendas e transcrições de vídeo. Um investimento em acessibilidade quase sempre melhora a base técnica de SEO como efeito colateral.

O contrário também vale: práticas ruins de SEO — texto escondido, títulos usados só para estilo, links vazios — costumam ser barreiras de acessibilidade.

Documento de acessibilidade e canal de contato

Além do site em si, é boa prática (e em alguns contextos, exigência) publicar uma página que declare o nível de conformidade buscado, as limitações conhecidas e um canal para que usuários reportem barreiras. Isso demonstra compromisso, ajuda na defesa em caso de questionamento e gera um retorno valioso: quem usa tecnologia assistiva encontra problemas que nenhuma auditoria pega.

Conteúdo: a responsabilidade de quem publica

Muitos problemas de acessibilidade não estão no código, e sim no conteúdo publicado no dia a dia. Uma imagem sem texto alternativo, um PDF que é só uma digitalização sem texto reconhecível, um vídeo sem legenda, um título usado só porque “fica maior”, links repetidos de “clique aqui”. Nenhuma auditoria técnica resolve isso de forma permanente se a equipe de conteúdo não incorporar o básico.

O que ajuda: campos obrigatórios de texto alternativo no upload de imagem, um guia curto de boas práticas, revisão de acessibilidade como parte do fluxo editorial e a orientação de que documentos importantes sejam publicados como páginas HTML sempre que possível, não como PDF.

PDFs e documentos

PDF é uma fonte recorrente de barreiras. Um PDF acessível precisa ter texto real (não imagem digitalizada), estrutura de títulos marcada, ordem de leitura correta, texto alternativo nas imagens e tabelas marcadas como tabelas. Criar PDFs assim dá trabalho e poucos são feitos corretamente.

A recomendação geral é preferir conteúdo em HTML — que é mais fácil de tornar acessível, responsivo e indexável — e reservar o PDF para o que realmente precisa ser um documento para download ou impressão, cuidando da acessibilidade nesses casos.

Prazo e abordagem para adequar um site existente

Adequar um site que não nasceu acessível não precisa ser um projeto único e paralisante. Uma abordagem realista:

  1. Auditoria para mapear os problemas e classificá-los por gravidade e por esforço.
  2. Correção imediata do que é crítico e barato — contraste, alt, foco visível, rótulos de formulário.
  3. Plano em ondas para o que exige mais trabalho — componentes interativos, revisão de templates.
  4. Ajuste do fluxo de conteúdo para não gerar novos problemas.
  5. Verificação automática no pipeline e auditoria manual periódica das áreas mais usadas.

O objetivo é sair de “inacessível” para “utilizável” rápido, e depois evoluir para conformidade plena de forma sustentável.

Testar: automático e manual

Ferramentas automáticas (axe, WAVE, Lighthouse) detectam cerca de um terço dos problemas — contraste, alt faltando, rótulos ausentes, alguns erros de estrutura. O restante exige teste manual:

  • Navegar o site inteiro só com o teclado, verificando se o foco está sempre visível e se nada fica inacessível.
  • Usar um leitor de tela (NVDA no Windows, VoiceOver no Mac, TalkBack no Android) nas páginas e fluxos principais.
  • Verificar a página com 200% de zoom e com o espaçamento de texto ampliado, sem perda de conteúdo ou de função.
  • Conferir se o conteúdo faz sentido sem depender de cor (para diferentes tipos de daltonismo).
  • Testar os formulários preenchendo errado de propósito, para ver se os erros são claros e localizáveis.

Acessibilidade se mantém, não se conquista

Um site pode ser auditado e ajustado para conformidade e regredir em semanas: um novo banner sem contraste, uma imagem publicada sem alt, um componente interativo novo que não funciona no teclado. Manter o padrão exige processo:

  • Checklist de acessibilidade na revisão de cada nova funcionalidade.
  • Campo de texto alternativo obrigatório no fluxo de publicação de imagens.
  • Verificação automática no pipeline, que barra regressões óbvias.
  • Treinamento da equipe de conteúdo sobre títulos, links e alt.
  • Auditoria manual periódica das áreas mais usadas.

Como a Jumps trata

A Jumps trata acessibilidade como parte do desenvolvimento em sites e portais, com o alvo de WCAG 2.1 nível AA, e mantém a verificação no ciclo de sustentação e evolução para que o padrão não se perca a cada publicação.

Se o seu site precisa de uma auditoria de acessibilidade ou de adequação à LBI, fale com a Jumps.