Relatório de conformidade em acessibilidade

1. O que foi verificado, e com o quê

A verificação com axe-core (WCAG 2.1 A/AA) roda em todo build, contra o build local, antes do deploy — e de novo contra produção depois. Não é uma auditoria com data: é um portão.

Duas verificações não vêm do axe, porque ele não as faz. O contraste da certidão é medido contra a superfície navy — o axe devolve "inconclusivo" diante de sobreposição, e uma primeira versão desta suíte passou verde sem verificar nada. E o foco visível exige focar o elemento e olhar o resultado: é aferido com navegação por Tab real.

2. O que este relatório NÃO afirma

Ferramenta automatizada encontra entre 30% e 40% dos problemas reais de acessibilidade. O axe acha contraste, rótulo ausente, ordem de cabeçalho e ARIA inválida. Ele não acha:

• ordem de foco ilógica;
• texto de link sem sentido fora de contexto ("clique aqui");
• armadilha de teclado num componente que ele não ativou;
• conteúdo que só faz sentido com visão;
• leitura real com leitor de tela — NVDA, JAWS, VoiceOver.

Portanto: "0 violações" significa "sem os defeitos que uma máquina enxerga", nunca "acessível". Afirmar o segundo com base no primeiro é o mesmo excesso que este produto evita nos seus artefatos probatórios.

3. Pendências declaradas, com data-alvo

• A3

  Teste com leitor de tela feito em parte — falta o julgamento humano

  Em 14/08/2026 a tela de entrada e a cerimônia de assinatura foram percorridas com um leitor de tela DE VERDADE (Orca sobre Firefox), lendo a fala que ele entrega ao sintetizador. Cinco defeitos apareceram e foram corrigidos — entre eles um campo obrigatório intocado que era anunciado como "inválido" na primeira tela do produto, e dois botões diferentes com o mesmo nome dentro da cerimônia. Nenhum deles aparece na tela nem é reprovado por verificador automático. O que continua aberto é o julgamento: se a SEQUÊNCIA do que foi anunciado conta uma história compreensível para quem não vê. Isso é interpretação, exige uma pessoa ouvindo, e falta também cobrir VoiceOver e NVDA — foi um leitor só, num navegador só.

  Data-alvo: antes de qualquer edital público

• A4

  O assistente de envio de envelope não é percorrido por teclado na verificação automática

  O primeiro passo dele é escolher um arquivo, e a janela do sistema não é automatizável — nenhuma ferramenta a abre. Fingir que é (injetando o arquivo por baixo) testaria outra coisa e diria que o passo está coberto quando não está. O resto do produto passou a ser: a cerimônia inteira e as sete telas do painel são percorridas só com o teclado a cada execução.

  Data-alvo: teste manual, antes de qualquer edital público

• A6

  O token de texto secundário não é verificado pela regra automática

  Por desenho ele é rótulo e texto de apoio; exigir 4,5:1 dele achataria a hierarquia. É uma escolha declarada na regra automatizada, não um esquecimento — e ela já cobrou o seu preço: sobre o fundo antigo o token rendia 4,47:1, abaixo do piso, e só apareceu numa medição manual.

  Data-alvo: revisão com o parecer de design

4. Recursos já implementados

• Armadilha de foco com restauração em todos os diálogos, e o Escape fecha o diálogo do topo — não o que está atrás dele.
• Alvo de toque de 44 px nos controles das telas de assinatura.
• Abas navegáveis por teclado (setas, Home/End) com ordem de tabulação rotativa, no padrão ARIA de tablist.
• Assinar sem mouse — o percurso inteiro, do cadastro à assinatura registrada, é percorrido só com o teclado a cada execução da suíte, incluindo o foco levado ao desfecho depois do ato. Nenhum clique, nenhum preenchimento por atalho de automação: se um controle não for alcançável por Tab, a verificação falha.
• Painel de gestão sem mouse — as sete telas internas são percorridas inteiras, e a cada parada verifica-se que o foco anda (foco preso reprova), que ele é visível, e que a tela tem paradas de verdade.
• Diálogos devolvem o foco — ao abrir, o foco entra na caixa; ao fechar com Esc, volta ao botão que a abriu, em vez de jogar a pessoa para o começo da página. Verificado nos dois sentidos.
• Contorno de campo e anel de foco vindos de um primitivo único — antes, cada tela escrevia o seu, e a borda rendia 1,23:1 contra o piso de 3:1.
• Tema claro e escuro respeitando a preferência do sistema, com alternância manual — e uma regra automatizada que impede cor absoluta de reentrar.
• Regiões vivas nos contadores de paginação e nos estados de envio.
• Sem CAPTCHA visual. O anti-abuso do link público é prova de trabalho computacional, resolvida pelo navegador; nada é pedido a quem preenche.