Acessibilidade em emails HTML: estrutura, imagens e contraste

Emails HTML precisam acomodar limites que uma página comum não tem. Muitos modelos dependem de tabelas aninhadas para alinhar colunas, enquanto Gmail, Apple Mail e Outlook podem modificar a marcação antes de exibi-la. Quem lê com leitor de tela também encontra uma mensagem linear, não a composição visual que o designer vê. Uma boa estrutura, texto que não dependa de imagens e links com destino explícito reduzem essas diferenças.

Comece pelo HTML recebido pelo cliente, não apenas pelo editor visual. No código final, confira a ordem do conteúdo, o idioma, os nomes acessíveis e as cores. As orientações abaixo se apoiam nos critérios das WCAG 2.2 e nas particularidades de suporte documentadas por Can I email. Esses padrões dão critérios concretos para revisar uma mensagem sem presumir que todos os clientes a tratarão da mesma forma.

Tabelas de layout não são tabelas de dados

Tabelas continuam comuns em emails porque oferecem alinhamento previsível em clientes com suporte limitado a CSS. Uma tabela usada para colocar logotipo, texto e botão lado a lado é apenas um recurso visual; ela não representa linhas e colunas de informação. Sem uma indicação adicional, alguns leitores de tela podem anunciar a navegação tabular, com referências a linhas e colunas que não ajudam a entender a mensagem.

Marque cada tabela estrutural com role="presentation" ou role="none". O atributo informa às tecnologias assistivas que a função de tabela deve ser ignorada, preservando o conteúdo das células. Coloque-o no próprio elemento table; não basta adicioná-lo a um td ou tr. A tabela que realmente compara dados, como itens e valores de uma fatura, precisa manter sua semântica. Nesse caso, use células de cabeçalho th, células de conteúdo td e um título que explique o que está sendo apresentado.

<table role="presentation" width="100%">
  <tr>
    <td>Resumo da mensagem</td>
    <td><a href="https://exemplo.com/pedido">Ver pedido 4821</a></td>
  </tr>
</table>

Também revise a ordem no código-fonte. Se um bloco de duas colunas aparece visualmente como imagem à esquerda e texto à direita, um leitor de tela pode percorrer primeiro todo o conteúdo de uma célula e depois o da outra. Organize as células na sequência em que a informação deve ser ouvida. Não dependa de uma inversão visual em CSS ou da posição da coluna para transmitir uma relação importante.

Imagens, texto alternativo e o modo sem imagens

O texto alternativo deve cumprir a função da imagem naquele contexto, e não apenas descrever sua aparência. Para uma foto de produto que ajuda a identificar um item, diga qual é o produto. Para um gráfico, resuma no texto próximo a conclusão que o leitor precisa conhecer. Quando uma imagem funciona como link, o alt deve indicar a ação ou o destino. Uma imagem puramente decorativa pode usar alt="", para que não interrompa a leitura com um nome de arquivo ou descrição desnecessária.

Escrever “imagem de” antes de cada descrição raramente acrescenta informação. Tampouco existe um limite universal de caracteres que torne qualquer alternativa adequada: uma frase curta pode ser suficiente para um ícone funcional, mas insuficiente para explicar um gráfico complexo. Coloque a informação essencial também como texto HTML. Assim, o preço, a data de validade ou a instrução de uma oferta não desaparecem quando o destinatário bloqueia imagens.

A visualização com imagens desligadas é especialmente importante em email. A imagem remota pode não carregar por preferência do usuário, configuração corporativa ou falha de conexão. Nessa situação, o texto alternativo pode aparecer no espaço reservado, mas a aparência varia por cliente e por estilo. Evite depender de uma imagem de texto para explicar a oferta; se ela precisar existir por identidade visual, repita a mensagem principal em texto real. Verifique ainda se o fundo e a cor do texto mantêm leitura quando o arquivo de imagem não está disponível.

Contraste que funciona em diferentes modos

Para texto comum, a WCAG 2.2, critério 1.4.3, define contraste mínimo de 4,5:1 entre texto e fundo. Texto grande — pelo menos 18 pontos, ou 14 pontos em negrito — pode usar 3:1. Componentes gráficos e indicadores visuais têm critérios próprios, como o 3:1 do critério 1.4.11 para partes necessárias à compreensão. Esses valores são razões de contraste, não escolhas estéticas: uma cor que parece legível no monitor de quem cria o email ainda pode falhar para outra pessoa.

Não use apenas a cor para distinguir um estado ou uma instrução. Se “aprovado” estiver verde e “pendente” amarelo, inclua também essas palavras ou outro sinal textual. Para cada par de texto e fundo, confira os valores calculados e considere o texto em links, botões, avisos e rodapés. Um botão precisa oferecer contraste suficiente tanto para o rótulo quanto para a forma que o torna reconhecível como ação.

O modo escuro acrescenta outra condição de leitura. Apple Mail pode respeitar preferências de aparência, enquanto Gmail e versões do Outlook podem aplicar suas próprias transformações de cor. O resultado não é uniforme: cores claras podem ser invertidas, fundos transparentes podem revelar uma superfície diferente e um logotipo escuro pode sumir. Declare fundos e cores com cuidado, inclua uma borda ou contorno quando a forma depender do fundo e examine o conteúdo também com o modo escuro ativado. Não conte com uma media query de preferência para controlar todos os aplicativos.

Use títulos semânticos para orientar a leitura

Um título HTML é uma estrutura de navegação, não apenas um tamanho de fonte. Use um h1 para o assunto principal e títulos h2 para as seções; um h3 deve estar dentro de uma seção subordinada, sem saltos arbitrários de nível. Aplique estilo inline para controlar a aparência, mas mantenha o elemento correspondente ao nível lógico. Leitores de tela permitem percorrer títulos e oferecem uma visão rápida do conteúdo dessa maneira.

Em clientes de email, elementos como main, nav e article têm suporte irregular ou podem ser removidos. Não faça deles a única forma de identificar uma seção. Títulos reais, parágrafos, listas marcadas com ul ou ol e texto descritivo são uma base mais consistente. Use negrito para dar ênfase dentro de uma frase, não para imitar sozinho um título que deveria ser navegável.

Declare idioma e direção de leitura

O atributo lang ajuda o leitor de tela a escolher regras de pronúncia. Para uma mensagem em português brasileiro, declare lang="pt-BR" no documento e repita a declaração em body quando o processo de envio permitir. Alguns clientes removem ou reconstroem partes externas do documento, então repetir o idioma no conteúdo principal pode ajudar. Em uma expressão em outra língua, marque o trecho com o próprio idioma, por exemplo <span lang="en">shipping update</span>.

Quando a mensagem usa um idioma escrito da direita para a esquerda, declare a direção com dir="rtl" no contêiner apropriado, além do idioma. Uma expressão isolada em árabe ou hebraico dentro de um email em português pode precisar de direção própria para que pontuação e números não mudem de posição. O suporte a lang e dir varia entre clientes; por isso, a marcação deve acompanhar a estrutura real, sem depender de um único atributo em uma célula de layout. Revise os casos mistos no resultado renderizado.

Escreva links cujo propósito fique claro

O critério 2.4.4 da WCAG pede que o propósito do link possa ser entendido pelo texto do link ou por seu contexto programático. Frases como “clique aqui” e “saiba mais” repetidas perdem sentido quando alguém percorre apenas a lista de links. Prefira “Acompanhar a entrega do pedido 4821” ou “Ler o guia de tamanhos”. O texto do botão também deve nomear a ação, como “Confirmar inscrição”, em vez de usar apenas “Enviar”.

Se um ícone for o único conteúdo do link, forneça um nome acessível que indique seu destino. Não transforme uma frase inteira em um link quando apenas uma parte precisa ser acionável. Links sublinhados ou destacados por mais de uma diferença visual continuam identificáveis quando a cor não pode ser percebida; mantenha também contraste adequado para seu texto.

O que acontece nos leitores de tela e nos clientes

O cliente de email processa o HTML antes de o leitor de tela interpretá-lo. Apple Mail geralmente preserva muitos atributos HTML usados para idioma e funções de apresentação. Gmail pode reescrever identificadores e limitar certos relacionamentos ARIA; por isso, referências como aria-labelledby não devem ser a única fonte do nome ou da estrutura. Outlook para Windows usa um caminho de renderização próprio e pode tratar elementos semânticos modernos de maneira diferente de títulos e tabelas tradicionais. A versão do aplicativo, o sistema operacional e o leitor de tela também influenciam o anúncio final.

Essa variação não significa que os leitores de tela anunciem tudo da mesma maneira. O atributo pode sobreviver ao processamento do email, mas a combinação com VoiceOver, NVDA ou outra tecnologia pode alterar a navegação e a pronúncia. Use marcação HTML nativa como base: títulos para seções, links com nomes compreensíveis, texto alternativo para imagens e role="presentation" nas tabelas usadas só para composição. ARIA pode complementar essa base, mas uma mensagem não deve depender de relações que o cliente possa quebrar.

Uma revisão prática antes do envio

Abra o HTML final e confirme se cada tabela de composição tem função apresentacional, se os títulos seguem uma sequência lógica e se cada imagem tem a alternativa adequada à sua função. Leia a mensagem com as imagens bloqueadas e verifique se a oferta continua compreensível. Confira contrastes para texto normal, texto grande, links e botões; depois repita a inspeção no modo escuro. Por fim, percorra os links fora do contexto da frase e pergunte se cada destino ainda fica claro.

Uma checagem automática pode encontrar atributos ausentes ou pares de cores problemáticos, mas não decide se a descrição de um gráfico comunica a conclusão certa. A inspeção do HTML também não revela por completo a ordem que uma pessoa ouvirá depois que o cliente modificar a mensagem. Quando possível, percorra a versão recebida com leitor de tela nos ambientes usados pelo público. Trate cada correção como parte do próprio conteúdo: a acessibilidade depende da mensagem final, de sua estrutura e de como ela continua fazendo sentido nas condições reais de leitura.