# Checklist WCAG 2.2 AA per prodotti SaaS e applicazioni web

<https://www.fixreports.com/it/blog/wcag-2-2-checklist-saas-web-apps>

Aggiornato il 2026-10-26

Un prodotto SaaS ha due superfici da rendere accessibili: il sito di marketing che lo vende e l’applicazione che le persone usano ogni giorno. Il sito di marketing fallisce negli stessi modi di qualsiasi sito web, con contrasto insufficiente, testo alternativo mancante e moduli senza etichetta. L’applicazione aggiunge problemi suoi: flussi di login che bloccano i password manager, finestre di dialogo che intrappolano il focus da tastiera, navigazione single-page che gli screen reader non notano, tabelle di dati e grafici senza testo, drag and drop senza alternative e sessioni che scadono senza preavviso. Questa checklist percorre il livello AA delle WCAG 2.2 seguendo le parti di un tipico prodotto SaaS.

**Punti chiave**

- Le WCAG 2.2 sono diventate Raccomandazione W3C nell’ottobre 2023 e hanno aggiunto nove criteri di successo, sei dei quali di livello A o AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA) significa che un login non può dipendere dal ricordare o trascrivere una password, a meno che non si possa incollarla o usare un password manager ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- I target interattivi devono misurare almeno 24 per 24 pixel CSS, oppure avere abbastanza spazio intorno (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Messaggi come «Salvato» o «3 risultati» devono raggiungere gli screen reader senza spostare il focus (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- Le aziende e gli enti pubblici che acquistano chiedono spesso un Accessibility Conformance Report (ACR), di solito redatto sul modello VPAT dell’Information Technology Industry Council ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## Perché l’accessibilità conta di più per un SaaS che per un sito vetrina?

Le persone usano un prodotto SaaS per ore, spesso perché l’ha scelto il loro datore di lavoro. Una barriera su una pagina di marketing fa perdere un visitatore; una barriera nel prodotto può impedire a qualcuno di fare il proprio lavoro. Per questo i clienti più grandi, le università e gli enti pubblici chiedono sempre più spesso dell’accessibilità prima di acquistare, e per questo la risposta deve riguardare l’applicazione, non solo il sito web.

Conta anche perché i test automatici rilevano solo una parte del problema. Strumenti come axe-core trovano gli errori nel markup, come etichette mancanti e contrasto insufficiente. Non possono dire se una finestra di dialogo riporta il focus nel punto giusto, se i dati di un grafico sono disponibili come testo o se un flusso di lavoro può essere completato con la tastiera. Un’applicazione ha bisogno sia di controlli automatici sia di test manuali.

## Come si rendono accessibili registrazione e login?

L’autenticazione è il punto in cui le WCAG 2.2 hanno aggiunto il nuovo requisito più importante per il SaaS.

- **Consenti l’incolla e i password manager (3.3.8, AA).** Non bloccare l’incolla nei campi della password o dei codici, e usa `autocomplete="username"`, `autocomplete="current-password"` e `autocomplete="one-time-code"` perché browser e password manager possano compilarli.
- **Evita i rompicapi come unico modo per entrare.** Un CAPTCHA che chiede di trascrivere testo distorto o di risolvere un rompicapo è un test di funzione cognitiva. Offri un’alternativa e preferisci verifiche che non richiedono azioni dell’utente ([W3C](https://www.w3.org/TR/turingtest/)).
- **Etichetta ogni campo (1.3.1 e 3.3.2, A).** Usa un `<label>` visibile collegato al suo campo; il testo segnaposto scompare quando si digita e non è un’etichetta.
- **Indica gli errori con il testo (3.3.1, A) e suggerisci correzioni (3.3.3, AA).** «La password deve avere almeno 12 caratteri» aiuta; un bordo rosso da solo no.
- **Non chiedere due volte (3.3.7, A).** Se una registrazione in più passaggi ha già chiesto il nome dell’azienda o un indirizzo, compilalo automaticamente o lascia che le persone lo selezionino invece di riscriverlo.
- **Tieni l’assistenza nello stesso punto (3.2.6, A).** Se offri una chat, un link di assistenza o dei recapiti, mettili nella stessa posizione relativa su ogni pagina del flusso.

## Quali schemi di moduli ed errori causano più problemi?

I moduli sono il punto in cui si concentra la maggior parte degli errori delle applicazioni. L’indagine 2026 di WebAIM su un milione di home page ha trovato etichette dei moduli mancanti nel 51% di esse ([WebAIM](https://webaim.org/projects/million/)), e le applicazioni hanno molti più moduli delle home page.

- Dai a ogni campo un nome programmatico e raggruppa i controlli correlati, come i pulsanti di opzione, con `<fieldset>` e `<legend>`.
- Segnala gli errori dove le persone li notano: sposta il focus su un riepilogo degli errori in cima al modulo, o sul primo campo non valido, e collega ogni voce del riepilogo al suo campo.
- Indica i campi obbligatori con il testo, non solo con il colore (1.4.1, A).
- Non inviare il modulo e non cambiare contesto quando qualcuno seleziona semplicemente un’opzione (3.2.2, A); aspetta un’azione esplicita.

## Come devono comportarsi finestre di dialogo, menu e popover?

I componenti personalizzati sono il punto in cui il supporto per tastiera e screen reader si rompe più spesso. L’ARIA Authoring Practices Guide del W3C descrive il comportamento atteso per ogni schema ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **Finestre di dialogo**: sposta il focus nella finestra quando si apre, mantieni il tasto Tab al suo interno finché resta aperta, chiudila con Esc e riporta il focus al controllo che l’ha aperta. Usa l’elemento nativo `<dialog>` oppure `role="dialog"` con `aria-modal="true"` e un nome.
- **Nessuna trappola da tastiera (2.1.2, A)**: ogni componente deve poter essere abbandonato con la tastiera.
- **Focus visibile (2.4.7, AA)** che non resti nascosto dietro header fissi, banner dei cookie o widget di chat (2.4.11, AA, novità della 2.2).
- **Tooltip e popover (1.4.13, AA)** che si possono chiudere con Esc, su cui si può passare il mouse senza che scompaiano e che restano visibili finché non vengono chiusi.
- **Scorciatoie da un solo tasto (2.1.4, A)**: se la pressione di un tasto con una lettera attiva un’azione, consenti di disattivare o riassegnare le scorciatoie, oppure rendile attive solo quando il componente interessato ha il focus.

## Come si gestisce la navigazione in un’app single-page?

In un’app single-page l’URL cambia senza caricare una nuova pagina, quindi gli screen reader potrebbero non annunciare che è successo qualcosa.

- Aggiorna il titolo del documento a ogni cambio di route, così ogni vista ha un titolo descrittivo (2.4.2, A).
- Sposta il focus sul titolo principale della nuova vista, oppure annuncia il cambiamento in una live region di tipo polite; framework come Next.js includono un route announcer a questo scopo.
- Mantieni un ordine del focus logico (2.4.3, A): dopo l’eliminazione di un elemento, il focus deve passare a un elemento vicino sensato, non tornare in cima alla pagina.
- Offri un modo per saltare la navigazione ripetuta (2.4.1, A), come uno skip link o i landmark.

## Come si rendono accessibili dashboard, tabelle di dati e grafici?

- **Tabelle**: usa un vero markup `<table>` con `<th>` e `scope` per le intestazioni, e una didascalia (1.3.1, A). Le griglie costruite con elementi `<div>` richiedono lo schema completo di griglia ARIA, molto più difficile da realizzare correttamente.
- **Grafici**: dai a ogni grafico un’alternativa testuale che ne esprima il punto principale e offri i dati in una tabella (1.1.1, A). Non affidarti solo al colore per distinguere le serie (1.4.1, A); aggiungi etichette o motivi.
- **Contrasto**: il testo richiede 4.5:1 (1.4.3, AA), mentre linee dei grafici, icone e bordi dei campi richiedono 3:1 rispetto allo sfondo (1.4.11, AA). Controlla la modalità scura separatamente. La nostra [verifica del contrasto dei colori](/it/color-contrast-checker) testa qualsiasi coppia di colori.
- **Messaggi di stato (4.1.3, AA)**: «Salvato», «Caricamento completato» e il numero di risultati devono usare `role="status"` o una live region, così gli screen reader li sentono senza perdere la posizione.

## Cosa cambiano per le app web i nuovi criteri delle WCAG 2.2?

| Criterio | Livello | Cosa significa in un’app |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Barre degli strumenti fisse, banner e widget di chat non devono coprire completamente l’elemento con il focus |
| 2.5.7 Dragging Movements | AA | Tutto ciò che si fa trascinando, come riordinare una bacheca kanban, richiede un’alternativa con un singolo puntatore, per esempio un menu o pulsanti su e giù |
| 2.5.8 Target Size (Minimum) | AA | Pulsanti e link di almeno 24 × 24 pixel CSS, oppure distanziati in modo che un cerchio di 24 pixel attorno a ciascuno non si sovrapponga a un altro |
| 3.2.6 Consistent Help | A | Link di assistenza, chat e recapiti nella stessa posizione relativa su ogni pagina |
| 3.3.7 Redundant Entry | A | Le informazioni già inserite nello stesso processo vengono compilate automaticamente o sono selezionabili |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login senza memorizzare o trascrivere, a meno che non siano consentiti l’incolla, i password manager o un altro metodo |

Le WCAG 2.2 hanno anche eliminato il 4.1.1 Parsing, che non ha più un effetto pratico sull’accessibilità ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## E per timeout, layout e zoom?

- **Timeout della sessione (2.2.1, A)**: avvisa le persone prima che una sessione scada e consenti di prolungarla con un’azione semplice, a meno che il limite di tempo non sia essenziale o superiore a 20 ore. Salvare il lavoro in corso evita il risultato peggiore.
- **Reflow (1.4.10, AA)**: i contenuti devono funzionare a 320 pixel CSS di larghezza (l’equivalente di uno zoom al 400% su uno schermo di 1280 pixel) senza scorrimento in due direzioni; tabelle di dati e contenuti simili sono esentati.
- **Spaziatura del testo (1.4.12, AA)**: aumentare l’interlinea e la spaziatura tra le lettere non deve tagliare il testo, cosa che i contenitori ad altezza fissa fanno spesso.
- **Orientamento (1.3.4, AA)**: non bloccare l’app in verticale o in orizzontale, a meno che non sia essenziale.

## Cos’è un ACR, e ti serve?

Un Accessibility Conformance Report (ACR) documenta come un prodotto soddisfa ogni criterio di accessibilità: supportato, parzialmente supportato o non supportato, con osservazioni. La maggior parte è redatta sul modello VPAT pubblicato dall’Information Technology Industry Council, che ha edizioni per le WCAG, gli standard statunitensi della Section 508 e lo standard europeo EN 301 549 ([ITI](https://www.itic.org/policy/accessibility/vpat)).

Le agenzie federali statunitensi devono acquistare tecnologia accessibile ai sensi della Section 508 ([Section508.gov](https://www.section508.gov/)), e gli enti pubblici dell’UE fanno riferimento alla EN 301 549, quindi ai prodotti B2B che vendono a questi clienti viene spesso chiesto un ACR durante le procedure di acquisto. Un ACR onesto, che elenca le lacune note, è più utile agli acquirenti di uno che dichiara un supporto completo. Deve basarsi su test del prodotto, compresi i test manuali; una scansione automatica da sola non basta a compilarlo.

Se vendi a consumatori dell’UE, anche l’European Accessibility Act può applicarsi al modo in cui vendi online; la nostra [guida all’EAA](/it/blog/european-accessibility-act-online-stores) ne spiega l’ambito. Questa non è una consulenza legale.

## Come dovrebbe testare l’accessibilità un team SaaS?

1. **Automatizza le basi.** Esegui axe-core o un motore simile nei test end-to-end e sul sito di marketing, e fai fallire le build in caso di nuove violazioni. La nostra [verifica gratuita dell’accessibilità](/it/website-accessibility-checker) esegue lo stesso motore su qualsiasi pagina pubblica.
2. **Testa con la tastiera.** Completa i flussi principali, come la registrazione, la creazione di un record e la modifica delle impostazioni, usando solo Tab, Maiusc+Tab, Invio, Spazio, Esc e i tasti freccia.
3. **Testa con uno screen reader.** NVDA su Windows e VoiceOver su macOS e iOS sono gratuiti. Verifica che nomi, ruoli, stati e messaggi vengano annunciati.
4. **Ingrandisci e ridimensiona.** Controlla lo zoom del testo al 200% e una finestra larga 320 pixel.
5. **Correggi nel design system.** La maggior parte degli errori nasce da componenti condivisi; correggere una volta un pulsante o una finestra di dialogo lo corregge ovunque.

## Domande frequenti

### Le WCAG si applicano alle parti di un’app web accessibili dopo il login?

Le WCAG si applicano a qualsiasi contenuto web, comprese le pagine protette da login. Se una legge imponga a un prodotto specifico di rispettarle dipende dalla giurisdizione e dal cliente, ma gli acquirenti che chiedono dell’accessibilità di solito intendono l’intero prodotto.

### Un overlay può rendere accessibile un prodotto SaaS?

No. Gli overlay non modificano il codice sottostante dei componenti personalizzati, ed è lì che si trovano gli errori delle applicazioni. La nostra guida sugli [overlay di accessibilità](/it/blog/accessibility-overlays-ftc-order) racconta l’azione della FTC contro uno dei principali fornitori di overlay.

### Quanta parte delle WCAG possono controllare gli strumenti automatici?

Solo una parte. Le regole automatiche trovano in modo affidabile nomi ed etichette mancanti ed errori di contrasto, ma molti criteri, come un ordine del focus sensato, un testo alternativo utile e messaggi di errore comprensibili, richiedono il giudizio di una persona.

### Quale versione delle WCAG dovremmo adottare come obiettivo?

Le WCAG 2.2 di livello AA sono la versione attuale. Molte leggi e regole sugli acquisti fanno ancora riferimento alle WCAG 2.1 AA; soddisfare le 2.2 AA significa soddisfare anche le 2.1 AA, a parte il criterio Parsing eliminato.

### Dobbiamo raggiungere il livello AAA?

Il W3C non raccomanda di richiedere il livello AAA per interi prodotti, perché alcuni contenuti non possono soddisfare tutti i criteri AAA. Il livello AA è l’obiettivo abituale.

## Fonti

- W3C: [What's new in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)