Come rendere accessibili i siti web personalizzati secondo WCAG

SqualiOnline integra l'accessibilità fin dalla fase di definizione dei requisiti, applicando WCAG 2.2 AA come baseline obbligatoria. Il team utilizza una libreria di componenti UI pre‑validati, dove oltre il 90% degli elementi rispetta già i criteri di contrasto (≥4.5:1), navigazione da tastiera e ruolo ARIA corretto. Durante lo sviluppo si richiede HTML semantico, etichette label associate a campi input e testi alternativi per immagini non decorative. Le revisioni di codice includono un checklist di 25 punti tratto dalle linee guida AgID, e ogni sprint termina con un test manuale usando screen reader NVDA e VoiceOver. Questo approccio riduce il lavoro di rifacimento successivo e garantisce conformità continua.

Per valutare il livello di conformità WCAG di un sito già sviluppato, SqualiOnline esegue un audit misto che combina strumenti automatizzati e verifiche manuali. Prima si scansionano almeno 30 pagine rappresentative con axe-core e Lighthouse, ottenendo un punteggio medio di violazioni per ciascun successo criterio. Successivamente un esperto esamina le pagine critiche (moduli di login, checkout, navigazione) usando screen reader e tastiera, annotando le mancate conformità ai livelli A, AA e AAA. Il rapporto finale indica la percentuale di successo per ogni livello; ad esempio, un progetto tipico mostra il 78% di conformità AA e il 45% di AAA. Questi dati guidano le priorità di correzione.

SqualiOnline inserisce i test di accessibilità nella pipeline CI/CD mediante axe-core, Lighthouse e pa11y, eseguendoli ad ogni pull request. Se il build rileva più di due violazioni di livello A, il merge viene bloccato finché non vengono risolte. Inoltre, nello Storyboard di sviluppo si attiva l'addon @storybook/addon-a11y per controllare i componenti isolati, mentre il contrasto colore è verificato automaticamente con lo strumento WebAIM Contrast Checker. Questo approccio consente di individuare e correggere problemi già nelle prime fasi, riducendo il rischio di rilasci non conformi.

L'audit di accessibilità va eseguito almeno tre volte nel ciclo di vita di un'app personalizzata da SqualiOnline. Il primo avviene durante la fase di wireframe, verificando che la struttura informativa e le etichette siano già pronte per la navigazione da tastiera e per i lettori di schermo. Il secondo si effettua dopo lo sviluppo iniziale (build alpha), quando si testano le funzionalità chiave con strumenti automatizzati e manuali. Il terzo avviene prima del rilascio candidato, includendo un test su almeno 20 scenari d'uso reale con persone che hanno diverse disabilità. Un audit di verifica WCAG AA è programmato entro due settimane dal freeze funzionale.

Implementare l'accessibilità in un progetto su misura comporta un costo aggiuntivo che varia generalmente dal 5% al 15% del budget totale, secondo i dati di progetto di SqualiOnline. La percentuale dipende dalla complessità dell'interfaccia, dal livello di conformità richiesto (AA versus AAA) e dal riuso di componenti già accessibili nella libreria interna. Ad esempio, per un progetto medio di 200 ore di sviluppo, SqualiOnline stima un impegno extra di circa 12‑18 ore dedicato a testing, correzioni e documentazione di accessibilità. Questo investimento riduce il rischio di rilavorazioni post‑release e migliora l'esperienza per tutti gli utenti.