O chamado de suporte ao cliente foi desconcertante no início. "Não consigo usar seus emails." O usuário explicou que era cego e usava um leitor de tela. Os emails lindamente desenhados da empresa eram uma parede de "imagem imagem imagem link link link"—sem texto alternativo, sem estrutura semântica, nenhuma forma de entender o conteúdo.
A acessibilidade em emails não é opcional. Além do imperativo ético de incluir todos, há exigências legais em muitas jurisdições. E, na prática, emails acessíveis são emails melhores—estrutura mais clara, melhor experiência em dispositivos móveis e renderização mais confiável.
Esta checklist abrange as considerações técnicas e de design que fazem os emails funcionarem para todos.
Imagens e mídia
Todas as imagens têm texto alternativo. Toda tag <img> precisa de um atributo alt. Descreva o que a imagem mostra, não apenas que é uma imagem. "Foto do produto: tênis de corrida azuis" é útil. "Imagem" não é.
Imagens decorativas têm alt vazio. Imagens que não transmitem informação (espaçadores, bordas decorativas) devem ter alt="" para que leitores de tela as ignorem. Não omita o atributo alt por completo—isso faz leitores de tela lerem o nome do arquivo.
O texto alternativo é conciso, mas completo. Mire em menos de 125 caracteres. Descreva a informação essencial. Para imagens complexas, como gráficos, forneça um resumo em texto próximo.
Imagens não são a única forma de transmitir informação. Se uma imagem contém texto, esse texto também deve aparecer como texto real. Se um gráfico mostra dados, resuma as principais conclusões em texto.
GIFs animados são usados com parcimônia. Conteúdo piscando ou mudando rapidamente pode desencadear convulsões. Se usar animação, garanta que não pisque mais de três vezes por segundo. Se possível, forneça uma maneira de pausar a animação.
Texto e tipografia
O tamanho da fonte é legível. Mínimo de 14px para o texto do corpo, idealmente 16px. Texto menor é difícil para muitos usuários, não apenas para aqueles com deficiência visual.
A altura da linha é adequada. Pelo menos 1,5x o tamanho da fonte. Texto apertado é difícil de ler para todos e especialmente para usuários com dislexia ou deficiências cognitivas.
O contraste de cor atende aos padrões da WCAG. O texto deve ter pelo menos uma taxa de contraste de 4,5:1 em relação ao fundo (3:1 para texto grande). Use uma ferramenta de verificação de contraste para confirmar.
A cor não é o único indicador. Não dependa apenas da cor para transmitir significado. "Campos em vermelho são obrigatórios" falha para usuários daltônicos. Use ícones, rótulos de texto ou padrões além da cor.
O texto pode ser redimensionado. Use unidades relativas (em, rem, %) em vez de pixels fixos sempre que possível. Usuários que precisam de texto maior devem conseguir obtê-lo.
Estrutura e semântica
Cabeçalhos criam hierarquia lógica. Use tags de cabeçalho (h1, h2, h3) para estruturar o conteúdo. Não pule níveis. Usuários de leitores de tela navegam pelos cabeçalhos—uma hierarquia adequada faz isso funcionar.
Tabelas são usadas para dados, não para layout. Tabelas de layout confundem leitores de tela. Use tabelas apenas para dados verdadeiramente tabulares. Para layout, use outras técnicas (embora as limitações do HTML em email tornem isso desafiador).
Tabelas de dados têm cabeçalhos. Use <th> para células de cabeçalho com scope="col" ou scope="row". Isso informa aos leitores de tela como associar células de dados aos seus cabeçalhos.
A ordem de leitura é lógica. Leitores de tela seguem a ordem do DOM, não a ordem visual. Garanta que a ordem do HTML faça sentido quando lida de forma linear, mesmo que o CSS reorganize elementos visualmente.
O idioma está especificado. Inclua lang="en" (ou o código de idioma apropriado) no elemento HTML. Isso ajuda leitores de tela a usar a pronúncia correta.
Links e botões
O texto do link é descritivo. "Clique aqui" e "Leia mais" não significam nada fora de contexto. Usuários de leitores de tela frequentemente navegam pelos links—"Leia nossa política de privacidade" diz a eles para onde o link leva.
Links são visualmente distintos. Sublinhados são o indicador mais confiável. Apenas cor não é suficiente para usuários daltônicos.
As áreas de toque são grandes o suficiente. Mínimo de 44x44 pixels para elementos tocáveis. Links pequenos são difíceis para usuários com limitações motoras e frustrantes para todos em dispositivos móveis.
Links têm estados de foco. Usuários de teclado precisam ver qual elemento está focado. Garanta que os estilos de foco sejam visíveis e distintos.
Formulários (se aplicável)
Campos de formulário têm rótulos. Todo input precisa de um rótulo associado. Use <label for="fieldid"> ou envolva o input no elemento label.
Mensagens de erro são claras. Explique o que deu errado e como corrigir. Não apenas destaque o campo em vermelho—forneça uma explicação em texto.
Campos obrigatórios estão indicados. Marque campos obrigatórios de forma clara, usando texto ("obrigatório") e não apenas asteriscos ou cor.
Testando acessibilidade
Teste com um leitor de tela. NVDA (Windows, gratuito), VoiceOver (Mac/iOS, nativo) e TalkBack (Android, nativo) são as principais opções. Ouça como seu email soa, não apenas como ele parece.
Teste a navegação por teclado. Você consegue alcançar todos os elementos interativos usando Tab? A ordem de foco é lógica? Você consegue ativar links e botões com Enter?
Teste com imagens desabilitadas. Muitos clientes de email bloqueiam imagens por padrão. Seu email é compreensível sem elas?
Teste em diferentes níveis de zoom. Aumente para 200% no seu navegador. O layout ainda funciona? O texto ainda é legível?
Use ferramentas automatizadas. WAVE, axe e ferramentas semelhantes capturam problemas comuns. Elas não pegam tudo—testes manuais ainda são necessários—mas são um bom ponto de partida.
Considerações específicas de email
O texto de preheader é significativo. Leitores de tela podem anunciar o preheader. Torne-o útil, não apenas "Ver no navegador" ou espaços em branco.
A versão em texto simples é completa. Alguns usuários preferem ou exigem texto simples. Garanta que sua versão em texto simples contenha todas as informações da versão HTML.
O cancelamento de assinatura é fácil de encontrar. Não esconda em um texto minúsculo. Usuários que desejam cancelar a assinatura devem conseguir encontrar a opção com facilidade.
Erros comuns
Usar imagens contendo texto. Texto em imagens não pode ser redimensionado, não se reacomoda (reflow) e não é legível por leitores de tela. Use texto real sempre que possível.
Texto justificado. Justificação total cria espaçamentos irregulares que são difíceis para usuários com dislexia. Use texto alinhado à esquerda.
"Escolhas de design" com baixo contraste. Texto cinza claro em fundos brancos pode parecer elegante, mas falha nos requisitos de acessibilidade. Priorize a legibilidade em vez da estética.
Links de pular conteúdo ausentes. Para emails longos, um link "pular para o conteúdo principal" ajuda usuários de teclado a evitar navegação repetitiva.
Frequently asked questions
Os requisitos de acessibilidade se aplicam a todos os emails?
Os requisitos legais variam por jurisdição e contexto. Mas a acessibilidade beneficia todos—estrutura mais clara, melhor experiência em dispositivos móveis, renderização mais confiável. Não há desvantagem em tornar emails acessíveis.
Como testo emails com um leitor de tela?
Envie o email para você mesmo, abra-o em um cliente de email e use um leitor de tela (VoiceOver no Mac, NVDA no Windows). Ouça o email inteiro. Observe onde a informação está faltando, confusa ou na ordem errada.
Qual é a taxa mínima de contraste para texto?
A WCAG AA exige 4,5:1 para texto normal e 3:1 para texto grande (18px+ ou 14px+ em negrito). A WCAG AAA exige 7:1 e 4,5:1, respectivamente. Use ferramentas como o verificador de contraste da WebAIM para verificar.
Posso usar CSS para recursos de acessibilidade em email?
O suporte a CSS em email é limitado e inconsistente. Baseie-se em atributos HTML (alt, lang, scope) em vez de soluções apenas com CSS. Teste em diferentes clientes para garantir que os recursos de acessibilidade funcionem.