Risorse · 89
Messaggi di stato accessibili: esito, attesa ed errore
Comunicare gli aggiornamenti senza interrompere inutilmente il compito.
Aggiornato · 2 min
Obiettivi di questa guida
- Mappare gli aggiornamenti
- Scegliere il meccanismo appropriato
- Scrivere messaggi completi
- Provare la sequenza reale
- Proteggere il focus
Verifica rapida
- Ogni aggiornamento deve essere annunciato?
- role status basta per superare il collaudo?
- Una conferma deve ricevere il focus?
Metodo passo passo
- 1
Mappare gli aggiornamenti
Elencare ricerca, salvataggio, carrello, attesa ed errore. Il criterio WCAG 4.1.3 riguarda messaggi di stato presentati senza ricevere il focus; non impone di annunciare ogni cambiamento della pagina.
Risultato: elenco di stati e priorità.
- 2
Scegliere il meccanismo appropriato
Usare role status per aggiornamenti opportuni e distinguere avvisi urgenti. Non annunciare ogni battuta di tastiera né trasformare tutti i messaggi in allarmi.
Risultato: meccanismo associato al compito.
- 3
Scrivere messaggi completi
Dare esito, oggetto e contesto: un numero isolato non basta. Rendere recuperabili informazioni utili; mantenere errori e valori necessari alla correzione.
Risultato: testi e regole di persistenza.
- 4
Provare la sequenza reale
Preparare la regione prima dell’aggiornamento quando serve. Verificare messaggi ripetuti, risposte fuori ordine e combinazioni effettive di browser e lettore di schermo. Un ruolo nel DOM non certifica il risultato.
Risultato: osservazioni di collaudo ripetibili.
- 5
Proteggere il focus
Una conferma non deve spostare arbitrariamente il focus. Un dialogo che richiede una scelta ha un comportamento diverso. Provare prosecuzione del compito e recupero dopo errore.
Risultato: percorso completo da tastiera.
Foglio di lavoro riutilizzabile
Completare con le proprie osservazioni autorizzate. Questi campi costituiscono un modello di lavoro, non risultati osservati.
| Campo | Informazioni da registrare |
|---|---|
| Attivazione | Azione ed evento che cambia lo stato |
| Annuncio | Testo, priorità e meccanismo |
| Persistenza | Informazione conservata e recupero |
| Accettazione | Prove con tastiera e tecnologie assistive |
Esempio pratico fittizio
Situazione illustrativa
Esempio fittizio: una ricerca aggiorna solo un numero in un angolo della pagina.
Decisione e prove attese
Il focus resta nel campo; al termine della ricerca compare una frase completa con numero e contesto, verificata con lettore di schermo.
Distinguere i meccanismi
| Meccanismo | Scopo | Verifica o limitazione |
|---|---|---|
| Testo visivo | Rende leggibile lo stato | Verificare percezione con tecnologie assistive |
| Regione di stato | Comunica aggiornamenti appropriati | Evitare annunci ripetitivi |
| Dialogo | Richiede una scelta o interazione distinta | Gestire focus e chiusura |
Indicatori di gestione
| Indicatore | Cosa misura | Prima azione |
|---|---|---|
| Stati compresi | Utente identifica esito e oggetto | Riscrivere messaggi ambigui |
| Annunci ripetuti | Ripetizioni durante un compito | Ridurre aggiornamenti superflui |
| Recupero riuscito | Correzione senza perdita di dati | Conservare valori e istruzioni |
Errori comuni
- Verificare percezione con tecnologie assistive
- Evitare annunci ripetitivi
- Gestire focus e chiusura
Domande frequenti
Ogni aggiornamento deve essere annunciato?
No. Selezionare gli stati rilevanti per il compito ed evitare rumore continuo.
role status basta per superare il collaudo?
No. Provare testo, sequenza, persistenza e comportamento reale.
Una conferma deve ricevere il focus?
Non automaticamente. Conservare il contesto se non è necessaria un’interazione distinta.
Riferimenti ufficiali
I riferimenti supportano il metodo. Adattare i controlli al proprio contesto; non costituiscono una certificazione. I titoli dei riferimenti originali e i documenti di origine potrebbero essere in un'altra lingua.
Riferimenti consultati il .
