Integrare i test automatici di accessibilità con compiti reali

Un test automatico di accessibilità può evidenziare problemi ricorrenti ed essere ripetuto dopo le modifiche. Il suo risultato riguarda però le regole, le pagine e gli stati esaminati. L’affermazione «nessun errore segnalato» richiede questo ambito per consentire una decisione utile.

Passare dal rapporto a un’attività concreta

Consideriamo una panoramica di progetti fittizia. Supponiamo che una scansione non segnali errori nello stato iniziale. Un cliente deve ora selezionare un progetto e scaricare il disegno approvato. Il piano di verifica manuale di questa attività prevede quanto segue:

La tabella è un incarico di verifica, non un rapporto su test già eseguiti. A seconda dello strumento, i controlli automatici possono supportarne alcune parti. Un rapporto iniziale senza problemi non consente, da solo, di dedurre se l’intera attività possa essere completata in modo comprensibile.

Unire riscontri automatici e manuali

W3C WAI spiega che alcuni controlli di accessibilità non possono essere automatizzati e che gli strumenti possono produrre risultati inesatti. Anche i problemi segnalati devono quindi essere valutati nel contesto specifico. Per l’uso della tastiera, il W3C descrive inoltre la necessità di poter uscire da un’area raggiungibile; eventuali modalità particolari di uscita devono essere comprensibili.

Rendere tracciabile il prossimo test

Registri insieme strumento e configurazione, stati di pagina esaminati, attività manuale e risultato osservato. Dopo una correzione, i passaggi interessati vengono verificati nuovamente. Resta così chiaro che cosa è stato esaminato e che cosa rimane aperto. Una singola scansione o una singola attività manuale non forniscono ancora una valutazione completa dell’accessibilità del prodotto.

Fonti

• W3C WAI: Evaluation Tools Overview

• W3C: Understanding No Keyboard Trap