WebInclusivedi Giuseppe Stumbo

Verifica di un sito web

Una persona deve poter cercare, leggere o inviare una richiesta nel tuo sito. Questa guida ti aiuta a scegliere i percorsi da provare, riconoscere le barriere e documentare ciò che trovi.

Preparare ed eseguire i controlli

Prima di usare gli strumenti, chiarisci cosa vuoi sapere: dove una persona si blocca, quali modifiche controllare o quali evidenze raccogliere.

  • Scope

    Definisci scope, requisiti e criteri di uscita

    Decidi quali pagine e funzioni controllare: questo è il perimetro della verifica. Un controllo prima del rilascio può riguardare un percorso completo; la verifica di una modifica può concentrarsi sul componente interessato e sui percorsi collegati.

    • Indica dominio, ambienti, pagine escluse, autenticazione, lingue, breakpoint e tecnologie assistive da usare.
    • Collega le pagine e le funzioni da verificare al risultato atteso: elenco dei rischi, attività da assegnare al team, report, dichiarazione, ACR o piano di correzione.

  • Campionamento

    Costruisci un campione rappresentativo

    Se non controlli ogni pagina, scegli un insieme rappresentativo, chiamato campione. Includi layout, componenti e stati diversi: dodici pagine simili possono non coprire ricerca, acquisto, errori del modulo e conferme.

    • Includi home, navigazione, ricerca, form, liste, schede dettaglio, documenti, errori e stati dinamici quando presenti.
    • Annota per ogni pagina perché entra nel campione: template, frequenza d'uso, rischio, obbligo informativo o funzione critica.

  • ACT

    Definisci applicabilità e risultato atteso

    Le regole ACT descrivono cosa verificare, quando la prova si applica e quale risultato attendersi. Usa gli esempi per confrontare la tua procedura e registra anche i casi non applicabili o non verificati.

    • Controlla lo stato della regola: approvata, proposta o deprecata.
    • Un esito positivo della regola non dimostra da solo la conformità del criterio WCAG.

  • Test

    Combina strumenti, controlli manuali e giudizio umano

    Combina scanner automatici, test da tastiera, screen reader, ispezione semantica e prove dei task. Es.: uno scanner può rilevare l'assenza di un testo alternativo, ma la sua adeguatezza richiede una valutazione del contenuto e del contesto.

    • Usa controlli automatici per trovare pattern ricorrenti, ma valida manualmente focus, nome accessibile, ruolo, stato e messaggi.
    • Quando possibile, coinvolgi persone con disabilità o dati da feedback reali per leggere l'impatto oltre il solo errore tecnico.

  • Validazione

    Distingui validazione HTML, scanner e test E2E

    Il Nu Html Checker verifica il markup; uno scanner come axe può rilevare un pulsante senza nome accessibile; l'albero di accessibilità espone nome, ruolo e stato. I test E2E verificano gli scenari implementati: nessuno di questi strumenti attesta da solo la conformità WCAG.

    • Nu Html Checker trova errori di markup; DevTools aiuta a leggere nome, ruolo e proprietà esposte dal browser.
    • Valuta ogni avviso dello strumento: può indicare cosa controllare, ma non dimostra da solo la conformità o l'assenza di barriere.

Dal report di audit al retest delle correzioni

Documenta i finding, pianifica la remediation e verifica i fix con retest tracciabili. Aggiorna lo stato delle issue e la suite di regressione: la chiusura di un difetto non attesta la conformità dell’intero sito.

  • Componenti

    Controlla ARIA, focus e design system nei componenti riusabili

    Le barriere nei componenti condivisi possono propagarsi su molte pagine. Es.: un dialog modale con contenimento del focus errato può riprodurre il difetto in ogni flusso che lo usa.

    • Usa HTML nativo quando copre semantica e comportamento; aggiungi ARIA solo quando serve e con stati aggiornati correttamente.
    • Nel design system conserva esempi accessibili, casi vietati, criteri di accettazione e test minimi per evitare regressioni su più pagine.

  • Finding e triage

    Documenta i finding e prioritizza la remediation

    Un finding documenta un risultato dell'audit. Il triage ne valuta impatto, severità e priorità: la non conformità richiede un criterio WCAG applicabile non soddisfatto. Es.: "il pulsante Conferma non è raggiungibile da tastiera al passo 2 del checkout" è riproducibile; "il checkout non è accessibile" non basta.

    • Descrivi passaggi, comportamento osservato, comportamento atteso, criterio WCAG, severità, pagina e tecnologia usata.
    • Tieni distinta la diagnosi dalla possibile soluzione, così il team può scegliere la correzione più adatta.

  • Retest e regressione

    Esegui il retest e definisci la suite di regressione

    Il retest (confirmation testing) verifica la risoluzione del difetto sulla build corretta. I test di regressione verificano gli effetti delle modifiche sulle funzionalità già operative: non sono sinonimi. Es.: dopo un fix del focus in un dialog, riprova il difetto e i flussi collegati.

    • Definisci quali problemi richiedono una nuova verifica manuale, per quali bastano controlli rapidi e quali prove ripetere per evitare che il problema ricompaia.
    • Quando una barriera ricorre su più template, verifica il componente condiviso e stabilisci una frequenza di controllo.

  • Knowledge base

    Trasforma gli errori ricorrenti in conoscenza riusabile

    Trasforma gli errori ricorrenti in controlli riutilizzabili dal team. Es.: se manca più volte l'etichetta dei filtri, aggiungi quel controllo alla checklist invece di trattare ogni caso come un problema isolato.

    • Per ogni pattern frequente conserva cosa controllare, come provarlo e quale comportamento atteso documentare.
    • Aggiorna la documentazione condivisa quando una nuova verifica mostra che la correzione non funziona su altre pagine o stati del componente.

Fonti e strumenti da aprire durante la verifica

Riferimenti ufficiali per impostare la verifica: primo controllo, metodologia di campionamento e struttura del report.