Sei lacune WCAG 2.2 AA da colmare: checklist per sviluppatori con test e soluzioni

WCAG 2.2 è l'attuale W3C Recommendation e la conformità di livello AA significa soddisfare tutti i criteri di successo di livello A e AA, compresi sei dei nove appena introdotti (2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 e 3.3.8). Parti da una scansione automatica per eliminare i problemi noti di livello A e AA, poi esegui test manuali sui nuovi criteri comportamentali, dato che la maggior parte non può essere rilevata da un crawler.

---

In breve:

• Sei dei nove nuovi criteri WCAG 2.2 sono obbligatori per la conformità di livello AA e riguardano visibilità del focus, alternative al trascinamento, dimensione dei bersagli, posizione dell'aiuto, autenticazione e inserimento ridondante.

• Gli strumenti automatici coprono più della metà dei problemi WCAG 2.1 esistenti, ma i test manuali sono indispensabili per i criteri comportamentali come la chiarezza del focus e l'accessibilità del trascinamento.

• Eseguire i test significa combinare rapide scansioni automatiche per i problemi strutturali e verifiche manuali con tastiera, screen reader e controllo visivo su un campione di pagine, seguendo una metodologia definita.

• Passare da WCAG 2.1 a 2.2 richiede soprattutto di affrontare sei nuovi criteri AA, più tre standard AAA facoltativi: per i siti già conformi la transizione è quindi gestibile.

• Documentare con precisione ambito, metodologia di test e pagine campione è fondamentale per le dichiarazioni contrattuali e di conformità, soprattutto quando si cita la versione e il livello WCAG esatti.

---

Cosa c'è davvero di nuovo nella checklist WCAG 2.2?

WCAG 2.2 non sostituisce WCAG 2.1: ci si appoggia sopra. Tutti i criteri di successo della 2.1 restano invariati, tranne uno che è stato eliminato del tutto (ne parliamo più avanti), e la nuova versione aggiunge nove criteri di successo. A seconda di come si contano i criteri raggruppati, il totale arriva a 86 o 87 criteri di successo fra i livelli A, AA e AAA.

Le nove aggiunte non sono casuali. Riguardano tre gruppi che i team di accessibilità hanno storicamente trascurato: le persone con difficoltà motorie che faticano con bersagli piccoli e gesti di trascinamento, le persone con disabilità cognitive che perdono il filo di dove si trovano in un processo a più passaggi e le persone ipovedenti che hanno bisogno di una navigazione coerente e prevedibile. Se il tuo ultimo audit era costruito sulla WCAG 2.1, questa è la lacuna che stai colmando.

Ecco la suddivisione che conta di più per il lavoro di conformità:

• Sei nuovi criteri sono di livello A o AA e sono obbligatori per la conformità AA: Focus Not Obscured (Minimum) 2.4.11, Dragging Movements 2.5.7, Target Size (Minimum) 2.5.8, Consistent Help 3.2.6, Accessible Authentication (Minimum) 3.3.7 e Redundant Entry 3.3.8.

• Tre sono solo di livello AAA, quindi sono buone pratiche ma non richiesti per la normale conformità AA: Focus Not Obscured (Enhanced) 2.4.12, Focus Appearance 2.4.13 e Accessible Authentication (Enhanced) 3.3.9.

• Un criterio più vecchio è stato eliminato: il 4.1.1 Parsing non si applica più, perché i browser moderni gestiscono il markup malformato in modo tale da rendere obsoleto il test originale.

Se stai preparando una checklist per un cliente o per un audit interno, la conclusione pratica è questa: non dare lo stesso peso a tutti e nove i nuovi punti. Sei decidono se superi il livello AA. Gli altri tre sono un obiettivo aggiuntivo.

I nove nuovi criteri di successo WCAG 2.2, un test per ciascuno

Questa è la checklist operativa. Ogni voce ha un test rapido che puoi eseguire da solo, più la soluzione che di solito risolve il problema. Sei sono obbligatori per il livello AA, tre sono AAA e segnalati come tali.

1. 2.4.11 Focus Not Obscured (Minimum), AA. Test: percorri con il tasto Tab tutti gli elementi interattivi della pagina e verifica se un'intestazione fissa, un banner sui cookie o un widget di chat copre mai completamente l'elemento con il focus. Soluzione: aggiungi scroll-margin-top o scroll-padding-top nel CSS, così gli elementi con il focus scorrono al di fuori delle intestazioni fisse, e imposta uno z-index più basso o chiudi le sovrapposizioni quando arriva il focus.

2. 2.5.7 Dragging Movements, AA. Test: individua ogni funzione che dipende dal trascinamento (cursori, riordino con trascina e rilascia, spostamento delle mappe) e verifica che funzioni anche con un solo clic o tocco. Soluzione: aggiungi pulsanti espliciti su/giù o sinistra/destra accanto ai cursori, oppure un menu "sposta in posizione" come alternativa al riordino con trascinamento.

3. 2.5.8 Target Size (Minimum), AA. Test: misura i bersagli cliccabili che non sono link testuali in linea. Tutto ciò che sta sotto i 24 per 24 pixel CSS non passa, a meno che non abbia spazio sufficiente dai bersagli vicini o un'area cliccabile invisibile di dimensioni equivalenti. Soluzione: aggiungi spazio interno ai piccoli pulsanti icona via CSS (padding oppure min-width/min-height più grandi) invece di rimpicciolire l'icona visibile.

4. 3.2.6 Consistent Help, AA. Test: se un meccanismo di aiuto (link alla chat, contatti, pagina di assistenza) è presente su più di una pagina, verifica che compaia nella stessa posizione relativa nell'ordine di navigazione su tutte. Soluzione: inserisci i link di aiuto in un componente condiviso di intestazione o piè di pagina invece di collocarli a mano pagina per pagina.

5. 3.3.7 Accessible Authentication (Minimum), AA. Test: prova ad accedere usando solo un gestore di password e il riempimento automatico del browser. Se il modulo blocca l'incolla, rimuove gli attributi autocomplete o impone un enigma manuale in stile CAPTCHA senza alternative, non passa. Soluzione: mantieni intatti autocomplete="current-password" e attributi simili, consenti di incollare nei campi password e offri almeno un metodo di autenticazione che non richieda di risolvere un enigma cognitivo.

6. 3.3.8 Redundant Entry, AA. Test: percorri un qualsiasi modulo a più passaggi e controlla se le informazioni già inserite (nome, indirizzo, e-mail) vengono richieste di nuovo senza essere precompilate. Soluzione: trasporta i dati del modulo fra i vari passaggi nello stato o nella memoria di sessione e compila automaticamente i campi ripetuti.

7. 2.4.12 Focus Appearance, AAA. Test: verifica che l'indicatore di focus abbia contrasto e dimensione sufficienti rispetto allo sfondo in ogni componente. Soluzione: usa un contorno visibile di almeno 2 pixel CSS di spessore, con un forte contrasto rispetto ai colori adiacenti.

8. 2.4.13 Focus Not Obscured (Enhanced), AAA. Test: come il 2.4.11, ma più severo: nessuna parte dell'elemento con il focus può essere nascosta, nemmeno parzialmente. Soluzione: la stessa del 2.4.11, applicata con maggiore rigore.

9. 3.3.9 Accessible Authentication (Enhanced), AAA. Test: verifica che l'accesso non richieda mai di ricordare, trascrivere o richiamare manualmente delle informazioni (nessun passaggio del tipo "digita i caratteri che hai memorizzato"). Soluzione: affidati interamente a un'autenticazione compatibile con incolla e riempimento automatico, senza alcun passaggio di richiamo mnemonico.

Consiglio pratico: Target Size (2.5.8) mette in difficoltà più team di qualsiasi altro nuovo criterio, perché i design system costruiti anni fa usavano spesso pulsanti icona da 20 px come standard. Esegui uno script rapido che misuri ogni button, a e div cliccabile del tuo sito rispetto alla soglia dei 24 px prima ancora di iniziare la revisione manuale. Ti fa risparmiare ore.

Sistemare la checklist ereditata prima di dichiarare la conformità

Prima ancora di pensare ai nove nuovi criteri, devi avere l'arretrato WCAG 2.1 in ordine. Questa è la parte della WCAG 2.2 checklist che gli strumenti automatici gestiscono bene, ed è la parte che frega i team convinti che una scansione verde significhi lavoro finito.

Gli scanner automatici sono affidabili per una categoria precisa di problemi: attributi alt mancanti, campi di modulo senza etichetta, associazioni mancanti fra etichetta e campo, contrasto cromatico insufficiente sul testo statico, attributi di lingua del documento mancanti e ID duplicati. Esegui prima uno scanner su tutto il sito e di solito in un pomeriggio elimini dal 50 al 70 percento del totale dei problemi.

Quello che l'automazione si perde sistematicamente è tutto ciò che richiede giudizio. Il testo alternativo descrive davvero l'immagine o esiste e basta? L'ordine di tabulazione corrisponde all'ordine di lettura visivo o salta qua e là in un modo che solo una persona noterebbe? La struttura delle intestazioni è logica o passa da un H2 direttamente a un H4 perché uno sviluppatore ha scelto le dimensioni dei caratteri invece dei livelli semantici? Qui serve una persona che naviga con tastiera e screen reader.

Gli strumenti automatici intercettano una quota significativa dei problemi in termini di quantità, ma la maggior parte delle aggiunte della WCAG 2.2 richiede verifica manuale proprio perché testa il comportamento, non il markup. Uno scanner può dirti che un pulsante esiste. Non può dirti se il trascinamento è l'unico modo per usarlo.

Per stabilire le priorità, procedi in questo ordine:

• Prima i blocchi: tutto ciò che impedisce completamente di portare a termine un'operazione, come un campo obbligatorio senza etichetta o una trappola da tastiera.

• Poi le pagine ad alto traffico: la homepage, il processo di acquisto e i percorsi di conversione principali contano più di una pagina d'archivio quasi mai visitata.

• Poi i problemi di contrasto ed etichettatura, in blocco: di solito sono sistemici (una variabile CSS sbagliata, un modello di componente), quindi una sola correzione risolve decine di casi.

• Lascia per ultimi i miglioramenti estetici AAA: l'aspetto avanzato del focus e voci AAA simili vale la pena farli, ma non a scapito dei blocchi di livello AA.

Un tipico arretrato di correzioni dopo un primo passaggio è fatto così: 40 attributi alt mancanti, 12 campi senza etichetta, 8 casi di testo a basso contrasto, 3 trappole da tastiera e qualche violazione nell'ordine delle intestazioni. Niente di tutto ciò è una novità della WCAG 2.2. È semplicemente la base che devi mettere in ordine prima che valga la pena testare i nove nuovi criteri.

Quale flusso di test funziona davvero per la WCAG 2.2?

Prima l'automazione, poi i test manuali, sempre in quest'ordine. Invertirlo fa sprecare ore su problemi che uno scanner avrebbe intercettato in pochi secondi.

1. Passaggio automatico. Esegui uno scanner come axe-core su ogni modello e tipo di pagina (non su ogni singola pagina, i modelli si ripetono). Così risolvi in fretta testi alternativi, etichette e contrasti e ottieni un conteggio di base dei problemi.

2. Passaggio manuale con una piccola cassetta degli attrezzi. Una tastiera, gli strumenti di sviluppo del browser, un selettore di contrasto, un gestore di password e uno screen reader coprono quasi tutto ciò che l'automazione si perde. Percorri con il Tab ogni flusso interattivo. Verifica la visibilità del focus rispetto alle intestazioni fisse. Testa le interazioni di trascinamento usando solo la tastiera. Prova ad accedere con riempimento automatico e incolla.

3. Audit del sito su campione con WCAG-EM. Per un sito intero, non testare ogni pagina. Il metodo in cinque passaggi di WCAG-EM definisce l'ambito, esplora la struttura del sito, seleziona un campione rappresentativo (modelli, moduli, pagine ad alto traffico e casi limite come gli stati di errore), verifica quel campione con controlli automatici e manuali e riporta i risultati rispetto a criteri di successo specifici, con esito positivo/negativo e prove a supporto.

La tua cassetta degli attrezzi non deve essere costosa né esotica:

• L'ispettore di accessibilità integrato nel browser (Chrome DevTools, pannello Accessibilità di Firefox) per l'ordine del focus e gli attributi ARIA.

• Un verificatore di contrasto per i controlli di visibilità del focus 2.4.11 e 2.4.13.

• Lo screen reader del tuo sistema operativo (VoiceOver, NVDA) invece di affidarti solo ai risultati automatici.

• Un gestore di password, dato che il 3.3.7 riguarda proprio il funzionamento effettivo di riempimento automatico e incolla.

Il rapporto che produci dovrebbe indicare quali pagine o modelli sono stati campionati, quali criteri di successo sono stati testati, l'esito positivo/negativo per ogni criterio e prove sufficienti (una schermata, un URL specifico, i passaggi per riprodurre il problema) perché un altro tester possa verificare quanto hai rilevato senza rifare l'intero audit.

In pratica, cosa cambia fra WCAG 2.2 e WCAG 2.1?

Se il tuo sito è già conforme a WCAG 2.1 AA, il salto alla 2.2 è più piccolo di quanto sembri. Ecco cosa cambia davvero per i team che fanno questo aggiornamento:

• Il 4.1.1 Parsing non c'è più. Richiedeva un markup valido e ben formato perché le tecnologie assistive potessero interpretarlo correttamente. I browser e le tecnologie assistive moderne gestiscono l'HTML malformato in modo abbastanza coerente da rendere il criterio superfluo, quindi è stato ritirato invece di essere mantenuto.

• Si applicano sei nuovi criteri AA, che sono quelli trattati nella checklist qui sopra: visibilità del focus, alternative al trascinamento, dimensione dei bersagli, posizione coerente dell'aiuto, autenticazione accessibile e inserimento ridondante.

• Esistono tre nuovi criteri AAA, ma non sono richiesti per le normali dichiarazioni di conformità AA, a meno che il contratto o il contesto normativo non richieda espressamente il livello AAA.

Per un team già al livello 2.1 AA, l'ambito di lavoro realistico è un progetto mirato sui sei nuovi criteri AA, non un nuovo audit completo. Pianifica il budget di conseguenza e verifica se il tuo contratto o il tuo obbligo normativo citi espressamente la 2.1 o la 2.2, perché le esenzioni e l'ambito richiesto cambiano leggermente fra le due versioni.

Come citare la WCAG 2.2 nei contratti e nei documenti di conformità

Una formula vaga come "rispetta le WCAG" è un rischio, non una dichiarazione di conformità. Le indicazioni del W3C su come citare la WCAG 2.2 raccomandano di indicare il livello di conformità esatto: "livello AA" significa tutti i criteri di successo di livello A e tutti quelli di livello AA, senza eccezioni e senza mezze misure. I documenti sulle tecniche sono informativi, non normativi: non citare una tecnica come se fosse un requisito.

Per le organizzazioni svizzere, lo standard di riferimento per il settore pubblico, eCH-0059, indica attualmente WCAG 2.1 livello AA come base obbligatoria per i siti dell'Amministrazione federale. Significa che oggi un sito federale svizzero non è tenuto per legge a rispettare la WCAG 2.2. Gli addetti ai lavori consigliano comunque di sviluppare secondo la 2.2, perché lo standard tende a muoversi in quella direzione e adeguarsi più tardi costa più che farlo subito.

Quando scrivi i requisiti in un contratto o in un bando, alcune abitudini ti evitano contenziosi:

• Indica la versione e il livello esatti ("WCAG 2.2 livello AA"), mai soltanto "conforme alle WCAG" o "accessibile".

• Elenca le pagine, i modelli o i percorsi utente specifici coperti dalla dichiarazione di conformità, perché dichiarare la conformità dell'intero sito senza definire l'ambito è inapplicabile.

• Precisa se i criteri AAA rientrano nell'ambito o se sono esplicitamente esclusi.

• Cita la metodologia di test usata (strumento automatico, passaggio manuale, dimensione del campione), così la dichiarazione è verificabile in seguito.

Documenta allo stesso modo l'ambito e le pagine campione del tuo audit: se una dichiarazione viene contestata, dietro c'è una traccia difendibile e non una frase di marketing.

Chi c'è dietro questa checklist?

Questa guida è stata scritta da Davide Morotti, sulla base del lavoro pratico di adeguamento all'accessibilità svolto su progetti per clienti in uno studio di sviluppo software di Zurigo che realizza siti web, applicazioni e piattaforme sia per startup sia per team consolidati.

Alcuni punti utili se stai decidendo se fidarti di questa checklist o affidare il lavoro a qualcun altro:

• Lo studio ha realizzato progetti attenti all'accessibilità per clienti come Arthouse Kinos, il gruppo di cinema di Zurigo, dove i percorsi di acquisto dei biglietti a più passaggi dovevano reggere i test con tastiera e screen reader.

• Il lavoro su Repa Immobiliare ha riguardato un software su misura, in parte funzionante offline: un contesto in cui la sola scansione automatica non basta e i test manuali sui casi limite contano di più.

• Hanno inoltre costruito e mantenuto sistemi di grandi dimensioni per Die Mitte, con oltre 600 siti web di un partito politico svizzero gestiti da un'unica piattaforma, e annoverano fra i clienti UBS e la Città di Lugano.

• I progetti sono seguiti dall'inizio alla fine da ingegneri senior, dalla prima consulenza alla consegna: questo aiuta a evitare che i requisiti di accessibilità si perdano fra la consegna del design e la realizzazione.

Come Ampersand Labs affronta l'adeguamento alla WCAG 2.2

Applicare questa checklist da solo è del tutto fattibile se hai tempo e uno sviluppatore che se ne può occupare. Se preferisci affidarla a chi l'ha già fatto, alcuni studi conducono audit in stile WCAG-EM che producono un rapporto con ambito e campione definiti e un elenco di interventi ordinati per priorità, non solo un'esportazione grezza dello scanner che devi interpretare da solo.

Un incarico tipico comincia con la definizione dell'ambito (quali pagine, quali percorsi, quale livello di conformità), il campionamento di modelli rappresentativi, l'esecuzione dei passaggi automatici e manuali descritti sopra e la consegna di un rapporto ordinato per impatto, invece di un elenco piatto di centinaia di problemi. Quando i progetti hanno una guida tecnica senior dalla prima chiamata alla consegna, le correzioni vengono implementate bene al primo colpo, senza rimbalzare fra l'intenzione del designer e l'interpretazione dello sviluppatore: un punto critico frequente quando il lavoro sull'accessibilità viene gestito a pezzi.

Se l'adeguamento comporta la ricostruzione dei componenti invece di rattopparli, quel lavoro rientra nei servizi di sviluppo di Ampersand Labs. Per i team che vogliono solo chiarezza sui costi prima di decidere, le tariffe attuali e le modalità di collaborazione sono indicate nella pagina dei prezzi di Ampersand Labs. Se la tua lacuna di accessibilità è in realtà il sintomo di un problema più ampio legato a una base di codice datata, vale la pena parlarne prima di spendere un budget per rattoppare un sistema che comunque andrebbe sostituito.

Fonti

Per il testo normativo vero e proprio, leggi direttamente la W3C WCAG 2.2 Recommendation invece di affidarti a riassunti di seconda mano, perché nei casi limite tecniche ed eccezioni fanno la differenza. Il documento ACT Rules Format spiega come le implementazioni dei test automatici vengono validate rispetto allo standard: utile se stai valutando se i risultati del tuo scanner sono affidabili. Per strutturare l'audit di un sito intero, WCAG-EM 1.0 è la metodologia che gli auditor citano quando un cliente chiede come è stato scelto il campione. E per una guida pratica ai test criterio per criterio, costruita proprio sulle nove nuove aggiunte, la guida ai test di wcag22aa.org è il complemento più diretto alla checklist qui sopra.

Per i team che vogliono capire se il proprio sito sia almeno scansionabile prima di affrontare un lavoro più approfondito sull'accessibilità, uno strumento come l'BabyLoveGrowth’s crawlability audit può segnalare problemi di accesso di base da escludere subito.

• W3C Recommendation

• WCAG 2.2 checklist

Domande frequenti

Cosa sono gli standard WCAG 2.2?

WCAG 2.2 è la W3C Recommendation che definisce i criteri di successo per l'accessibilità web su tre livelli: A, AA e AAA. Mantiene tutti i criteri della WCAG 2.1 tranne il 4.1.1 Parsing, che è stato eliminato, e aggiunge nove nuovi criteri rivolti alle esigenze motorie, cognitive e di chi ha una vista ridotta.

La WCAG 2.2 è obbligatoria?

La WCAG 2.2 di per sé non è una legge, è uno standard tecnico a cui leggi e regolamenti fanno riferimento. In Svizzera, lo standard federale per il settore pubblico eCH-0059 cita attualmente WCAG 2.1 livello AA come base di riferimento, non la 2.2, anche se adottare già ora la 2.2 è ampiamente consigliato per non dover rifare il lavoro di conformità in futuro.

Che cos'è una verifica WCAG?

Una verifica WCAG è un test rispetto a uno specifico criterio di successo per stabilire se è soddisfatto o meno, condotto con scansioni automatiche per i problemi strutturali (etichette mancanti, rapporti di contrasto) e test manuali per i problemi di comportamento (usabilità da tastiera, visibilità del focus, alternative al trascinamento). Una verifica completa segue di solito la metodologia WCAG-EM: definire l'ambito, campionare le pagine, condurre l'audit e riportare i risultati.

Quali sono i nuovi standard WCAG introdotti nella versione 2.2?

La WCAG 2.2 ha aggiunto nove criteri di successo, sei dei quali sono obbligatori per la conformità di livello AA: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), Consistent Help, Accessible Authentication (Minimum) e Redundant Entry. Gli altri tre, Focus Not Obscured (Enhanced), Focus Appearance e Accessible Authentication (Enhanced), sono di livello AAA e facoltativi per la normale conformità AA.

Quanto dura di solito un audit WCAG 2.2?

Dipende dalle dimensioni del sito e da quanto dell'arretrato WCAG 2.1 è già stato sistemato, ma un audit mirato sui sei nuovi criteri AA, su un sito già conforme alla 2.1 AA, è in genere un progetto breve e circoscritto, non una ricostruzione completa. Un primo audit completo che combina scansione automatica, test manuali e un piano di campionamento WCAG-EM richiede più tempo e cresce con il numero di modelli distinti e di percorsi utente presenti sul sito.

Consigliati

• NeuroMynds: il sito di una fondatrice reso veloce, sicuro e pronto ad acquisire abbonati.

• Die Mitte: oltre 600 siti web di un partito politico svizzero gestiti da un solo sistema.

• Sviluppo di MVP, app web e mobile a Zurigo