Messaggi di stato

Cosa richiede

Quando la pagina comunica all’utente che qualcosa è accaduto — «Articolo aggiunto al carrello», «3 risultati trovati», «Connessione persa», «Salvataggio in corso…» — quel messaggio deve raggiungere gli utenti di lettori di schermo senza costringere lo spostamento del focus. L’informazione deve essere determinata programmaticamente come stato, in modo che le tecnologie assistive possano intercettarla e annunciarla.

Tre categorie che WCAG identifica:

• Successo / completamento — «Profilo salvato», «Email inviata».
• Risultati di un’azione — «12 risultati», «Nessuna corrispondenza trovata».
• Stato dell’applicazione — «Salvataggio in corso…», «Riconnessione in corso», «Caricamento al 40%».

Come soddisfarlo

• Inserisci una regione live nel DOM al caricamento della pagina — un elemento vuoto con role="status" (educato) o role="alert" (assertivo). Al momento dell’aggiornamento, scrivi il nuovo testo al suo interno.
• Per le conferme non critiche e i conteggi dei risultati, usa role="status" o aria-live="polite". I lettori di schermo attendono che l’utente sia inattivo, poi annunciano.
• Per i messaggi critici — errori di invio del modulo, connessione persa, sessione prossima alla scadenza — usa role="alert" o aria-live="assertive". L’annuncio interrompe immediatamente.
• Le notifiche toast necessitano di una regione live. Il contenitore del toast deve esistere nel DOM prima che il toast appaia, con aria-live impostato, e il testo del toast iniettato come figlio.
• Abbina aria-live con aria-atomic="true" se vuoi che l’intera regione venga riletta a ogni aggiornamento, non solo i nodi modificati.
• Per gli errori del modulo, il messaggio di errore inline può usare role="alert", oppure sposta il focus a un riepilogo in cima al modulo — ma non fare entrambe le cose; gli utenti devono sentirlo una sola volta.

Errori comuni

• Notifiche toast inserite in un elemento che non esisteva prima del toast — il listener della regione live non si attacca mai, nulla viene annunciato.
• Un banner di successo che viene inserito ma si trova fuori da qualsiasi regione aria-live — visibile agli utenti vedenti, invisibile agli utenti di lettori di schermo.
• Il conteggio dei risultati di ricerca («Visualizzazione di 12 di 340») che si aggiorna silenziosamente dopo il filtraggio. Gli utenti ritornano ai risultati senza sapere se qualcosa è cambiato.
• La validazione del modulo che aggiorna uno <span class="error"> inline senza role="alert" o aria-live — l’errore appare, il lettore di schermo rimane in silenzio.
• L’uso di aria-live="assertive" per ogni aggiornamento di stato. Interruzioni continue; gli utenti di lettori di schermo disabilitano la pagina.
• Lo spostamento del focus su un messaggio di stato che non è un’intestazione né un elemento interattivo — il focus cade su un elemento non navigabile con la tastiera, gli utenti perdono la propria posizione.
• Indicatori «Salvataggio in corso…» / «Salvato» che invertono una classe CSS ma non aggiornano mai il contenuto testuale all’interno di una regione live.

Perché è importante

I messaggi di stato sono il punto debole delle moderne applicazioni a pagina singola. La pagina non si ricarica mai, il focus si sposta raramente, e quindi l’unico segnale che qualcosa è accaduto è un cambiamento visivo — inutile per chiunque non stia guardando lo schermo. Il 4.1.3 impone la parità: se un utente vedente può vedere «Aggiunto al carrello», un utente di lettore di schermo può sentirlo. La soluzione è quasi sempre economica (una regione live, popolata all’aggiornamento) e la sua assenza rompe quasi sempre i flussi principali — checkout, ricerca, invio del modulo, chat in tempo reale.