Mais de 94% dos sites de e-commerce apresentam falhas mensuráveis de acessibilidade segundo as WCAG, embora a comunidade de pessoas com deficiência represente um mercado global de US$ 13 trilhões. Este guia oferece a proprietários de sites, desenvolvedores e gestores de conformidade um roteiro concreto e acionável para adequar suas lojas online às WCAG 2.2 — desde as páginas de produto até o checkout.
Por que a acessibilidade em e-commerce deixou de ser opcional
As implicações legais e financeiras em torno da acessibilidade na web nunca foram tão altas, e o e-commerce está bem no centro do alvo. Só em 2024, 4.605 processos judiciais relacionados a sites sob a ADA foram abertos em tribunais federais dos EUA, com o setor de e-commerce arcando com a maior parte — respondendo por aproximadamente 68–77% de todas as ações, dependendo da fonte de relatório. A tendência está se acelerando: a primeira metade de 2025 registrou 2.014 processos de acessibilidade digital, um aumento de 37% em relação ao mesmo período em 2024, colocando o setor no ritmo de ultrapassar 4.975 processos até o fim do ano.
Os acordos também não são triviais. As resoluções típicas variam de $25,000 a $75,000, além dos honorários advocatícios de ambos os lados e do custo do trabalho de correção que você deveria ter feito desde o início. Mais preocupante: em 2024, quase metade de todos os casos foi movida contra empresas que já tinham sido processadas antes e não haviam corrigido seus sites de forma abrangente. Resolver uma vez não protege você do próximo processo se o código subjacente continuar quebrado.
O cenário regulatório também está se tornando mais rígido globalmente. O European Accessibility Act (EAA) passou a ser aplicável em 28 de junho de 2025 e abrange plataformas de e-commerce que vendem para mercados da UE — com penalidades que podem chegar a €100,000 ou 4% da receita anual em alguns Estados-membros. Nos Estados Unidos, o Department of Justice publicou, em abril de 2024, uma regra final que formalmente exige WCAG 2.1 Nível AA para sites de governos estaduais e locais e, embora empresas privadas ainda não enfrentem um padrão técnico federal vinculante, os tribunais e o próprio DOJ usam consistentemente a WCAG como referência de fato ao avaliar ações com base na ADA. O impulso é inconfundível: esperar por regulamentações mais claras é uma estratégia de alto risco.
Além do risco legal, há um mercado enorme e pouco atendido em jogo. Pessoas com deficiência e suas famílias respondem por um estimado $13 trilhões em atividade econômica global, e apenas a renda disponível da comunidade global de pessoas com deficiência é estimada em $1.9 trilhão anuais. Marcas que priorizam acessibilidade também veem benefícios mensuráveis em lealdade — um estudo encontrou uma taxa de retenção de clientes 18% maior entre consumidores com deficiência que se sentiram bem atendidos. Acessibilidade não é caridade. É bom negócio.
Entendendo a WCAG: o padrão que realmente importa
As Web Content Accessibility Guidelines (WCAG), desenvolvidas pelo World Wide Web Consortium (W3C), são a estrutura técnica de acessibilidade digital reconhecida internacionalmente. Elas são organizadas em torno de quatro princípios centrais — conhecidos pelo acrônimo POUR: o conteúdo deve ser Perceivable (Perceptível), Operable (Operável), Understandable (Compreensível) e Robust (Robusto). Cada princípio se desdobra em critérios de sucesso específicos e testáveis.
A versão atual, WCAG 2.2, foi publicada em outubro de 2023 e adiciona nove novos critérios de sucesso à versão anterior, permanecendo totalmente compatível com versões anteriores. Atender à WCAG 2.2 significa automaticamente que você satisfaz a WCAG 2.1 e 2.0. Para a maioria das empresas de e-commerce, o alvo deve ser a conformidade em Nível AA — é o padrão mencionado em praticamente todas as estruturas regulatórias, aquele ao qual os tribunais recorrem em litígios sob a ADA e o nível que atende de forma significativa à maior variedade de usuários. O Nível A é o mínimo indispensável, e o Nível AAA, embora admirável, não é praticamente alcançável para a maioria dos sites transacionais complexos.
Os nove novos critérios da WCAG 2.2 adicionaram vários requisitos com implicações diretas e de alto impacto para o varejo online: tamanhos mínimos de alvos de toque (2.5.8), indicadores de foco que não são encobertos por cabeçalhos fixos (2.4.11), prevenção de entradas redundantes em fluxos de checkout em múltiplas etapas (3.3.7), autenticação acessível que não depende de quebra-cabeças cognitivos como CAPTCHAs complexos (3.3.8) e posicionamento consistente de mecanismos de ajuda em todas as páginas (3.2.6). Essas não são diretrizes abstratas — elas se relacionam diretamente com os pontos de fricção que fazem seus clientes abandonarem carrinhos.
As falhas de acessibilidade mais comuns em sites de e-commerce
Pesquisas revelam consistentemente que sites de e-commerce falham em um conjunto previsível de questões. Entender esses padrões de falha é o primeiro passo para priorizar o seu trabalho de correção. De acordo com o relatório WebAIM Million 2026, texto com baixo contraste continua sendo o problema mais disseminado, agora encontrado em 83.9% das home pages — acima dos 79.1% do ano anterior. A home page média agora contém 34 instâncias distintas de texto com baixo contraste. Isso significa que o seu banner de promoção, os rótulos dos seus botões, as suas etiquetas de preço — há uma boa chance de que uma parte significativa dos seus clientes com baixa visão simplesmente não consiga lê-los.
Além do contraste, o Baymard Institute descobriu que, entre 33 sites de e-commerce de maior faturamento avaliados em relação à WCAG 2.1 AA: 82% tinham problemas de acessibilidade com imagens de produtos, 73% tinham problemas com links, 64% tinham problemas com navegação por teclado e 58% tinham problemas com marcação de campos de formulário. Esses não são casos extremos — são componentes fundamentais da jornada de usuário de qualquer loja online, da navegação à compra.
Aqui estão as categorias de falha que aparecem com mais frequência tanto em auditorias quanto em ações judiciais sob a ADA direcionadas a lojas online:
- Texto alternativo ausente ou de baixa qualidade em imagens de produtos: Leitores de tela anunciam o nome do arquivo da imagem ou a ignoram completamente quando o texto alternativo está ausente. Um bom texto alternativo descreve o que a imagem realmente mostra — não apenas "imagem do produto", mas algo como "Suéter azul-marinho de lã merino, gola careca, disposto plano sobre fundo branco".
- Rótulos de formulário e mensagens de erro inacessíveis: Cada campo de entrada no seu checkout deve ter um elemento
<label>associado de forma programática. Mensagens de erro que aparecem apenas como texto em vermelho — sem descrição textual — são invisíveis para usuários de leitores de tela e violam critérios de uso de cor. - Armadilhas de teclado em modais e gavetas: Sobreposições de carrinho, seletores de tamanho e modais de cupom que interceptam o foco do teclado, mas não permitem que o usuário saia com a tecla
Escape, são uma barreira comum e séria. Um usuário que não consegue sair do modal não consegue concluir a compra. - Elementos interativos inacessíveis por teclado: Carrosséis, dropdowns personalizados, controles de quantidade e controles de zoom de imagem construídos sem papéis ARIA e manipuladores de eventos de teclado simplesmente não existem para usuários que dependem apenas do teclado.
- Atualizações dinâmicas do carrinho não anunciadas para tecnologias assistivas: Quando um usuário adiciona um item ao carrinho e a contagem do carrinho muda via JavaScript sem recarregar a página, leitores de tela não percebem a mudança a menos que você a anuncie explicitamente usando uma região ARIA live.
- Tamanhos insuficientes de alvos de toque: A WCAG 2.2 exige que elementos interativos tenham pelo menos 24×24 pixels CSS. Ícones pequenos de "Adicionar à lista de desejos", botões de fechar em modais e amostras de cores de variantes rotineiramente falham nisso no mobile.
- Indicadores de foco ocultos por cabeçalhos fixos ou conteúdo sobreposto: Quando um usuário navega com a tecla Tab até um link ou botão e o anel de foco fica escondido sob uma barra de navegação persistente ou um banner de cookies, ele não consegue saber onde está na página.
Uma regra prática útil: se você não consegue completar todo o fluxo de compra — da landing page à confirmação do pedido — usando apenas o teclado e sem mouse, o seu checkout não é acessível.
Um roteiro de acessibilidade página a página para a sua loja
A acessibilidade em e-commerce não é um único problema — é um conjunto de problemas específicos e dependentes de contexto que variam por tipo de página. A abordagem de correção mais eficaz percorre a jornada do cliente de forma sistemática, começando pelas áreas de maior impacto.
Páginas de listagem de produtos (PLPs): Garanta que os controles de filtro — checkboxes, sliders, dropdowns — sejam operáveis por teclado e tenham estados de foco visíveis. Se os filtros atualizam os resultados dinamicamente, envolva a região de resultados em uma região aria-live para que leitores de tela anunciem que a lista de produtos mudou. Cada link de card de produto deve ter texto descritivo (não apenas "Ver" ou "Saiba mais") e as imagens de produtos precisam de texto alternativo significativo.
Páginas de detalhes de produto (PDPs): Seletores de variantes (tamanho, cor, material) são um ponto de falha notório. Botões de opção com estilo personalizado ou botões usados como interruptores precisam de papéis e estados ARIA adequados. Se você usa uma tabela de medidas em um modal, esse modal deve gerenciar o foco corretamente — prendendo-o dentro da caixa de diálogo quando aberta e devolvendo-o ao elemento acionador quando fechada. Vídeos de produtos devem ter legendas; descrições em áudio são necessárias quando informações visuais significativas são transmitidas sem narração.
Carrinho de compras e mini-carrinho: Quando um usuário adiciona um item ao carrinho, a confirmação deve ser anunciada a leitores de tela por meio de uma região aria-live com role='status' ou role='alert'. Controles de quantidade devem ser operáveis por teclado, e o botão "Remover item" deve ter um nome acessível exclusivo e descritivo para cada item de linha — não apenas "Remover" repetido quatro vezes para quatro produtos diferentes.
Fluxo de checkout: É aqui que vivem as violações de WCAG de maior impacto e de onde se originam os processos mais caros. Sob o modelo de conformidade da WCAG, cada página em um processo deve estar em conformidade — você não pode ter uma página de produto acessível e uma tela de pagamento inacessível e alegar conformidade. Requisitos-chave incluem: todos os campos de formulário devem ter rótulos visíveis persistentes (não apenas texto placeholder, que desaparece quando o usuário começa a digitar), mensagens de erro devem identificar o campo específico e descrever em texto o que deu errado, atributos de preenchimento automático (autocomplete='email', autocomplete='cc-number', etc.) devem estar presentes para ajudar usuários com deficiências cognitivas e motoras, e todo o fluxo deve ser completável sem mouse. A WCAG 2.2 também proíbe exigir que usuários insiram novamente informações que já forneceram na mesma sessão — portanto, se o seu checkout pede endereço de cobrança depois de o cliente ter acabado de inserir o endereço de entrega, essas informações devem poder ser preenchidas automaticamente.
Login e registro de conta: O critério de Autenticação Acessível (3.3.8) da WCAG 2.2 significa que você não pode exigir que usuários resolvam um teste de função cognitiva — como um CAPTCHA de imagem padrão — como único método de autenticação. Ofereça alternativas como links mágicos por e-mail, códigos por SMS ou OAuth de terceiros. Se você usar CAPTCHA, uma alternativa em áudio é o mínimo, mas defensores da acessibilidade cognitiva recomendam abandonar o CAPTCHA completamente em favor de métodos menos onerosos.
Implementação em nível de código: como é um e-commerce acessível na prática
A acessibilidade é, em última análise, um problema de código, e orientações abstratas só vão até certo ponto. Veja como é a implementação correta para alguns dos padrões de e-commerce mais comuns.
Para um link de pular navegação (essencial para usuários de teclado que não querem percorrer todo o cabeçalho em cada página):
<a href='#main-content' class='skip-link'>Skip to main content</a>
<style>
.skip-link {
position: absolute;
top: -40px;
left: 0;
background: #000;
color: #fff;
padding: 8px 16px;
z-index: 9999;
text-decoration: none;
}
.skip-link:focus {
top: 0;
}
</style>
<main id='main-content' tabindex='-1'>
<!-- your page content -->
</main>Para um anúncio de atualização de carrinho que leitores de tela captarão automaticamente quando um item for adicionado:
<!-- Place this in your page HTML -->
<div
role='status'
aria-live='polite'
aria-atomic='true'
class='visually-hidden'
id='cart-announcement'
></div>
<!-- Then in your JavaScript, after a cart update: -->
<script>
function announceCartUpdate(message) {
const region = document.getElementById('cart-announcement');
region.textContent = '';
// Force the browser to register the DOM change before updating
requestAnimationFrame(() => {
region.textContent = message;
});
}
// Example usage:
announceCartUpdate('Blue Linen Shirt added to cart. Cart now contains 3 items.');
</script>Para um indicador de foco compatível com a WCAG 2.2 que atende aos requisitos de contraste e tamanho:
<style>
/* Remove browser default and replace with a strong custom indicator */
:focus-visible {
outline: 3px solid #0057b8;
outline-offset: 3px;
border-radius: 2px;
}
/* Ensure sticky header doesn't obscure focused elements (WCAG 2.4.11) */
:focus {
scroll-margin-top: 80px; /* match your header height */
}
</style>Para rótulos de formulário corretamente associados e mensagens de erro inline no checkout:
<div class='form-field'>
<label for='email'>Email address <span aria-hidden='true'>*</span></label>
<input
type='email'
id='email'
name='email'
autocomplete='email'
aria-required='true'
aria-describedby='email-error'
/>
<span
id='email-error'
role='alert'
class='error-message'
><!-- Populated by JS on validation failure --></span>
</div>Testes: ferramentas automatizadas são um ponto de partida, não a linha de chegada
Um dos equívocos mais perigosos em conformidade de acessibilidade é a ideia de que scanners automatizados podem dizer se o seu site é acessível. Eles não podem. Ferramentas automatizadas conseguem detectar aproximadamente 30–40% dos problemas de WCAG — questões como atributos alt ausentes, falhas óbvias de contraste e rótulos de formulário ausentes. Os 60–70% restantes exigem julgamento humano: este texto alternativo realmente descreve a imagem de forma significativa? A ordem de leitura é lógica quando navegada por leitor de tela? A mensagem de erro é realmente útil ou apenas diz "entrada inválida"?
Uma estratégia de testes realista para uma loja de e-commerce usa múltiplas camadas. Comece com um scanner automatizado — ferramentas como axe-core, WAVE ou Lighthouse — executado em cada template de página (PLP, PDP, carrinho, checkout, conta). Isso traz à tona rapidamente os problemas mais óbvios. Em seguida, faça uma sessão usando apenas o teclado: desconecte o mouse e tente completar uma compra completa. Percorra tudo com Tab. Tente abrir e fechar modais. Tente atualizar a quantidade no carrinho. Tente aplicar um código de cupom. Se você ficar preso em qualquer ponto, isso é uma falha.
Depois, teste com pelo menos um leitor de tela. NVDA com Firefox e VoiceOver com Safari são as combinações mais representativas para a maioria dos públicos. Ouça como a sua página de produto é anunciada. O leitor de tela transmite todas as informações que um usuário vidente teria? O fluxo de checkout faz sentido quando lido de forma linear? Por fim, e mais importante, teste com usuários reais com deficiência. Ferramentas automatizadas e testes feitos por desenvolvedores sempre deixarão passar coisas que usuários reais encontram por causa da forma específica como interagem com tecnologias assistivas.
Para conformidade contínua, verificações de acessibilidade devem ser integradas ao seu pipeline de CI/CD para que novas implantações de código sejam automaticamente analisadas antes de entrarem em produção. Sites de e-commerce mudam constantemente — novas promoções, novas categorias de produtos, novas etapas de checkout — e cada mudança é uma oportunidade de introduzir novas barreiras. Acessibilidade é um processo, não um projeto pontual.
A questão dos widgets de overlay: o que você precisa saber
Se você tem pesquisado soluções de acessibilidade, quase certamente encontrou widgets de overlay — ferramentas em JavaScript que prometem tornar seu site compatível adicionando uma camada de correções automatizadas sobre o código existente. Alguns produtos vendem isso como uma solução de uma linha só. A realidade é mais complicada, e o perfil de risco é significativo.
Em 2024, mais de 1.000 empresas foram processadas apesar de terem widgets de acessibilidade instalados em seus sites, respondendo por mais de 25% de todos os casos sob a ADA naquele ano. A razão é simples: overlays adicionam uma camada de JavaScript sobre um HTML quebrado, mas leitores de tela encontram as barreiras de acessibilidade subjacentes antes que os scripts de overlay possam intervir — se é que intervêm. Widgets de overlay também podem introduzir seus próprios problemas de acessibilidade, incluindo caixas de diálogo modais que prendem o foco e recursos que entram em conflito com as configurações da própria tecnologia assistiva do usuário.
Em janeiro de 2025, a Federal Trade Commission obrigou a AccessiBe — um dos provedores de overlay mais amplamente divulgados — a pagar $1 milhão para encerrar alegações de que havia deturpado a capacidade de seu produto de tornar sites compatíveis com a WCAG. Nenhum tribunal aceitou um widget de overlay como evidência de conformidade com a ADA.
Isso não significa que todas as ferramentas de acessibilidade do lado do cliente sejam inúteis. Um SDK de acessibilidade bem construído — que complemente uma correção genuína em nível de código em vez de substituí-la — pode oferecer valor real: disponibilizar para usuários um painel de preferências onde possam ajustar contraste, tamanho de fonte ou configurações de movimento; fornecer uma declaração de acessibilidade com um canal claro de feedback; e viabilizar correções em áreas onde o acesso completo ao código é limitado (como certos widgets de terceiros). A distinção é enorme: uma ferramenta que auxilia usuários e complementa uma correção adequada é categoricamente diferente de uma que afirma substituí-la. Soluções como Accsible são projetadas com essa filosofia — fornecendo um SDK que melhora a experiência de usuários que precisam de adaptações, deixando claro que a conformidade real é construída no código.
Construindo um programa de acessibilidade, não apenas corrigindo bugs
O caminho mais resiliente para a conformidade com a WCAG — e o menos propenso a resultar em processos repetidos — é tratar a acessibilidade como uma prática organizacional contínua, e não como um projeto técnico pontual. Corrigir sem melhorar o processo é como tirar água de um barco com vazamento sem consertar o buraco.
Comece publicando uma Declaração de Acessibilidade no seu site. Essa página deve descrever o padrão que você está buscando (WCAG 2.2 Nível AA), as limitações conhecidas da sua implementação atual, como usuários podem relatar barreiras de acessibilidade e com que rapidez você responderá. Isso sinaliza boa-fé, oferece aos usuários um caminho para buscar ajuda e é explicitamente exigido pela legislação da UE. Combine isso com um mecanismo genuíno de feedback — um endereço de e-mail ou formulário que realmente chegue a alguém com autoridade para corrigir problemas.
Treine toda a sua equipe, não apenas desenvolvedores. Designers que entendem razões de contraste e requisitos de estados de foco produzirão mockups acessíveis. Criadores de conteúdo que sabem escrever texto alternativo eficaz deixarão de deixar campos em branco. Product managers que entendem a WCAG vão questionar quando um recurso proposto não tiver caminho por teclado. Conhecimento de acessibilidade distribuído pela equipe é muito mais durável do que um único especialista em acessibilidade tentando pegar tudo no final.
Por fim, documente suas descobertas de auditoria, as correções aplicadas e os resultados dos testes. Isso cria uma trilha de auditoria valiosa tanto internamente — para acompanhar o progresso — quanto externamente, como evidência de esforços de conformidade de boa-fé se você enfrentar um desafio legal. Um em cada quatro processos em 2024 envolveu réus reincidentes que haviam sido processados e fizeram acordo sem realmente corrigir o problema. Um programa de correção documentado e abrangente é sua melhor defesa contra esse resultado.
Principais pontos
- O e-commerce é o principal alvo de litígios de acessibilidade. Respondendo por aproximadamente 70% de todos os processos de acessibilidade digital sob a ADA, lojas online enfrentam o maior risco no cenário digital. Acordos rotineiramente ficam entre $25,000–$75,000 mais custos de correção, e um acordo anterior não protege você de ações subsequentes se as barreiras permanecerem.
- Tenha como alvo a WCAG 2.2 Nível AA — ela cobre 2.1 e 2.0 automaticamente. A WCAG 2.2 é compatível com versões anteriores, então mirar no padrão mais recente oferece a cobertura legal mais ampla em tribunais dos EUA, no European Accessibility Act da UE e na maioria das outras jurisdições ao redor do mundo.
- Corrija primeiro o funil de compra. O fluxo de checkout — do carrinho à confirmação do pedido — é onde vivem as barreiras de maior risco e onde usuários com deficiência têm mais probabilidade de abandonar. Priorize acessibilidade por teclado, rótulos de formulário, tratamento de erros e anúncios de conteúdo dinâmico em cada etapa do checkout.
- Ferramentas automatizadas capturam apenas 30–40% dos problemas de WCAG. Complete a varredura automatizada com testes usando apenas teclado, testes com leitores de tela e sessões com usuários reais. Integre verificações de acessibilidade ao seu pipeline de CI/CD para que novo código não introduza regressões.
- Acessibilidade é um programa, não um remendo. Treine seus designers, desenvolvedores e equipe de conteúdo. Publique uma Declaração de Acessibilidade com um canal real de feedback. Documente o seu trabalho de correção. Incorpore acessibilidade ao seu processo de desenvolvimento para que as correções se mantenham à medida que sua loja evolui.