Verificare da tastiera il dialogo dell’indirizzo
Un esempio svolto mostra ordine del focus, annullamento e salvataggio dell’indirizzo, rendendo riproducibili gli errori da tastiera.
Un dialogo per l’indirizzo di consegna deve essere interamente utilizzabile da tastiera. Verifichi il percorso dall’apertura al ritorno sulla pagina. Raggiungere il pulsante di salvataggio non basta.
L’esempio è fittizio: nel portale clienti l’indirizzo D-17 è «Hafenweg 8». La persona vuole cambiare il numero civico in 10. Il dialogo contiene via e numero, oltre ad «Annulla» e «Salva indirizzo». È un test funzionale manuale, non una valutazione completa dell’accessibilità.
Registrare l’errore come sequenza
Nello stato iniziale ipotizzato, il dialogo si apre ma il focus resta su «Modifica indirizzo di consegna», dietro l’area oscurata. Tab raggiunge poi i collegamenti a piè di pagina. I campi visibili vengono saltati. Un test con il mouse avrebbe potuto ignorare facilmente questo errore.
Registri pagina iniziale, controllo di apertura, tasti usati ed elemento realmente focalizzato. Lo sviluppo potrà riprodurre il problema. Usi un ambiente sicuro con dati di prova; non modifichi un vero indirizzo cliente per sperimentare.
Definire il comportamento atteso
Per questo dialogo breve, il campo Via è una posizione iniziale ragionevole. Dialoghi lunghi o con conseguenze importanti possono richiederne un’altra. Il modello WAI spiega queste differenze.
Azione | Risultato atteso nell’esempio |
|---|---|
Raggiungere il controllo con Tab, poi Invio | Il dialogo si apre; il focus è visibile nel campo Via. |
Avanzare con Tab | Via, numero civico, Annulla, Salva indirizzo; poi di nuovo Via. |
Tornare indietro con Shift+Tab | Gli stessi controlli in ordine inverso; nessun passaggio dietro il dialogo. |
Inserire 10, poi Escape prima di salvare | Il dialogo si chiude; il focus torna al controllo iniziale; D-17 resta Hafenweg 8. |
Riaprire e salvare 10 | Il successo appare dopo la conferma del salvataggio; D-17 mostra Hafenweg 10. |
Salvataggio rifiutato dalle regole operative | Errore comprensibile; dati inseriti conservati; area interessata raggiungibile. |
Questo ordine di tabulazione vale per lo specifico esempio. La Sua interfaccia può includere altri controlli.
Correggere la causa nel punto giusto
Usi veri pulsanti per le azioni e campi correttamente etichettati. Un dialogo personalizzato richiede un nome accessibile e una gestione corretta del focus. role="dialog" o aria-modal="true" da soli non bloccano lo sfondo né implementano l’interazione da tastiera.
Lo sviluppo deve considerare insieme apertura, mantenimento del focus nel dialogo modale attivo e chiusura. Qui il controllo iniziale esiste ancora alla chiusura. Se un altro flusso lo rimuove, serve un diverso punto di ritorno logico. Gli stili non devono eliminare l’indicatore visibile del focus.
Verificare la chiusura durante il salvataggio
Escape non ritira automaticamente una richiesta già inviata al server. In questo esempio la finestra può chiudersi anche durante l’elaborazione. La pagina continua a mostrare «Modifica dell’indirizzo in elaborazione» per D-17. Una risposta confermata aggiorna l’indirizzo; un esito incerto resta da chiarire. «Modifica scartata» sarebbe scorretto in tale situazione.
Ripeta il test corretto nei browser supportati e con una configurazione adeguata del lettore di schermo. Registri osservazioni ed errori aperti. Il percorso da tastiera corretto non dimostra ancora lo stato delle altre pagine, dei contrasti o dei contenuti.
Fonti
Continuate a leggere
Tutti gli articoli
Design & UX con ASES
Esperienza utente, interfacce e immagine del marchio