WebInclusivedi Giuseppe Stumbo

Modelli ed esercizi

Qui puoi esercitarti in autonomia, senza richiedere un workshop. Vuoi capire come descrivere una barriera e preparare la sua verifica? Leggi gli esempi compilati, poi scegli un esercizio. Scrivi il tuo elaborato in un documento e confrontalo con la traccia. Per un percorso guidato sul prodotto del team, consulta il servizio Formazione.

Materiali o laboratorio: scegli da dove iniziare

Puoi iniziare dagli esempi per capire come sono fatti, oppure scegliere un esercizio e metterti alla prova. Ogni percorso spiega cosa fare e quale risultato preparare.

  • Materiali: consulta gli esempi

    Segui il caso del modulo contatti: dal problema alla proposta di correzione e al piano di retest. Nei tre documenti compilati puoi vedere quali informazioni servono a chi legge un bug report e a chi deve correggere o verificare il difetto.

    Risultato atteso: Capire quali informazioni raccogliere, come documentarle e quali prove pianificare. Sono esempi fittizi di riferimento, da adattare al tuo contesto.

  • Laboratorio: svolgi un esercizio

    Scegli una delle quattro tracce e leggi scenario e attività. Prepara nel tuo documento quanto trovi in «Da consegnare», poi controllalo con «Verifica del risultato» e confrontalo con l’esempio di risposta. Puoi lavorare da solo o con il team.

    Risultato atteso: Un elaborato da rivedere: testi e gestione degli errori, comportamento da tastiera, bug report oppure riepilogo di prove e decisioni. Gli esiti di test reali si registrano solo dopo aver eseguito le prove.

Per chi
Designer, developer, QA e referenti di prodotto, da soli o in gruppo.
Cosa puoi produrre
Un elaborato di esercizio: testi e comportamento di un componente, un bug report oppure un piano di verifica.
Come lavori
Leggi gli esempi, scegli una traccia e scrivi il tuo elaborato in un documento o negli strumenti del team.

Materiali: caso guidato di un modulo contatti

Da consultare. Osserva le tre schermate, poi usa le cinque schede per seguire contesto, segnalazione, evidenze, correzione proposta e piano di retest. La sequenza mostra come documentare il lavoro; le prove descritte restano da eseguire.

Scenario fittizio a scopo dimostrativo, non un progetto cliente. Prodotto, versioni e comportamento iniziale sono inventati; non sono state eseguite prove sul modulo descritto. Le evidenze qui riportate sono illustrative e il retest resta da eseguire.

Il caso in tre schermate

Tre schermate dimostrative: errore generico, correzione proposta e conferma prevista. Le descrizioni riportano anche i testi dell’esempio.

Errore generico

L’avviso non identifica il campo da correggere.

Nome: Mario Rossi. Email: mario@. Messaggio: Vorrei informazioni sull’audit di accessibilità. Avviso: «Si è verificato un errore». Pulsante: «Invia richiesta».

Errore associato al campo

Il messaggio identifica l’email e suggerisce il formato.

Nome: Mario Rossi. Email: mario@. Messaggio: Vorrei informazioni sull’audit di accessibilità. Errore: «Inserisci un indirizzo email completo, ad esempio nome@example.com». Pulsante: «Invia richiesta».

Conferma prevista

La conferma compare dopo l’esito positivo del server.

Nome: Mario Rossi. Email: mario@example.com. Messaggio: Vorrei informazioni sull’audit di accessibilità. Stato: «Richiesta ricevuta». La conferma non dimostra la consegna dell’email.

FORM-DEMO-001

Scenario fittizio

Contesto e perimetro

  • Obiettivo e perimetro

    Un sito di consulenza immaginario raccoglie richieste attraverso nome, email e messaggio, tutti obbligatori. L'obiettivo della verifica è permettere di individuare e correggere gli errori senza perdere i dati. Il campione comprende modulo vuoto, email non valida, correzione, invio riuscito ed errore del server. Sono esclusi consegna delle email, antispam, privacy e resto del sito.

  • Ambienti previsti

    Componente illustrativo: sito-demo.example/contatti, versione prima della correzione demo 1.0, versione candidata demo 1.1. Piano ambienti: Windows con Chrome e NVDA; iPhone con Safari e VoiceOver. In una verifica reale si registrano versioni esatte, impostazioni, data e build di ogni prova.

Segnalazione FORM-DEMO-001

  • Segnalazione

    Titolo: gli errori non identificano i campi da correggere. Riproduzione prevista: aprire il modulo, compilare nome e messaggio, inserire «mario@» nell'email e attivare «Invia richiesta» usando solo la tastiera.

  • Risultati e impatto

    • Comportamento iniziale simulato: compare «Si è verificato un errore»; il bordo dell'email diventa rosso, ma manca una spiegazione testuale del problema e il focus resta sul pulsante.
    • Risultato atteso: identificare l'email non valida, spiegare come correggerla e rendere il messaggio disponibile anche al lettore di schermo, conservando gli altri valori.
    • Impatto: chi non vede il colore o usa un lettore di schermo deve cercare la causa del mancato invio; anche chi legge il messaggio generico non sa cosa correggere.
    • Priorità proposta: alta nel flusso dimostrativo, perché la richiesta non può essere completata senza risolvere l'errore. Non è una severità assegnata dalle WCAG; nel prodotto reale va motivata con frequenza, impatto e alternative.

Evidenza illustrativa e requisiti

Correzione proposta e responsabilità

  • Interventi e responsabilità

    • Content e design: indicare «obbligatorio» nelle etichette e usare «Inserisci un indirizzo email completo, ad esempio nome@example.com». Il colore accompagna il testo, non lo sostituisce.
    • Sviluppo: mantenere controlli HTML nativi e label associate; in caso di errore impostare aria-invalid e collegare il messaggio al campo. Nel flusso scelto, portare il focus al primo campo non valido dopo l'invio, senza cancellare i dati.
    • Sviluppo: validare anche sul server; impedire invii duplicati mentre la richiesta è in corso. Annunciare la conferma con una regione di stato senza spostare il focus; per un errore tecnico conservare i valori e consentire un nuovo tentativo.
    • QA: verificare tastiera, focus, lettura degli errori e dei messaggi di stato. Dipendenze: risposta del server distinguibile tra errore dei dati ed errore tecnico, testi approvati e ambiente di prova senza invio a destinatari reali.

  • Comportamento previsto e rischi

    Dopo la correzione, il comportamento previsto è: focus sull'email, messaggio specifico associato al campo e dati conservati. Conferma prevista solo dopo risposta positiva del server: «Richiesta ricevuta». Non promette la consegna dell'email. Rischi di regressione: annunci duplicati, errori residui dopo la correzione, focus nascosto su mobile e cancellazione involontaria dei valori.

Piano di retest e criteri di accettazione

Il retest ripete le prove del difetto per verificarne la risoluzione; i test di regressione controllano gli effetti delle modifiche sui comportamenti collegati, come conservazione dei dati e invio. Questo elenco raccoglie le prove da eseguire prima di chiudere FORM-DEMO-001: è un piano di verifica, non un risultato già ottenuto.

  • Modulo vuoto

    Criterio di accettazione
    Ogni campo obbligatorio non compilato ha un errore testuale; il primo riceve il focus dopo l'invio.
    Stato
    Da eseguire

  • Email non valida

    Criterio di accettazione
    Il messaggio identifica il problema, suggerisce il formato e viene letto con il campo nei due ambienti previsti.
    Stato
    Da eseguire

  • Correzione dei dati

    Criterio di accettazione
    L'errore viene rimosso alla rivalidazione; nome e messaggio restano invariati e il focus non salta durante la digitazione.
    Stato
    Da eseguire

  • Invio riuscito

    Criterio di accettazione
    La conferma compare e viene annunciata dopo la risposta positiva; il focus resta coerente e parte una sola richiesta.
    Stato
    Da eseguire

  • Errore del server

    Criterio di accettazione
    Il messaggio distingue il problema tecnico dagli errori dei campi; i valori restano disponibili e il nuovo tentativo è possibile.
    Stato
    Da eseguire

  • Tastiera e mobile

    Criterio di accettazione
    Il flusso è completabile senza mouse, il focus è visibile e i messaggi non sono tagliati a 320 px e con ingrandimento del testo.
    Stato
    Da eseguire
Stato del caso

Correzione proposta; nessun esito di retest disponibile. Le sei prove restano da eseguire.

Quando considerare il problema risolto

Dopo le prove sulla versione corretta negli ambienti previsti, registrando data, versioni ed evidenze. Se una prova fallisce, il bug resta aperto; eventuali rischi residui vanno documentati.

Limite dell'esempio

Il piano riguarda solo questo modulo e gli ambienti indicati: non copre tutte le combinazioni assistive e non è una dichiarazione di conformità.

Materiali: bug report, correzione e retest compilati

Da consultare e adattare. Questi tre documenti fittizi mostrano come collegare una segnalazione, il lavoro di correzione e il relativo esito di verifica. Per il tuo elaborato riprendi la struttura dei campi e inserisci soltanto dati ed evidenze del caso che stai affrontando.

Bug report

Scenario didattico: un pulsante del carrello senza nome accessibile.

ID

DEMO-A11Y-001

Titolo

Il pulsante per rimuovere un articolo non ha un nome accessibile.

URL, schermata o componente

negozio.example/carrello — pulsante con icona del cestino accanto alla giacca.

Ambiente

Windows, Firefox, build demo 1.4.0. Nel test reale indicare le versioni di sistema e browser.

Tecnologia assistiva, se usata

NVDA, impostazioni predefinite. Nel test reale indicare la versione.

Passaggi per riprodurre
  1. Aprire il carrello demo con una giacca inserita.
  2. Con NVDA attivo, usare Tab fino al pulsante del cestino.
  3. Ascoltare il nome prima di attivare il pulsante.
Risultato atteso

Lo screen reader annuncia un pulsante con nome «Rimuovi giacca dal carrello».

Risultato osservato

Lo screen reader annuncia un pulsante senza nome.

Impatto utente

Chi usa lo screen reader non sa quale articolo verrà rimosso.

Severità

Alta nell'esempio: è l'unico controllo di rimozione. Da rivalutare nel prodotto reale.

Requisito collegato

WCAG 4.1.2 — Nome, ruolo, valore: il pulsante deve avere un nome accessibile.

Evidenza

Registrazione NVDA e albero di accessibilità con nome vuoto. Evidenza fittizia: DEMO-A11Y-001-prima.

Remediation

Scenario didattico: correzione del pulsante, responsabilità e criteri di accettazione.

Owner

Team frontend del negozio dimostrativo; QA incaricato del retest.

Area coinvolta
  • Sviluppo: correggere il nome del pulsante nel componente carrello.
  • QA: ripetere la prova con tastiera e NVDA.
Correzione proposta

Dare al pulsante nativo un nome con azione e articolo: «Rimuovi giacca dal carrello».

Dipendenze

Nome dell'articolo disponibile nel componente e testo tradotto nelle lingue del prodotto.

Rischio di regressione

Nomi errati con più articoli; controllare il focus dopo la rimozione.

Criterio di accettazione

Ogni pulsante identifica il proprio articolo, è raggiungibile con Tab e rimuove l'articolo corretto.

Retest

Scenario didattico: registrazione dell'esito dopo la correzione del pulsante.

Data retest

6 ottobre 2026 — data illustrativa, build dimostrativa 1.4.1.

Esito

Superato nell'esempio: NVDA identifica azione e articolo; la tastiera permette la rimozione anche con due articoli.

Prova che la correzione funziona

Registrazione e albero di accessibilità dopo gli stessi passaggi. Evidenza fittizia: DEMO-A11Y-001-dopo.

Note residue

Solo Firefox/NVDA nell'esempio. Le altre configurazioni del piano restano da verificare.

Laboratorio: scegli e svolgi un esercizio

Quattro scenari fittizi, ciascuno con attività, consegna, esempio di risposta e criteri di verifica. Apri una traccia, scrivi l’elaborato nel tuo documento e controllalo prima di confrontarlo con l’esempio.

Esercizio 1 - Rendere comprensibili gli errori di un modulo

Scenario

Modulo fittizio con nome, email e messaggio obbligatori. Inserendo «mario@» compare solo «Dati non validi» e il modulo cancella il messaggio. Dopo un invio riuscito, il pulsante cambia colore ma non compare una conferma testuale.

Attività

  • Scrivere etichette e istruzioni per i tre campi, indicando quelli obbligatori.
  • Preparare i testi per campo vuoto, email non valida, invio riuscito ed errore del server.
  • Descrivere focus, associazione degli errori ai campi e conservazione dei dati dopo l'invio.
  • Definire come rendere disponibile la conferma anche al lettore di schermo, senza annunci duplicati.

Da consegnare

  • Testi dei campi e dei quattro stati.
  • Sequenza del focus e tre prove: email errata, invio riuscito, errore tecnico.

Esempio di risposta

Email non valida: «Inserisci un indirizzo completo, ad esempio nome@example.com». Dopo l'invio il focus raggiunge l'email; nome e messaggio restano compilati.

Verifica del risultato

  • Si capisce cosa correggere senza affidarsi al colore?
  • Ogni prova specifica testo atteso, focus e dati da conservare?
  • La conferma dipende dalla risposta positiva del server, non dal solo clic?

Esercizio 2 - Progettare una navigazione da tastiera

Scenario

Navigazione fittizia con «Servizi», pagina cliccabile, e due sottopagine: «Audit» e «Formazione». Il sottomenu si apre solo al passaggio del mouse. Su mobile un pannello modale copre la pagina, ma Tab raggiunge ancora i link sottostanti.

Attività

  • Separare il link «Servizi» dal pulsante che apre le sottopagine.
  • Disegnare il percorso di Tab e Maiusc+Tab a sottomenu chiuso e aperto; indicare Invio, Spazio ed Escape.
  • Per il pannello modale mobile, definire focus iniziale, contenimento del focus e ritorno al pulsante di apertura.
  • Specificare lo stato espanso del pulsante. Per una normale navigazione a link, non imporre il comportamento di un menu applicativo.

Da consegnare

  • Schema desktop e mobile con ordine del focus.
  • Prove di apertura, chiusura e accesso alle tre pagine senza mouse.

Esempio di risposta

Su desktop: Tab raggiunge il link «Servizi», poi il pulsante delle sottopagine. Invio apre il sottomenu; Tab raggiunge «Audit» e «Formazione». Escape chiude e riporta il focus al pulsante.

Verifica del risultato

  • La pagina «Servizi» resta raggiungibile senza aprire il sottomenu?
  • I link nascosti sono esclusi dal percorso di Tab?
  • Il pannello mobile si chiude da tastiera e restituisce il focus?

Esercizio 3 - Trasformare una nota in un bug riproducibile

Scenario

Nota fittizia del QA: «Nel carrello non capisco quale articolo cancello». Ci sono due prodotti, «Tazza blu» e «Tazza verde», e due pulsanti con nome accessibile «Rimuovi». Mancano ambiente, passaggi e risultato atteso.

Attività

  • Scrivere titolo, condizioni iniziali e passaggi per raggiungere i due pulsanti.
  • Separare comportamento osservato, risultato atteso e impatto per chi usa un lettore di schermo.
  • Proporre nomi distinguibili e una priorità motivata; indicare quali informazioni restano da raccogliere.
  • Definire una prova di retest per ciascun prodotto, senza dichiarare verifiche mai eseguite.

Da consegnare

  • Un bug report con passaggi numerati, impatto e correzione proposta.
  • Elenco delle prove mancanti e risultati necessari per considerare il problema risolto.

Esempio di risposta

Atteso: «Rimuovi Tazza blu» e «Rimuovi Tazza verde». Retest: verificare che ciascun pulsante identifichi il prodotto e rimuova soltanto quello scelto. Ambiente e lettura effettiva restano da documentare.

Verifica del risultato

  • Un collega può riprodurre il problema senza chiedere altri passaggi?
  • L'impatto descrive un ostacolo concreto, non solo «non accessibile»?
  • Fatti forniti, ipotesi e informazioni mancanti sono distinti?

Esercizio 4 - Collegare prove, correzioni e decisioni

Scenario

Tre note fittizie sul modulo contatti: l'email errata è stata controllata da tastiera; la lettura dell'errore con NVDA non è stata verificata; la conferma dopo l'invio è ancora da correggere. Il responsabile chiede se il modulo è pronto al rilascio.

Attività

  • Creare una matrice con prova, ambiente, evidenza, stato, responsabile e prossimo passo.
  • Distinguere ciò che la nota riferisce da ciò che è dimostrato: anche la prova da tastiera richiede un'evidenza allegata.
  • Pianificare il controllo con NVDA e il retest della conferma dopo la correzione.
  • Scrivere una decisione di rilascio motivata, limitata al campione e alle informazioni disponibili.

Da consegnare

  • Matrice di tre righe con evidenze mancanti e azioni assegnate.
  • Nota di decisione con condizioni per il rilascio e limiti della verifica.

Esempio di risposta

Lettura errore con NVDA: non verificata; responsabile QA; prossimo passo: eseguire la prova sulla versione candidata e allegare ambiente, data ed esito. Non registrare «superato» sulla base della sola prova da tastiera.

Verifica del risultato

  • Ogni stato è sostenuto da un'evidenza o indicato come da verificare?
  • Le attività ancora da svolgere hanno un responsabile e un risultato atteso verificabile?
  • La nota evita di dichiarare conforme l'intero sito da tre prove sul modulo?
Consulta le condizioni di riuso dei materiali