O e-mail em HTML ainda é HTML, renderizado por um agente de usuário — um cliente de webmail é um navegador, e o motor de renderização de um aplicativo de e-mail nativo não é fundamentalmente diferente. Os critérios de sucesso do WCAG não abrem uma exceção específica para e-mail, e se aplicam de forma igualmente direta a uma enquete, quiz ou acordeão somente CSS quanto ao componente web equivalente. Este é um checklist prático para os quatro critérios mais relevantes para e-mail interativo, construído com a técnica do checkbox hack.
Por que o WCAG se aplica aqui, afinal
O WCAG 2.2 é escrito em termos de "conteúdo" renderizado por um "agente de usuário", não especificamente de "páginas web" — não é um padrão formal específico para e-mail, já que o e-mail como meio não é sequer mencionado na especificação, mas o conteúdo subjacente é HTML de qualquer forma. É por isso que a comunidade de acessibilidade trata os critérios de sucesso do WCAG como a régua prática para conteúdo de e-mail, da mesma forma que este checklist faz, em vez de tratar o e-mail como uma categoria separada que as diretrizes não alcançam.
1.1.1 Conteúdo Não Textual — toda imagem precisa de um alt de verdade
Fotos de produto, imagens de destaque, separadores decorativos e botões apenas com ícone precisam todos de um atributo alt que um leitor de tela consiga anunciar — ou, para imagens genuinamente decorativas que não carregam nenhuma informação, um alt="" explicitamente vazio, para que o leitor de tela as ignore em vez de ler um nome de arquivo sem sentido. Isso importa mais em blocos interativos do que em blocos estáticos: uma roleta premiada ou uma raspadinha inteiramente baseada em imagem, sem nenhuma alternativa textual descrevendo o resultado, deixa um usuário de leitor de tela sem nenhuma forma de saber o que ganhou.
1.4.3 / 1.4.11 — Contraste para texto e controles interativos
O WCAG estabelece uma razão de contraste mínima de 4.5:1 para texto de corpo normal (3:1 para texto grande, segundo o 1.4.3), e um mínimo de 3:1 para os limites visuais de componentes de interface e elementos gráficos (1.4.11). Ambos se aplicam diretamente a elementos interativos, não apenas ao texto de parágrafo — a borda de uma opção de enquete, o fundo do botão de resposta de um quiz em relação ao seu contêiner, os dígitos de um cronômetro de contagem regressiva em relação ao seu fundo. Um controle interativo de baixo contraste não é apenas um erro estético; ele pode tornar o controle completamente invisível para um destinatário com baixa visão.
2.1.1 Teclado — a vantagem genuína da técnica do checkbox hack
Um <input type="radio">/<input type="checkbox"> real, combinado com um <label for="...">, é nativamente focável e operável com Tab mais Espaço ou Enter, em qualquer cliente que renderize controles de formulário — sem marcação extra, sem trabalho extra, porque é assim que os navegadores sempre trataram controles de formulário reais. Veja Máquinas de Estado CSS :checked para entender como a própria técnica funciona. Essa é uma vantagem genuína sobre o que um carrossel web movido a JavaScript costuma fazer — um <div onclick> sem nenhum manipulador de teclado — e é uma vantagem que o e-mail interativo ganha por construção, não por esforço extra, desde que pares reais de <label>/<input> sejam usados em vez de <div>s clicáveis nuas.
2.5.8 Tamanho do Alvo (Mínimo) — novo no WCAG 2.2
O Critério de Sucesso 2.5.8, introduzido no WCAG 2.2, estabelece um piso de 24×24 pixels CSS para alvos interativos, com exceções para texto embutido, restrições de layout essenciais, ou um controle equivalente maior disponível em outro lugar. É mais relevante no mobile — onde acontece a maioria das aberturas de e-mail — para os menores elementos interativos que um estúdio facilita encolher demais: pontos de carrossel, ícones de avaliação por estrelas, chips de resposta de quiz agrupados de forma apertada.
4.1.2 Nome, Função, Valor — rotulando corretamente os controles :checked
Um leitor de tela anuncia o nome, a função e o estado atual de um controle a partir de marcação semântica real — que é exatamente o que um <label> envolvendo um <input> real fornece de graça, e exatamente o que falta em uma <div> estilizada nua fazendo às vezes de botão. Na prática, isso significa que toda opção de enquete, resposta de quiz e cabeçalho de acordeão precisa de um texto de rótulo real que um leitor de tela consiga ler em voz alta, não apenas uma imagem de fundo ou um ícone sem texto de acompanhamento.
Checklist prático
- Toda imagem carrega um
altde verdade, ou umalt=""explicitamente vazio se for decorativa. - O texto e as bordas dos controles interativos atendem ao contraste de 4.5:1 (texto) / 3:1 (componente de interface).
- Toda interação
:checkedusa um par real de<input>+<label for="...">— nunca uma<div>clicável nua. - Os alvos interativos têm pelo menos 24×24 pixels CSS, especialmente em blocos voltados para mobile.
- Os rótulos de enquete/quiz/acordeão carregam texto real e legível — não apenas uma imagem ou ícone.