Problemas de acessibilidade comuns a evitar

Porque é que os mesmos problemas de acessibilidade continuam a surgir

A maioria das barreiras de acessibilidade não tem nada de exótico. Ano após ano, as auditorias automáticas e manuais revelam a mesma lista curta de erros: texto alternativo em falta, contraste insuficiente, campos de formulário sem etiqueta, armadilhas de teclado e estrutura deficiente. Repetem-se porque são introduzidas em silêncio — um programador publica um novo componente, um responsável de marketing carrega uma imagem, um designer escolhe uma cor de marca — e nada no fluxo de trabalho habitual assinala o problema. O resultado visual parece correto a quem usa um rato e uma boa visão, por isso a barreira segue para produção.

Este catálogo percorre as falhas WCAG 2.2 mais frequentes que encontramos em auditorias reais. Para cada uma, vai encontrar porque é que importa, quem afeta, o critério de sucesso aplicável e uma correção concreta antes/depois. No conjunto, estes problemas representam a esmagadora maioria das barreiras que bloqueiam pessoas com deficiência — e a esmagadora maioria das queixas jurídicas apresentadas ao abrigo do European Accessibility Act, do ADA e da Section 508.

Uma coisa a esclarecer antes da lista: as ferramentas automáticas não conseguem encontrar todos estes problemas. Investigação independente mostra de forma consistente que mesmo os melhores scanners detetam de modo fiável apenas 30 a 40 % dos problemas WCAG. São excelentes a apanhar atributos alt em falta, falhas de contraste programáticas e ausência de etiquetas de formulário, mas não conseguem avaliar se um texto alternativo é exato, se a ordem de foco é lógica, ou se um widget personalizado funciona mesmo com um leitor de ecrã. É por isso que qualquer programa credível combina a análise com uma revisão manual. O nosso software de análise de acessibilidade trata da camada automatizável; as auditorias manuais e as auditorias realizadas por pessoas com deficiência cobrem o resto.

Uma forma rápida de encontrar o seu próprio ponto de partida antes de continuar: veja a página com as imagens desativadas, leia cada palavra como um único parágrafo sem estrutura, e tente concluir cada tarefa usando apenas o teclado. Onde quer que a experiência se desmorone, encontrou uma barreira.

Percetível: conteúdo que as pessoas não conseguem ver nem ler

Texto alternativo em falta ou inexato nas imagens

Quem afeta: pessoas cegas ou com baixa visão que usam leitores de ecrã; qualquer pessoa numa ligação lenta em que as imagens não carregam.

Critério WCAG: 1.1.1 Conteúdo não textual (nível A).

As imagens sem atributo alt são invisíveis para a tecnologia de apoio — o utilizador pode nem sequer saber que a imagem existe. Pior do que um atributo em falta é um atributo inexato: nomes de ficheiro como IMG_4821.jpg, palavras genéricas como «imagem», ou cadeias cheias de palavras-chave enganam ativamente o ouvinte.

A regra é simples mas depende do contexto. As imagens informativas precisam de uma descrição concisa do seu significado, não da sua aparência. As imagens decorativas que nada acrescentam devem ter um alt="" vazio para que os leitores de ecrã as ignorem. As imagens funcionais — um ícone que funciona como botão — devem descrever a ação, não a imagem. Os elementos visuais complexos, como gráficos, precisam de um alt curto mais um equivalente textual mais longo nas proximidades.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

As ferramentas automáticas detetam instantaneamente a ausência de texto alternativo. Não lhe conseguem dizer se o texto está correto — isso exige que um humano leia a página no seu contexto.

Contraste de cor insuficiente

Quem afeta: pessoas com baixa visão, daltonismo ou perda de visão associada à idade; todas as pessoas que usam um ecrã sob luz solar intensa.

Critério WCAG: 1.4.3 Contraste (mínimo), nível AA; mais 1.4.11 Contraste de conteúdo não textual para componentes de interface.

As WCAG 2.2 exigem um rácio de contraste de pelo menos 4,5:1 para texto normal e 3:1 para texto grande (cerca de 18 pt, ou 14 pt a negrito). Os componentes de interface e os gráficos com significado — contornos de campos, indicadores de foco, ícones que transmitem um estado — devem atingir 3:1 face à sua envolvente. As falhas de contraste estão entre os problemas mais comuns encontrados em qualquer auditoria de grande escala, e são quase sempre introduzidas logo na fase de design.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Teste toda a paleta, não apenas o corpo de texto: o texto de marcador de posição (placeholder), os estados desativados que ainda têm de ser lidos, as mensagens de erro e o texto colocado sobre fotografias são infratores frequentes. Nunca dependa da cor sozinha para transmitir significado (1.4.1) — um contorno vermelho num campo inválido tem de ser acompanhado de texto ou de um ícone.

Multimédia e movimento com reprodução automática

Quem afeta: pessoas com perturbações vestibulares, perturbações de atenção ou cognitivas, utilizadores de leitores de ecrã cuja saída áudio fica abafada, e qualquer pessoa num espaço partilhado silencioso.

Critérios WCAG: 1.4.2 Controlo de áudio (nível A), 2.2.2 Pôr em pausa, parar, ocultar (nível A), 2.3.1 Três flashes (nível A), e 2.3.3 Animação a partir de interações (nível AAA).

Qualquer áudio ou vídeo que se reproduza automaticamente durante mais de três segundos tem de oferecer uma forma óbvia de o pôr em pausa ou silenciar. O conteúdo que se move, pisca ou se atualiza automaticamente durante mais de cinco segundos — carrosséis, banners animados, textos em movimento — precisa de um controlo de pausa acessível. O conteúdo que pisca mais de três vezes por segundo pode desencadear convulsões e deve ser totalmente evitado. Respeite a definição prefers-reduced-motion do utilizador para atenuar as animações não essenciais.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Operável: aquilo que as pessoas não conseguem usar

Inacessibilidade por teclado e armadilhas de teclado

Quem afeta: pessoas com deficiência motora que não conseguem usar um rato, utilizadores de leitores de ecrã (que navegam por teclado), e pessoas que usam dispositivos comutadores ou controlo por voz.

Critérios WCAG: 2.1.1 Teclado (nível A) e 2.1.2 Sem armadilha de teclado (nível A).

Cada interação — ligações, botões, campos de formulário, menus, janelas modais, seletores de data, arrastar e largar — tem de ser totalmente operável apenas com o teclado. A variante mais prejudicial é a armadilha de teclado: o foco entra num componente (muitas vezes uma janela modal ou um widget incorporado) e não consegue sair, deixando o utilizador preso na página. Os widgets personalizados são os culpados habituais, porque os elementos nativos como <button> e <a> são operáveis por teclado por predefinição, ao passo que as imitações baseadas em <div> não o são.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Percorra os seus percursos-chave usando apenas Tab, Shift+Tab, teclas de seta, Enter, Espaço e Escape. Confirme que o foco pode sempre avançar e sair de cada componente, que Escape fecha as sobreposições, e que nada exige um ponteiro. O nosso serviço de avaliação com leitor de ecrã testa exatamente estes fluxos tal como os vivem os verdadeiros utilizadores de tecnologia de apoio.

Indicadores de foco em falta ou invisíveis e ordem de foco ilógica

Quem afeta: utilizadores videntes de teclado, utilizadores com baixa visão, e qualquer pessoa que tenha perdido a noção de onde está na página.

Critérios WCAG: 2.4.7 Foco visível (nível A) e 2.4.3 Ordem de foco (nível A); 2.4.11 Foco não obscurecido (nível AA) nas WCAG 2.2.

Um erro «de arrumação» comum é remover o anel de foco predefinido do navegador com outline: none e nunca o substituir. Os utilizadores de teclado ficam sem qualquer ideia de qual o elemento ativo. Igualmente prejudicial é uma ordem de foco que não segue a ordem de leitura visual e lógica — normalmente causada por valores tabindex positivos ou por uma ordem do DOM que diverge do esquema apresentado.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

As WCAG 2.2 acrescentam o 2.4.11: quando um elemento recebe o foco, não pode ficar completamente escondido atrás de cabeçalhos fixos, banners de cookies ou widgets de chat. Abra uma janela modal, percorra-a com o teclado, e confirme que o elemento focado nunca fica soterrado.

Ligações e botões não descritivos

Quem afeta: utilizadores de leitores de ecrã que abrem uma lista de todas as ligações para percorrer uma página, e pessoas com deficiência cognitiva.

Critérios WCAG: 2.4.4 Finalidade da ligação (no contexto), nível A; 2.5.3 Etiqueta no nome, nível A.

Os utilizadores de leitores de ecrã navegam muitas vezes saltando entre ligações fora de contexto. Uma página cheia de ligações «clique aqui», «ler mais» e «saber mais» torna-se sem sentido quando lida como uma lista. O texto da ligação deve descrever o seu destino por si só. O mesmo se aplica aos botões só com ícone, que precisam de um nome acessível.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Navegação sobrecarregada e sem forma de a saltar

Quem afeta: utilizadores de leitores de ecrã, utilizadores de teclado, e pessoas com deficiência cognitiva.

Critério WCAG: 2.4.1 Ultrapassar blocos (nível A).

Um megamenu com dezenas de ligações obriga os utilizadores de leitores de ecrã e de teclado a percorrer toda a lista em cada página antes de chegar ao conteúdo. Uma ligação «Saltar para o conteúdo principal» como primeiro elemento focável permite-lhes saltar diretamente por cima dos blocos repetidos. Agrupe os itens relacionados, mantenha os menus enxutos, e assegure-se de que a ligação de salto se torna visível ao receber o foco.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Compreensível: conteúdo que confunde

Campos de formulário sem etiqueta ou incorretamente associados

Quem afeta: utilizadores de leitores de ecrã, pessoas com deficiência cognitiva, e utilizadores de controlo por voz que se dirigem aos campos pelo nome.

Critérios WCAG: 1.3.1 Informação e relações, 3.3.2 Etiquetas ou instruções, e 4.1.2 Nome, função e valor (todos de nível A).

Os campos de entrada sem uma <label> associada por programação são anunciados como «editar texto, vazio» — o utilizador não faz ideia do que escrever. O texto de marcador de posição (placeholder) não é um substituto: desaparece ao escrever e normalmente falha no contraste. Os campos obrigatórios, as regras de formatação e os erros de validação também têm de ser transmitidos por texto, e não apenas pela cor ou pela posição.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Associe as mensagens de erro ao respetivo campo com aria-describedby, marque os campos inválidos com aria-invalid, e garanta que o envio de um formulário incompleto move o foco para o primeiro erro.

Idioma da página em falta

Quem afeta: utilizadores de leitores de ecrã — o idioma errado faz com que o sintetizador pronuncie tudo mal.

Critérios WCAG: 3.1.1 Idioma da página (nível A) e 3.1.2 Idioma de partes (nível AA).

Um único atributo em falta quebra a pronúncia de uma página inteira. Declare o idioma principal no elemento raiz, e marque as passagens em linha noutro idioma com o seu próprio lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Hierarquia de cabeçalhos incorreta e marcos em falta

Quem afeta: utilizadores de leitores de ecrã que navegam por cabeçalhos e regiões, e qualquer pessoa que dependa da estrutura do documento.

Critério WCAG: 1.3.1 Informação e relações (nível A).

Os cabeçalhos são o esquema da página. Os utilizadores de leitores de ecrã saltam de cabeçalho em cabeçalho para encontrar conteúdo depressa; quando há níveis saltados, usados apenas para o tamanho do tipo de letra, ou ausentes, essa navegação desmorona-se. Cada página deve ter um único <h1> e uma sequência lógica e ininterrupta de <h2>, <h3>, e assim por diante. Igualmente importantes são as regiões de marco — <header>, <nav>, <main>, <footer> — que permitem aos utilizadores saltar entre as áreas principais. Uma página construída inteiramente com elementos <div> não oferece nenhum mapa desse tipo.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Robusto: código que a tecnologia de apoio não consegue interpretar

Widgets personalizados inacessíveis e ARIA mal utilizado

Quem afeta: sobretudo os utilizadores de leitores de ecrã, e qualquer tecnologia de apoio que dependa de uma árvore de acessibilidade correta.

Critério WCAG: 4.1.2 Nome, função e valor (nível A).

As listas pendentes, separadores, acordeões, caixas de combinação, janelas modais e dicas de ferramenta personalizados, construídos a partir de <div> e <span>, não têm qualquer função, estado ou comportamento de teclado inerente. Os programadores recorrem ao ARIA para remendar isto, mas o ARIA apenas descreve — não acrescenta comportamento, e um ARIA incorreto é pior do que nenhum. A primeira regra do ARIA é preferir um elemento HTML nativo sempre que exista um. Quando tiver mesmo de construir um widget personalizado, implemente toda a interação de teclado que os padrões de criação ARIA especificam e mantenha aria-expanded, aria-selected e estados semelhantes sincronizados com a realidade.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

São precisamente estes os problemas que os scanners automáticos mais frequentemente não detetam. Um scanner vê um atributo aria-expanded e dá-o como válido; só um humano (ou um avaliador que use um leitor de ecrã) pode confirmar que o valor muda realmente quando o menu abre. Consulte o nosso guia de teste com leitor de ecrã para saber como verificar o comportamento de um widget de ponta a ponta.

Uma nota sobre os widgets de sobreposição (overlays)

É tentador instalar um «widget de acessibilidade» de uma linha ou uma sobreposição que promete conformidade instantânea. Estas ferramentas não corrigem os problemas acima — o texto alternativo continua em falta na origem, o contraste continua a falhar, o widget personalizado continua avariado. As sobreposições não conseguem remediar o código que cria as barreiras, interferem frequentemente com a própria tecnologia de apoio dos utilizadores, e têm figurado num número crescente de processos judiciais de acessibilidade. A verdadeira acessibilidade digital vem de corrigir o HTML, o CSS e o comportamento subjacentes, e não de os mascarar.

Impeça que estes problemas voltem

Corrigir uma lista de erros uma vez é necessário mas não suficiente; os mesmos problemas reaparecem na próxima publicação, a menos que mude a forma como as coisas seguem para produção. A correção duradoura consiste em incorporar a acessibilidade no fluxo de trabalho:

Detete cedo os 30 a 40 % automatizáveis integrando as análises na sua pipeline. A integração de acessibilidade no CI/CD faz a build falhar quando é introduzida uma regressão, antes de chegar à produção.
Cubra o resto com pessoas. Agende auditorias de acessibilidade manuais e auditorias por pessoas com deficiência, que fazem emergir barreiras que nenhuma ferramenta consegue detetar.
Dê às equipas os instrumentos certos. O conjunto de ferramentas de acessibilidade QualiBooth e o Agora ajudam designers e programadores a testar enquanto trabalham.
Faça disto um processo, não um projeto. A consultoria de acessibilidade contínua e a melhoria do processo de acessibilidade enraízam os hábitos para que a qualidade se mantenha ao longo do tempo.

Para um roteiro de remediação passo a passo, comece pelo nosso guia sobre como tornar o seu site conforme às WCAG.

Por onde começar hoje

Com mais de 1,3 mil milhões de pessoas em todo o mundo a viver com alguma forma de deficiência, o argumento de negócio a favor da acessibilidade é claro — e, desde junho de 2025, o argumento jurídico ao abrigo do European Accessibility Act também o é. Os problemas deste catálogo são os primeiros a ser examinados em qualquer queixa ou auditoria.

A forma mais rápida de saber onde está é executar uma análise de URL gratuita — sem configuração, sem compromisso. Quando estiver pronto para ir além do que a automatização consegue alcançar, solicite uma demonstração e mostrar-lhe-emos como um programa que combina o automático com o manual fecha a lacuna restante.