Se oggi state pianificando audit, remediation o adeguamenti normativi, il confronto wcag 2.1 vs wcag 2.2 non è una discussione teorica. Incide su backlog, priorità di sviluppo, qualità dell’esperienza utente e capacità di dimostrare una conformità credibile. Per chi gestisce siti, e-commerce o servizi digitali, capire la differenza significa evitare interventi parziali proprio mentre l’accessibilità entra sempre più nel perimetro del rischio aziendale.
WCAG 2.1 vs WCAG 2.2: la differenza essenziale
La prima cosa da chiarire è semplice: WCAG 2.2 non sostituisce la logica di WCAG 2.1, la estende. La struttura resta la stessa, così come i principi POUR – percepibile, utilizzabile, comprensibile e robusto – ma il set di criteri viene aggiornato per coprire meglio casi d’uso che nella pratica generavano ancora ostacoli, soprattutto per persone con disabilità cognitive, motorie e per chi naviga da mobile o solo da tastiera.
Per un decisore, questo ha un impatto diretto. Se un sito è stato progettato con attenzione seria ai requisiti WCAG 2.1 AA, il salto a 2.2 non parte da zero. Se invece la conformità era solo dichiarata o limitata a correzioni superficiali, WCAG 2.2 tende a far emergere le lacune più rapidamente.
In altre parole, non è un cambio di paradigma. È un test di maturità.
Cosa aggiunge WCAG 2.2
WCAG 2.2 introduce nuovi criteri di successo e rimuove un criterio della versione precedente. Il cuore del cambiamento riguarda l’interazione: focus visibile, target cliccabili, alternative ai gesti trascinati, aiuto nei processi di autenticazione e riduzione degli errori in flussi complessi.
Questo aggiornamento nasce da un punto molto concreto: molti servizi digitali risultavano formalmente migliorati con WCAG 2.1, ma continuavano a creare frizione reale in passaggi chiave come login, checkout, compilazione moduli, selezione di elementi interattivi e navigazione da tastiera.
Per chi vende online o offre servizi al pubblico, è qui che l’accessibilità smette di essere un adempimento astratto. Un focus poco visibile o un’area cliccabile troppo piccola non sono solo problemi tecnici. Possono diventare abbandoni, reclami, perdita di conversioni e contestazioni.
I nuovi criteri che meritano attenzione
Focus non oscurato e più riconoscibile
Una parte importante di WCAG 2.2 rafforza il tema del focus. Chi naviga da tastiera deve poter capire sempre dove si trova. Non basta che il focus esista nel codice: deve essere visibile, non coperto da header sticky, popup o componenti flottanti, e sufficientemente evidente da guidare la navigazione.
Questo punto sembra minore finché non si osserva un’interfaccia reale. Menu mobili, barre promozionali, cookie banner e modali spesso coprono proprio l’elemento attivo. Il risultato è un’esperienza interrotta per chi non usa il mouse.
Per i team design e frontend il messaggio è netto: il focus non è una rifinitura. È parte dell’architettura di interazione.
Target size minima
WCAG 2.2 introduce un criterio sulla dimensione minima dei target interattivi. Pulsanti, link e controlli devono avere un’area attivabile sufficiente per ridurre errori di selezione, soprattutto su mobile o per utenti con limitazioni motorie.
Qui emerge un classico trade-off. Interfacce dense, menu compatti e componenti molto raffinati visivamente possono sembrare efficienti, ma spesso sacrificano l’usabilità reale. L’adeguamento richiede talvolta di rivedere layout, spaziature e priorità visive. Non sempre è un fix rapido via CSS.
Dragging movements
Se un’azione dipende da un trascinamento, WCAG 2.2 chiede che esista un’alternativa semplice. Questo riguarda slider, ordinamenti, mappe, calendari, upload avanzati e varie interfacce moderne che presuppongono precisione motoria.
Il punto non è vietare il drag and drop. Il punto è non renderlo l’unico modo per completare un task. Per molte aziende è un dettaglio che passa inosservato fino al momento dell’audit.
Accessible authentication
L’autenticazione è uno dei passaggi più critici. WCAG 2.2 spinge a evitare che il login richieda test cognitivi non necessari, come ricordare, trascrivere o risolvere passaggi complessi senza supporti adeguati.
Questo è molto rilevante per aree riservate, banking, assicurazioni, e-commerce B2B e servizi con customer portal. Sicurezza e accessibilità qui devono convivere. Non si tratta di abbassare il livello di protezione, ma di progettare sistemi che non escludano utenti legittimi.
Il criterio rimosso: un falso problema
WCAG 2.2 rimuove il criterio 4.1.1 Parsing. Per alcuni questo può sembrare un alleggerimento, ma nella pratica non va letto come un via libera a markup disordinato o componenti mal implementati.
La ragione della rimozione è legata all’evoluzione dei browser e dei parser HTML, non al fatto che la qualità del codice non conti più. Se un’interfaccia rompe semantica, relazioni tra etichette e controlli, naming accessibile o comportamento di widget custom, i problemi restano eccome. Cambia il criterio, non la responsabilità progettuale.
WCAG 2.1 vs WCAG 2.2 nei progetti reali
Siti vetrina e corporate
Su siti editoriali o corporate, l’impatto di WCAG 2.2 si vede soprattutto nella navigazione da tastiera, nella gestione del focus, nei componenti sticky e nelle CTA. Se il sito usa template moderni con elementi sovrapposti, il rischio di focus nascosto è concreto.
In questi casi l’adeguamento può essere abbastanza lineare, ma dipende dalla qualità del tema e dalla libertà di intervenire sui componenti condivisi.
E-commerce
Negli e-commerce l’effetto è più operativo. Filtri, selettori variante, carrelli laterali, login, recupero password, coupon, checkout e micro-interazioni sono pieni di punti sensibili per WCAG 2.2.
Qui il tema non è solo conformità. È riduzione dell’attrito. Un checkout accessibile tende a essere anche più chiaro, più stabile e meno incline a errori. Questo ha un valore diretto su conversione e customer care.
Portali e servizi online
Quando il servizio digitale prevede autenticazione, moduli, documenti, prenotazioni o workflow multi-step, WCAG 2.2 diventa ancora più importante. I nuovi criteri aiutano a intercettare proprio quei blocchi che possono impedire il completamento di un’operazione essenziale.
Per enti, aziende regolamentate e fornitori che lavorano con la PA o con grandi organizzazioni, questo aspetto pesa anche in fase di procurement. La conformità non è più un allegato decorativo. Sempre più spesso è una condizione di affidabilità.
Serve adeguarsi subito?
Dipende dal vostro contesto, ma rimandare senza una valutazione seria è una scelta debole. Se oggi siete allineati a WCAG 2.1 AA, il passo successivo è verificare il delta reale verso 2.2 e classificare gli interventi per rischio, effort e impatto utente.
Se invece non avete mai fatto un audit strutturato, la domanda giusta non è se passare da 2.1 a 2.2. La domanda è se avete davvero visibilità sul vostro livello attuale di accessibilità.
Molte organizzazioni scoprono troppo tardi di avere una situazione frammentata: qualche fix automatico, una dichiarazione non aggiornata, componenti custom fuori controllo e nessun monitoraggio continuo. In quel quadro, discutere solo di versione dello standard è riduttivo. Prima serve governance.
Come affrontare il passaggio da WCAG 2.1 a WCAG 2.2
L’approccio più efficace non parte da una checklist generica. Parte dagli asset critici. Homepage, navigazione, aree riservate, moduli, pagine prodotto, checkout, ricerca interna e componenti riutilizzati dovrebbero essere il primo perimetro di verifica.
Dopo la scansione iniziale, serve una lettura esperta. Alcuni problemi sono automatizzabili, altri no. Il focus coperto da una barra sticky, la difficoltà di usare un controllo drag-and-drop o l’incomprensibilità di un flusso di autenticazione emergono bene solo con test mirati e revisione umana.
Anche la remediation va gestita per priorità. Non tutto pesa allo stesso modo. Un errore su un widget secondario non ha la stessa criticità di un blocco su login o pagamento. Per questo conviene lavorare con un piano che colleghi requisiti WCAG, rischio normativo e valore di business.
Per molte aziende italiane il nodo vero è qui: trasformare l’accessibilità da attività sporadica a processo. Scanner periodici, interventi correttivi, controllo delle release e documentazione coerente fanno la differenza tra un sito che sembra conforme e un’organizzazione che sa governare la conformità. È il tipo di approccio che piattaforme come Inclusivia rendono operativo, unendo automazione, remediation e gestione documentale.
WCAG 2.1 vs WCAG 2.2: quale scegliere come riferimento
Se dovete definire oggi uno standard interno, usare WCAG 2.2 come riferimento è la scelta più solida. Non perché WCAG 2.1 sia improvvisamente obsoleto, ma perché progettare sullo standard più aggiornato riduce il rischio di rincorrere correzioni a breve.
Detto questo, ci sono casi in cui la documentazione contrattuale, i capitolati o i requisiti normativi citano ancora in modo esplicito WCAG 2.1 AA. In quel caso non va ignorato il testo applicabile. Va però letto con buon senso: rispettare il requisito minimo non impedisce di adottare un benchmark più avanzato.
La differenza tra conformità formale e qualità sostanziale sta tutta qui. Fare il minimo richiesto può bastare sulla carta. Sul mercato, spesso non basta affatto.
L’accessibilità non si misura dalla versione che dichiarate, ma da ciò che una persona riesce davvero a fare sul vostro sito senza ostacoli inutili. È da quel punto che si costruiscono conformità, fiducia e vantaggio competitivo.