Acessibilidade em Bulas Digitais: O Que Significa WCAG 2.1 AA na Prática

A RDC 885/2024 exige conformidade com WCAG 2.1 nível AA. Mas o que isso significa na prática? E por que a maioria dos portais farmacêuticos que dizem ser "acessíveis" reprovariam em uma auditoria séria?

Este artigo é voltado para equipes técnicas e gerentes de projeto que precisam implementar ou validar acessibilidade em portais de bula digital.

WCAG 2.1 AA: o que realmente é exigido

As Web Content Accessibility Guidelines (WCAG) são organizadas em 4 princípios, 13 diretrizes e 50 critérios de sucesso no nível AA. Para bulas digitais, os critérios mais relevantes são:

Perceptível

1.1.1 Conteúdo não textual: Toda imagem, ícone ou gráfico precisa de texto alternativo descritivo. Em bulas, isso se aplica a fórmulas químicas apresentadas como imagens e ícones de alerta.
1.3.1 Informação e relações: A estrutura da bula precisa ser transmitida semanticamente, não apenas visualmente. Headings (h1-h6) devem refletir a hierarquia real das seções. Tabelas de posologia precisam de headers (th) e caption.
1.4.3 Contraste mínimo: Razão de 4.5:1 para texto normal, 3:1 para texto grande (18pt ou 14pt bold). Muitos portais farmacêuticos usam cinza claro sobre branco que não atende esse critério.
1.4.4 Redimensionamento de texto: O conteúdo deve permanecer legível e funcional quando ampliado até 200%. Isso significa que layouts rígidos com largura fixa vão quebrar.

Operável

2.1.1 Teclado: Toda funcionalidade deve ser acessível via teclado. Menus de navegação, busca, controles de TTS, seleção de seções: tudo precisa funcionar com Tab, Enter e Escape.
2.4.1 Ignorar blocos: Deve haver um link "Pular para o conteúdo" no início da página, permitindo que usuários de leitor de tela acessem diretamente a bula sem navegar por header e menu a cada página.
2.4.6 Cabeçalhos e rótulos: Cada seção da bula precisa de um heading descritivo. "Seção 4" não é descritivo. "4. Contraindicações" é.

Compreensível

3.1.1 Idioma da página: O atributo lang do HTML deve corresponder ao idioma do conteúdo. Para bulas em português, lang="pt-BR".
3.1.2 Idioma das partes: Se a bula contiver termos em latim (nomes científicos), eles devem ser marcados com lang="la" para que leitores de tela pronunciem corretamente.
3.3.2 Rótulos ou instruções: Campos de busca devem ter labels descritivos, não apenas placeholders que desaparecem ao focar.

Robusto

4.1.2 Nome, função, valor: Componentes interativos (botão de TTS, seletor de seção, controles de áudio) devem ter roles ARIA corretos e estados anunciados por leitores de tela.

Os 5 erros mais comuns em portais de bula

1. PDF "acessível" não é acessível

Muitos laboratórios acreditam que disponibilizar o PDF da bula com tags de acessibilidade é suficiente. Não é. PDFs acessíveis são significativamente piores que HTML em termos de navegação por leitor de tela, especialmente em dispositivos móveis. A RDC 885 exige que a bula seja disponibilizada em formato web nativo, não apenas como PDF para download.

2. Headings decorativos

Usar tags h2 ou h3 apenas por estilo visual, sem respeitar a hierarquia, confunde completamente a navegação por leitor de tela. Um leitor de tela apresenta os headings como um índice navegável. Se a hierarquia está errada, o índice fica incompreensível.

3. Controles de áudio sem ARIA

Botões de play/pause do TTS que não têm aria-label ou aria-pressed são invisíveis para leitores de tela. O usuário que mais precisa do TTS (pessoa com deficiência visual) não consegue ativá-lo.

4. Tabelas de posologia sem headers

Tabelas de posologia são críticas em bulas. Sem th com scope="col" e scope="row", um leitor de tela lê os dados como uma sequência linear incompreensível: "10mg 1 comprimido 2 vezes 20mg 2 comprimidos 1 vez" em vez de "Dose: 10mg, Quantidade: 1 comprimido, Frequência: 2 vezes ao dia".

5. Foco não visível

Muitos portais removem o outline de foco (outline: none) por razões estéticas. Isso torna impossível para usuários de teclado saber onde estão na página. O outline de foco deve ser sempre visível e com contraste adequado.

Como testar corretamente

Testes de acessibilidade devem combinar três abordagens:

Validadores automáticos: axe-core, WAVE, Lighthouse. Eles capturam cerca de 30-40% dos problemas. Use como primeiro filtro, não como validação final.
Teste manual com teclado: Navegue pela bula inteira usando apenas Tab, Enter, Escape e setas. Consiga acessar todas as funcionalidades? O foco está visível? A ordem de tabulação faz sentido?
Teste com leitor de tela: NVDA (Windows, gratuito), VoiceOver (macOS/iOS, nativo), TalkBack (Android, nativo). Consiga ler a bula inteira sem ver a tela. As seções são anunciadas? As tabelas fazem sentido? O TTS pode ser ativado?

A combinação dessas três abordagens cobre mais de 90% dos problemas de acessibilidade. Os 10% restantes exigem testes com usuários reais com deficiência, o que recomendamos fortemente pelo menos uma vez antes do go-live.