A aplicação web da VeriSwarm é construída para atender, e testada continuamente em relação, às Web Content Accessibility Guidelines (WCAG) 2.2, Level AA — a referência citada pela ADA e pela Section 508. Esta página declara com clareza nosso objetivo de conformidade, o que realmente já verificamos e o que ainda precisa de trabalho. Não afirmamos aqui conformidade total ou certificada — afirmamos o que testamos e listamos o que ainda não concluímos.
Última revisão: 27 de agosto de 2026.
Nosso objetivo é o nível WCAG 2.2 Level AA em todo o veriswarm.ai. Esse objetivo é aplicado no nosso próprio pipeline de entrega, não é apenas uma aspiração: verificações automatizadas de acessibilidade rodam a cada mudança antes do merge, e páginas representativas passam ainda por auditorias manuais e verificação com leitor de tela. Não é uma certificação pontual — é uma verificação que executamos continuamente à medida que o site muda.
Esta declaração cobre a aplicação web veriswarm.ai — o site de marketing, a documentação, o blog, os preços, o fluxo de autenticação e os consoles autenticados de conta e administração. Ela não cobre sites de terceiros para os quais linkamos, nem conteúdo que nossos clientes publicam através da plataforma (por exemplo, páginas geradas por agentes).
Controles e verificações concretos que estão realmente em funcionamento hoje, não um roteiro.
As regras jsx-a11y do ESLint rodam a cada commit, e varreduras automatizadas de páginas com axe-core rodam contra rotas representativas a cada mudança. Ambas são verificações bloqueantes, não apenas avisos.
Além da varredura automatizada, fizemos auditorias manuais em nível de código em arquétipos de página representativos — landing, conteúdo de documentação/aprendizado, preços, blog, autenticação, dashboard e administração — verificando manualmente a estrutura de cabeçalhos, os landmarks, a acessibilidade por teclado e a correção do ARIA.
Cada página usa uma única estrutura de landmarks — um header/nav, um main e um footer — com uma hierarquia de cabeçalhos adequada, e um link “Skip to content” é o primeiro elemento focável em cada página.
Os controles interativos são alcançáveis e operáveis apenas pelo teclado, com um indicador de foco visível em cada elemento focável. Widgets personalizados, como modais, implementam uma trap de foco adequada, fechamento com Esc e retorno do foco ao elemento que o acionou.
As animações e os movimentos respeitam a preferência de movimento reduzido do sistema operacional (prefers-reduced-motion).
As cores de texto e da interface são verificadas em relação às taxas de contraste da WCAG 1.4.3 (4.5:1 para texto normal, 3:1 para texto grande e limites de interface), calculadas com a fórmula real de luminância relativa em vez de a olho nu.
Gráficos e visualizações de pontuação expõem seus dados subjacentes como texto (rótulos, tabelas ou descrições acessíveis) em vez de depender apenas de cor ou forma.
Os campos de formulário têm rótulos associados de forma programática, e erros de validação são expostos com aria-invalid e aria-describedby em vez de apenas cor.
Não afirmamos conformidade completa ou certificada. Aqui está o que sabemos que ainda precisa de trabalho, e por que não lançamos uma correção que não pudéssemos verificar.
O dashboard de conta e o console de administração já passaram por auditorias completas em nível de código (estrutura de cabeçalhos, uso de landmarks, correção do ARIA, gerenciamento de foco), mas como essas superfícies exigem uma sessão de login ativa, a verificação com um leitor de tela real e uma navegação apenas por teclado sobre a saída realmente renderizada ainda está em andamento. Consideramos uma auditoria em nível de código necessária, mas não suficiente por si só.
Algumas seções com abas nos consoles de conta e administração (por exemplo, a navegação da conta e as subabas Cortex/Governance) atualmente usam botões padrão que alternam o conteúdo visível, em vez do padrão completo de abas ARIA (role="tablist"/tab/tabpanel com navegação por teclas de seta). Uma tentativa anterior de adicionar roles ARIA parciais sem o padrão completo foi revertida, porque um widget de abas parcialmente implementado é pior para tecnologia assistiva do que um simples conjunto de botões — ele anuncia uma interação de abas que a página, na verdade, não suporta. Os botões simples continuam totalmente operáveis por teclado e mouse enquanto isso; um padrão de interface com abas mais completo e totalmente implementado para essas seções é um trabalho futuro planejado.
Se você encontrar algo em veriswarm.ai que seja difícil de usar com teclado, leitor de tela ou outra tecnologia assistiva, nos avise. Inclua a URL da página, o que você estava tentando fazer e, se possível, a tecnologia assistiva ou o navegador que você estava usando.
support@veriswarm.ai