Stima dei tempi necessari per una correzione relativa all’accessibilità

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 il problema: il resto della navigazione da tastiera, gli annunci dello 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 ingresso in 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 occuparsi della classe affine, e poi di quella successiva, fino a quando 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 sala

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 da porsi prima di votare

• Si tratta di un’istanza o di una classe? Quanti componenti simili esistono?
• Ambito della verifica: questa componente, questa pagina, questo prodotto?
• Obiettivo WCAG: A, AA, AAA?
• Test: axe, screen reader manuale, procedura passo passo solo con la 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 controllo del resto e valuti ciascuna di esse in base a quanto si sta effettivamente impegnando a garantire.

Definite la classe, non l’istanza. Una trappola cognitiva è “mezza giornata”; il modello che 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à elaborate, oppure si avvii una sessione gratuita di Planning Poker una volta concordato l’ambito di intervento.