L'applicazione web di VeriSwarm è realizzata per essere conforme, e viene testata continuamente rispetto, alle Web Content Accessibility Guidelines (WCAG) 2.2, Level AA — il riferimento citato dall'ADA e dalla Section 508. Questa pagina dichiara con chiarezza il nostro obiettivo di conformità, ciò che abbiamo effettivamente verificato e ciò che resta ancora da fare. Qui non dichiariamo una conformità completa o certificata: dichiariamo ciò che abbiamo testato ed elenchiamo ciò che non abbiamo ancora completato.
Ultima revisione: 27 agosto 2026.
Il nostro obiettivo è WCAG 2.2 Level AA su tutto veriswarm.ai. Questo obiettivo viene applicato nella nostra stessa pipeline di rilascio, non è solo un'aspirazione: controlli di accessibilità automatizzati vengono eseguiti a ogni modifica prima del merge, e le pagine rappresentative ricevono inoltre audit manuali e verifica con screen reader. Non è una certificazione una tantum: è un controllo che rieseguiamo continuamente man mano che il sito cambia.
Questa dichiarazione copre l'applicazione web veriswarm.ai — il sito marketing, la documentazione, il blog, i prezzi, il flusso di autenticazione e le console autenticate di account e amministrazione. Non copre siti di terze parti a cui rimandiamo, né i contenuti che i nostri clienti pubblicano tramite la piattaforma (per esempio pagine generate da agenti).
Controlli e verifiche concreti che sono effettivamente attivi oggi, non una roadmap.
Le regole jsx-a11y di ESLint vengono eseguite a ogni commit, e le scansioni automatizzate delle pagine con axe-core vengono eseguite su percorsi rappresentativi a ogni modifica. Entrambi sono controlli bloccanti, non semplici avvisi.
Oltre alla scansione automatizzata, abbiamo condotto audit manuali a livello di codice su archetipi di pagina rappresentativi — landing, contenuti di documentazione/apprendimento, prezzi, blog, autenticazione, dashboard e amministrazione — verificando a mano la struttura dei titoli, i landmark, la raggiungibilità da tastiera e la correttezza ARIA.
Ogni pagina utilizza un'unica struttura di landmark — un header/nav, un main e un footer — con una gerarchia dei titoli corretta, e un link “Skip to content” è il primo elemento che riceve il focus in ogni pagina.
I controlli interattivi sono raggiungibili e utilizzabili solo con la tastiera, con un indicatore di focus visibile su ogni elemento che può riceverlo. I widget personalizzati come le modali implementano una corretta trappola del focus, la chiusura con Esc e il ritorno del focus all'elemento che lo ha attivato.
Le animazioni e i movimenti rispettano la preferenza di movimento ridotto del sistema operativo (prefers-reduced-motion).
I colori del testo e dell'interfaccia vengono verificati rispetto ai rapporti di contrasto di WCAG 1.4.3 (4.5:1 per il testo normale, 3:1 per il testo grande e i confini dell'interfaccia), calcolati con la formula reale di luminanza relativa anziché a occhio.
I grafici e le visualizzazioni dei punteggi espongono i dati sottostanti come testo (etichette, tabelle o descrizioni accessibili) invece di affidarsi solo al colore o alla forma.
I campi dei moduli hanno etichette associate in modo programmatico, e gli errori di validazione vengono segnalati con aria-invalid e aria-describedby anziché solo con il colore.
Non dichiariamo una conformità completa o certificata. Ecco cosa sappiamo che richiede ancora lavoro, e perché non abbiamo rilasciato una correzione che non potevamo verificare.
Il dashboard dell'account e la console di amministrazione hanno già ricevuto audit approfonditi a livello di codice (struttura dei titoli, uso dei landmark, correttezza ARIA, gestione del focus), ma poiché queste superfici richiedono una sessione di accesso attiva, la verifica con uno screen reader reale e un percorso solo da tastiera sull'output effettivamente renderizzato è ancora in corso. Consideriamo un audit a livello di codice necessario, ma non sufficiente da solo.
Alcune sezioni a schede nelle console di account e amministrazione (per esempio la navigazione dell'account e le sotto-schede Cortex/Governance) usano attualmente pulsanti standard che cambiano il contenuto visibile, invece del pattern completo di schede ARIA (role="tablist"/tab/tabpanel con navigazione tramite tasti freccia). Un tentativo precedente di aggiungere ruoli ARIA parziali senza il pattern completo è stato annullato, perché un widget di schede implementato a metà è peggiore per le tecnologie assistive rispetto a un semplice set di pulsanti — annuncia un'interazione a schede che la pagina in realtà non supporta. Nel frattempo i pulsanti semplici restano pienamente utilizzabili con tastiera e mouse; un pattern di interfaccia a schede più completo e correttamente implementato per queste sezioni è un lavoro futuro pianificato.
Se incontri su veriswarm.ai qualcosa di difficile da usare con tastiera, screen reader o altra tecnologia assistiva, faccelo sapere. Indica l'URL della pagina, cosa stavi cercando di fare e, se puoi, la tecnologia assistiva o il browser che stavi usando.
support@veriswarm.ai