Stima dei tempi necessari per una correzione relativa all'accessibilità
Come valutare la portata di una correzione relativa all’accessibilità: i problemi di accessibilità (a11y) sono funzionalità che non sono state incluse nella versione iniziale. Perché è importante valutare la portata del problema nel suo complesso, anziché un singolo caso.
Le correzioni relative all’accessibilità non sono bug. Sono funzionalità che il team non aveva incluso nella versione iniziale.
Considerare un problema di accessibilità come un bug — «correggere la finestra modale in modo che mantenga il focus» — limita la portata della soluzione. Non tiene conto di ciò da cui dipende tale soluzione: il resto della navigazione da tastiera, le indicazioni fornite dallo screen reader, il contrasto cromatico che probabilmente presenta lo stesso problema anche nella finestra modale successiva. La maggior parte delle «piccole correzioni di accessibilità» costituisce un punto di accesso a una categoria di problemi che attraversa l’intero componente.
La stima realistica riguarda la classe, non l’istanza. Se si implementa una correzione, ci si ritroverà a dover tornare nello sprint successivo per la classe affine, e poi per quella successiva, finché qualcuno non ammetterà che il lavoro consiste nel “verificare il modello di interazione modale” e non ne valuterà l’entità di conseguenza.
Ciò che viene detto nella stanza
Frontend: “L’implementazione della ‘focus trap’ richiede mezza giornata.”
Domanda: “Il pulsante ‘Chiudi’ viene annunciato dagli screen reader?”
Progettista: «Il contrasto sul pulsante secondario è adeguato?»
Introduzione: “Quanti altri verbi modali hanno la stessa forma?”
PM: «Li controlliamo tutti o solo quello di cui si sono lamentati i clienti?»
Domande che vale la pena porsi prima di votare
- Si tratta di un’istanza o di una classe? Quanti componenti simili esistono?
- Ambito della verifica: questo componente, questa pagina, questo prodotto?
- Livello di conformità alle WCAG: A, AA, AAA?
- Test: axe, screen reader manuale, procedura guidata solo da tastiera?
- Prevenzione delle regressioni: regola Lint, snapshot dello story, controllo CI?
- Qual è il budget previsto per le attività di accessibilità una volta che questo progetto sarà stato completato?
Se si tratta di una classe anziché di un’istanza, separi split la componente con cui i clienti interagiscono dal resto — e valuti ciascuna di esse in base a quanto si sta effettivamente impegnando a fornire.
Definite la dimensione della classe, non dell’istanza. Una “trappola di attenzione” dura mezza giornata; il modello che ne sta alla base è la storia.
Come nel caso della stima di una modifica al sistema di progettazione, la correzione a monte è minima e il lavoro effettivo consiste nella copertura a valle. Si consultino gli altri esempi di stime già effettuati, oppure si avvii una sessione gratuita di Planning Poker una volta concordato l’ambito di intervento.