Come dare priorità agli errori WCAG: matrice e backlog

Un errore di livello A è sempre più urgente di uno AA?

Quando si riceve un report di un audit di accessibilità con una serie di problemi aperti, la prima cosa che ci si chiede è: "Da dove si inizia?". Soprattutto all’inizio si tende a credere che tutti gli errori di livello A debbano essere risolti prima di vedere gli altri criteri di livello AA.

In realtà è molto più complesso di così. Nelle linee guida del W3C infatti, i requisiti di conformità vengono classificati in 3 livelli (A, AA e AAA), ma questi non quantificano l’impatto dell’utente o l’importanza dei criteri, dal momento che sono tutti importanti e necessari per avere un sito perfettamente accessibile e che non violi le norme.

Le linee guida internazionali della WCAG si basano sui quattro principi cardine dell’accessibilità (per approfondire leggi la guida pratica ai 4 principi POUR) che determinano lo standard di ogni interfaccia.
Se un principio viene violato, l’ostacolo all’accessibilità conseguente può manifestarsi in modi diversi:v

• come blocco: la persona che usa tecnologie assistive o naviga da tastiera non ha modo di completare l’operazione o di proseguire nella navigazione; degli esempi sono le violazioni che impediscono fisicamente o programmaticamente l’interazione, come un pulsante "Paga ora" con scarso contrasto (testo grigio chiaro su sfondo bianco) che viola il criterio 1.4.3 di livello AA. Pur non essendo di livello A, impedisce l'acquisto a chi ha un deficit visivo, bloccando sia l'utente sia il business.
• come disagio o attrito: il percorso presenta rallentamenti, ambiguità o affaticamento ma comunque il task principale si riesce a completare; è il caso per esempio di una nota informativa in calce a un articolo avente un markup semantico imperfetto o un attributo ridondante (quindi una violazione di un criterio di livello A): può creare un lieve disagio all’utente, un senso di disorientamento durante la navigazione, ma non lo impedisce nel completare le azioni essenziali del servizio.

La priorità sta quindi sul piano operativo ed è legata all’esperienza reale degli utenti (usabilità) e alla severità d’uso, ossia l’effetto concreto dell’errore sull’attività dell’utente.

Agire secondo questo falso mito che porta a credere che il livello A batta sempre il livello AA porterebbe a concentrare tempo e risorse su dettagli marginali, lasciando inalterati blocchi sul checkout, sui form di login o sui flussi di conversione. La conformità formale serve a tracciare il traguardo, ma per pianificare gli sprint quotidiani è indispensabile valutare l’impatto reale di ogni difetto sul percorso utente.

4 fattori da valutare per distinguere un blocco da un disagio

Per capire oggettivamente l’urgenza di un intervento, il primo passo dovrebbe essere, come abbiamo già visto, definire l’entità di questo ostacolo e capire se si tratta di un blocco o di un senso di disagio provato dall’utente a causa di un attrito.
Solitamente la correzione di un problema di attrito viene programmata in fase di manutenzione, mentre un blocco totale e situato in un flusso core avrà la precedenza.

Per calcolare la priorità operativa e ordinare il backlog, non basta fermarsi all’impatto sul singolo elemento ma bisogna valutare anche altri fattori da considerare insieme:

1. Impatto sull'utente

Misura la gravità diretta della barriera sulle capacità di interazione:

• Nel caso di un blocco totale, se un pulsante non riceve il focus o se avviene un focus trap l’interazione si interrompe del tutto.
• Nel caso di attrito/disagio, l’informazione richiede più tempo o passaggi per essere decodificata ma non preclude il raggiungimento dell’obiettivo.

2. Criticità del task

Valuta l’importanza del contesto in cui si manifesta il problema:

• Un intoppo delle funzionalità core durante passaggi indispensabili come procedure di login, autenticazione o checkout blocca la conversione o l’accesso al servizio;
• Nelle sezioni informative o di consultazione occasionale un ostacolo compromette solo una porzione circoscritta di contenuto senza interrompere il flusso.

3. Frequenza di occorrenza

Indica quanto spesso si incontra durante il percorso utente:

• Se si tratta di un componente con cui l’utente interagisce continuamente, allora l’effetto negativo si somma a ogni step.
• Se invece si tratta di un elemento isolato o secondario, si riduce l’esposizione al problema.

4. Ampiezza di diffusione

Misura la scala architetturale del problema:

• Se si trova in un componente presente in tutte le pagine come header, menù di navigazione e footer, avrà la precedenza su altri problemi;
• Se invece rimane circoscritto a una singola scheda prodotto o a una specifica tabella dati sarà più semplice da isolare e avrà un raggio di impatto ridotto.

Formula di priorità: come calcolare il punteggio di gravità

Il risultato di una valutazione di conformità è una tracciabilità strutturata di esiti positivi e di non conformità riscontrate nel campione analizzato. Il report registra i fallimenti rispetto ai criteri ma rimane comunque il dubbio sull’ordine con cui intervenire; per non rischiare di basarsi su considerazioni soggettive e arbitrarie, l’ideale è definire una formula precisa di priorità per assegnare alle criticità dei punteggi specifici:

Gravità = Impatto × Criticità × Frequenza

Per poter fare un calcolo immediato, si consiglia di adottare una scala da 1 a 3 per ogni variabile:

Il punteggio ottenuto andrà da un minimo di 1 a un massimo di 27 (3 × 3 × 3) e da esso si potrà classificare la barriera come:

• Priorità bassa (punteggio da 1 a 6): potrebbe trattarsi di rifiniture o di difetti isolati su dei task secondari o marginali.
• Priorità media/alta (punteggio da 8 a 16) per criticità su task primari o problemi significativi su flussi secondari.
• Priorità assoluta (punteggio da 18 a 27) come nel caso di blocchi di uso sui flussi chiave o sui componenti globali. Vanno inseriti d’ufficio nello sprint in corso.

Classi di priorità ed esempi pratici a confronto

Un tema che emerge nelle discussioni è legato a una realtà pratica: non tutti i bug possono essere presi in carico e risolti con lo stesso tempo. Per organizzare i fix ed evitare ritardi nei rilasci, il backlog necessita una suddivisione in classi di priorità ben definite.

Mettendo a confronto 4 scenari reali riferiti alle specifiche tecniche delle WCAG 2, si nota come sia agevole categorizzare i problemi per velocizzare il lavoro nel team e sapere con esattezza da cosa iniziare a lavorare.

Il moltiplicatore invisibile: gestire i bug nei componenti condivisi

Nel caso di funzionalità condivise e di componenti globali, bisogna prestare maggiore attenzione quando si applica la metodologia WCAG-EM di valutazione della conformità: Se in uno di questi componenti globali si dovesse riscontrare un problema, questo introduce un vero e proprio effetto a cascata. Ecco che in questo scenario:

• L’ampiezza di diffusione cambia il peso del bug: un errore apparentemente banale presente in una singola scheda prodotto isolata ha un’ampiezza di diffusione minima, ma se questo stesso difetto risiede nel menù di navigazione si moltiplica automaticamente su centinaia di URL.
• Impatto sul totale delle sessioni: i componenti condivisi rappresentano i percorsi di accesso obbligati dell’esperienza utente. Un problema tecnico collocato su un input field riutilizzabile o sulla barra di navigazione principale finisce per impattare potenzialmente il 100% delle sessioni di visita, trasformando un disagio marginale in un disservizio continuo ed esteso.

Questo moltiplicatore invisibile nasconde una grande opportunità operativa: intervenire alla radice su una funzionalità condivisa nel Design System permette di risolvere decine di schermate con un singolo fix centralizzato e garantisce inoltre un alto ritorno sull’investimento, proprio perché viene eliminato subito un volume enorme di non conformità dall’intero sito.

Matrice Priorità x Effort: dal quick win al debito tecnico

Per poter trasformare un report di valutazione strutturata in un piano di remediation sostenibile occorre, oltre al calcolo della gravità di un problema, è indispensabile valutare il costo tecnico della correzione (effort).
La seguente tabella illustra tutte le risorse tecniche necessarie da allocare con criterio:

Caso pratico: ordinare il backlog di un e-commerce in sprint da 4 settimane

La situazione tipica in cui si trova un product manager o un team di sviluppo dopo un audit di accessibilità è spesso disarmante poiché si ritrova una lista apparentemente ingestibile di problemi da risolvere, senza un ordine chiaro da cui partire. Dunque, affrontare queste violazioni in ordine sparso o procedere per elenco numerico generebbe frustrazione e rallenterebbe il lavoro. La soluzione consiste quindi nell’applicare la logica dei principi di accessibilità W3C alle azioni di business, risolvendo prima le barriere che bloccano i task primari e solo dopo passando a quelle legate ai contenuti secondari.

Supponendo di avere 18 problemi tipici di un e-commerce da distribuire in 2 sprint di lavoro da 4 settimane ciascuno, la struttura verosimilmente potrebbe essere la seguente:

Suddividere il backlog con questa logica fa sì che ogni rilascio produca effetti concreti e positivi sia per gli utenti che usano tecnologie assistive, sia per gli obiettivi di vendita dell’e-commerce.

Come documentare roadmap, owner e re-test

Senza un metodo rigoroso di documentazione, le correzioni rischiano di perdersi nei backlog ordinari o di essere considerate “risolte” senza essere realmente verificate. Dunque, ispirandosi al modello del W3C per la valutazione e la rendicontazione, è sempre bene registrare ogni non conformità individuata in un registro delle correzioni ben strutturato, in cui ogni voce dovrebbe contenere informazioni su ID e criterio WCAG associato, gravità operativa, scadenza prevista del rilascio che dovrebbe correggere l’errore e informazioni su chi se ne occupa e sulla nuova verifica dell’errore.

"Da non confondere: priorità operativa non significa conformità legale!
Quando si organizza la roadmap e si classifica un errore di bassa priorità o come debito tecnico temporaneo, non bisogna ignorarlo o dichiarare una piena conformità quando in realtà non c’è, perchè altrimenti viene a meno la conformità di un determinato livello: tutti i criteri di successo devono essere interamente soddisfatti per poter dichiarare un’effettiva conformità. Posticipare un errore a basso impatto permette di concentrarsi su errori più bloccanti, ma finchè anche quell’errore non viene risolto, il sito non è conforme dal punto di vista formale."

Inizia oggi: verifica la conformità del tuo sito

FAQ — Domande frequenti