Lista de verificação de acessibilidade web para PME e lojas online

Imagine uma cliente que usa um leitor de ecrã. Encontra as sapatilhas que quer, escolhe o tamanho e carrega no que pensa ser o botão do carrinho. O leitor de ecrã diz «botão». Mais nada. Há três assim na página e nenhum tem nome, por isso ela desiste, e a loja nunca chega a saber porquê.

A maioria dos problemas de acessibilidade nos sites de pequenas empresas é assim: invisível para o dono, um beco sem saída para o cliente. Esta lista é para quem gere um site em Shopify, WooCommerce, Wix ou Squarespace sem um programador na equipa.

O site da minha pequena empresa tem de ser acessível?

Se vende a consumidores na UE, provavelmente sim. O Ato Europeu da Acessibilidade (abre num novo separador) abrange os serviços de comércio eletrónico desde 28 de junho de 2025. A principal isenção é para as microempresas que prestam serviços: empresas com menos de 10 trabalhadores e um volume de negócios anual ou balanço total anual que não excede 2 milhões de euros.

Comércio eletrónico significa aqui vender à distância, através de um site ou de uma app, «mediante pedido individual de um consumidor tendo em vista a celebração de um contrato de consumo» (artigo 3.º, ponto 30). Uma loja online ou um motor de reservas encaixam. A isenção abrange apenas serviços: quem vende produtos abrangidos, como leitores de livros eletrónicos, continua sujeito às regras para produtos (artigo 4.º, n.º 5). Estar fora da UE também não ajuda, porque uma loja britânica que vende a clientes em França está abrangida em relação a eles (artigo 3.º, ponto 4). O nosso guia sobre o Ato Europeu da Acessibilidade trata das leis nacionais e das sanções.

No Reino Unido, a Equality Act 2010 (abre num novo separador) exige adaptações razoáveis para pessoas com deficiência, mas não fixa uma norma técnica para sites. Nos EUA, as orientações de março de 2022 (abre num novo separador) do Departamento de Justiça dizem que as empresas abertas ao público têm de tornar acessível o que oferecem online e que normas como as WCAG «fornecem orientações úteis». Diga a lei o que disser, um cliente que não consegue concluir o checkout não compra.

Quais são os problemas de acessibilidade mais comuns nos sites?

Seis falhas dominam. No WebAIM Million 2026 (abre num novo separador), uma análise automática das páginas iniciais do milhão de sites mais visitados feita em fevereiro de 2026, 95,9% das páginas tinham falhas WCAG detetadas, com uma média de 56,1 erros por página. O texto com pouco contraste foi o problema mais comum, presente em 83,9% das páginas iniciais.

As WCAG, as Diretrizes de Acessibilidade para o Conteúdo da Web, são a norma por trás destas verificações; a maioria das leis remete para o seu nível AA, e o nosso guia das WCAG 2.2 explica a versão mais recente. Várias verificações abaixo são coisas que nenhum analisador automático consegue avaliar.

Toda a gente consegue ler os seus textos e perceber as suas imagens?

Comece por aqui, porque estas correções são baratas e quase todas pode fazê-las no editor do site. O texto precisa de contraste suficiente, as imagens que transmitem informação precisam de texto alternativo e nada deve depender só da cor. Cerca de 1 em cada 12 homens e 1 em cada 200 mulheres têm uma deficiência na visão das cores, segundo a Colour Blind Awareness (abre num novo separador).

• Contraste. O texto normal precisa de uma relação de contraste de pelo menos 4,5:1 (abre num novo separador) com o fundo, e o texto grande de pelo menos 3:1. Teste as suas cores, incluindo o texto sobre fotografias de banners, num verificador gratuito. O nosso guia sobre contraste de cores mostra correções que preservam a sua marca.
• Texto alternativo dos produtos. Descreva o que quem compra precisa de saber: «Camisola de lã azul-marinho com gola alta canelada, vista de frente» é melhor do que «imagem de produto 1». Comece pelos dez produtos mais vendidos.
• Imagens decorativas. Um ornamento de fundo deve ter o texto alternativo vazio, para que os leitores de ecrã o ignorem. Algumas plataformas preenchem um alt vazio com o nome do ficheiro, por isso verifique a sua.
• Só a cor. «Esgotado» indicado apenas com uma amostra de cor acinzentada, ou um campo obrigatório assinalado só a vermelho, não chega a toda a gente. Veja a página com o filtro de tons de cinzento do telemóvel e acrescente uma palavra ou um ícone onde o significado se perder.
• Zoom. Com o zoom do navegador a 200%, o texto deve aumentar sem se sobrepor nem ficar cortado, e o menu deve continuar a funcionar.
• Idioma da página. Qualquer verificador gratuito assinala a falta da declaração de idioma. É uma definição do tema ou uma alteração de uma linha no modelo.

É possível usar o seu site com o teclado?

Muitas pessoas navegam sem rato: utilizadores de leitores de ecrã, pessoas com tremores ou movimentos limitados das mãos e qualquer pessoa cujo trackpad acabou de avariar. Ponha o rato de lado e prima Tab. Deve conseguir chegar a cada ligação, botão e campo de formulário numa ordem lógica, ver sempre onde está e nunca ficar preso.

• Foco visível. Um contorno deve mostrar qual é o elemento ativo, e um cabeçalho fixo ou uma bolha de chat não o devem tapar (critério 2.4.11 Foco não obscurecido das WCAG 2.2). Muitos temas retiram o contorno por razões estéticas; um programador pode repô-lo.
• Sem armadilhas. Abra com o teclado o menu, o seletor de tamanho, as janelas pop-up e a galeria de imagens, escolha algo e tente sair. A tecla Escape deve fechar as janelas pop-up.
• Nomes para os ícones. Cada ligação e botão com ícone precisa de um nome que o leitor de ecrã consiga anunciar, como «Carrinho, 2 artigos». Substitua «Clique aqui» por palavras que digam para onde a ligação leva.
• Ligação para saltar e títulos. O ideal é que a primeira vez que se prime Tab apareça uma ligação «Saltar para o conteúdo». No inquérito da WebAIM de 2024 a utilizadores de leitores de ecrã (abre num novo separador), 71,6% disseram que percorrem primeiro uma página longa pelos títulos, por isso use níveis de título verdadeiros e não texto a negrito.
• Alvos de toque. As WCAG 2.2 pedem alvos com pelo menos 24 por 24 píxeis CSS, ou espaço suficiente à volta (critério de sucesso 2.5.8 (abre num novo separador)).

Toda a gente consegue concluir os formulários, o carrinho e o checkout?

É no checkout que os problemas de acessibilidade lhe custam dinheiro diretamente, por isso teste-o do princípio ao fim, incluindo o que acontece quando algo corre mal. Cada campo precisa de uma etiqueta visível, os erros têm de explicar o problema por palavras e iniciar sessão não deve depender de testes de memória nem de quebra-cabeças. As páginas do seu fornecedor de pagamentos também contam.

• Etiquetas, não texto de exemplo. O texto de exemplo (placeholder) desaparece mal se começa a escrever e é muitas vezes demasiado claro para se ler. Cada campo precisa de uma etiqueta que fique visível.
• Mensagens de erro. Submeta o formulário vazio. Cada erro deve estar escrito («Introduza um código postal, por exemplo 1000-001»), junto ao respetivo campo e ser anunciado, em vez de apenas pôr o contorno do campo a vermelho.
• Não pergunte duas vezes. Ofereça «A morada de faturação é a mesma» em vez de obrigar a escrever de novo a morada de entrega. As WCAG 2.2 tornaram isto um requisito de nível A, o 3.3.7 Entrada redundante.
• Início de sessão. Deixe colar palavras-passe e códigos de utilização única e usar gestores de palavras-passe. Bloquear a função colar falha o critério de autenticação acessível (abre num novo separador) das WCAG 2.2, a não ser que ofereça outra forma de entrar.
• CAPTCHA. No inquérito da WebAIM de 2024, os utilizadores de leitores de ecrã classificaram o CAPTCHA como o elemento mais problemático da web. Se precisa de proteção contra bots, evite quebra-cabeças visuais e ofereça sempre uma alternativa não visual.
• Limites de tempo. Se um carrinho ou uma reserva expirar, avise as pessoas e deixe-as prolongar o prazo.

Se partes do checkout pertencem à sua plataforma ou ao fornecedor de pagamentos, teste-as na mesma, comunique os problemas e indique-os como problemas conhecidos.

E as faixas de cookies, as janelas pop-up e os widgets de chat?

Para os seus clientes, os scripts de terceiros fazem parte do seu site. Uma faixa de cookies que não se fecha com o teclado bloqueia todas as páginas, e uma janela pop-up da newsletter que rouba o foco a meio do checkout pode fazer-lhe perder uma venda. Teste cada script que acrescentou e pergunte aos fornecedores pela acessibilidade antes de instalar um novo.

• Faixa de cookies. Consegue chegar aos botões de aceitar e rejeitar com Tab, lê-los com zoom a 200% e continuar depois onde estava?
• Janelas pop-up. O foco deve entrar na janela, ficar lá até ela fechar e depois voltar. A tecla Escape deve fechá-la.
• Widgets de chat. O botão precisa de um nome, a janela deve abrir e fechar com o teclado e, no telemóvel, não deve ficar por cima de «Pagar agora».
• Carrosséis. Tudo o que se move sozinho durante mais de cinco segundos precisa de uma forma de pausar, parar ou ocultar (WCAG 2.2 (abre num novo separador), critério de sucesso 2.2.2).
• Conteúdos incorporados. Widgets de avaliações, mapas e ferramentas de reserva também estão na sua página. Comunique as falhas ao fornecedor.

Os seus vídeos, PDF e menus funcionam para toda a gente?

Os vídeos precisam de legendas, o áudio precisa de uma transcrição e a informação importante não deve existir só num PDF ou numa imagem. Um restaurante cujo menu é um PDF digitalizado, ou uma loja cuja tabela de tamanhos é a fotografia de uma tabela, exclui os utilizadores de leitores de ecrã e quem precisa de ampliar no telemóvel.

• Legendas e transcrições. Corrija as legendas automáticas antes de publicar. Os podcasts precisam de uma versão em texto.
• Imagens de texto. Ponha os menus, as tabelas de preços, as tabelas de tamanhos e os horários numa página web normal. Se tiver mesmo de usar um PDF, exporte-o com títulos e etiquetas a partir do processador de texto em vez de digitalizar uma impressão.
• Ficheiros antigos. O EAA não o obriga a corrigir documentos de escritório nem áudio e vídeo pré-gravados publicados antes de 28 de junho de 2025, nem conteúdos arquivados que já não atualiza (artigo 2.º, n.º 4). Os ficheiros novos estão abrangidos.

O que posso corrigir sozinho e quando preciso de um programador ou de uma auditoria?

Pode corrigir sozinho a maioria dos problemas de conteúdo no CMS: texto alternativo, títulos, texto das ligações, cores, legendas e muitas etiquetas de formulário. Os problemas do tema, como a falta de estilos de foco, as armadilhas de teclado e as listas pendentes personalizadas, precisam de um programador. Uma auditoria faz mais sentido quando o básico já está corrigido, ou antes de lançar uma remodelação.

Qual é o papel de um widget como o nosso? Um painel para visitantes como a SiteAccessible permite aumentar o contraste, ampliar o texto ou ativar um guia de leitura. Isso ajuda alguns visitantes, mas não risca nada desta lista: um botão sem nome continua sem nome e uma armadilha de teclado continua a ser uma armadilha. Corrija primeiro o site e trate o widget como um extra.

Como registo o que fiz?

Mantenha um registo simples do que testou, quando, o que corrigiu e o que ainda não funciona, e publique um resumo honesto numa declaração de acessibilidade. Se o EAA se aplicar a si, tem também de publicar informação sobre a forma como o seu serviço cumpre os requisitos de acessibilidade, normalmente nos termos e condições gerais ou num documento equivalente.

Essa segunda obrigação vem do anexo V da diretiva; a lei nacional define o formato. O nosso guia para redigir uma declaração de acessibilidade inclui um modelo que pode adaptar. Depois, mantenha a rotina:

1. Aplique a lista às três páginas principais e faça uma captura de ecrã de cada falha.
2. Corrija sozinho os pontos de conteúdo esta semana.
3. Passe a um programador os pontos do tema e do checkout, começando pelos piores.
4. Volte a testar cada correção com o teclado, e não só com um verificador.
5. Publique ou atualize a sua declaração, com a data.
6. Repita sempre que acrescentar uma app, mudar de tema ou lançar uma nova página de destino.