WCAG — che cos'è, Web Content Accessibility Guidelines e livelli AA

Cos'è WCAG?

WCAG (Web Content Accessibility Guidelines) è un insieme di raccomandazioni per garantire l'accessibilità dei contenuti web alle persone con disabilità. Lo standard è sviluppato da W3C Web Accessibility Initiative (WAI) dal 1999. WCAG copre ciechi e ipovedenti, sordi e ipoudenti, persone con limitazioni motorie, disturbi del linguaggio e cognitivi, nonché utenti anziani con cambiamenti legati all'età.

La prima versione WCAG 1.0 è uscita nel 1999 e conteneva 14 principi guida. WCAG 2.0 (2008) è diventata tecnologicamente neutra, applicabile a HTML, PDF, multimedia e applicazioni mobili. WCAG 2.1 (2018) ha aggiunto criteri per dispositivi mobili e input tattile. WCAG 2.2 (2023) è la versione attuale con nuovi criteri per animazione e focus. WCAG non è una legge, ma molti paesi vi fanno riferimento nella loro legislazione.

GOST R 52872-2019 in Russia, la European Accessibility Act nell'UE e la Sezione 508 negli USA — tutte richiedono conformità WCAG AA. Per i siti web aziendali e governativi, WCAG AA è uno standard obbligatorio, la cui inosservanza porta a cause legali. Secondo UsableNet (2024), oltre 12 000 cause per inaccessibilità web sono state presentate negli USA.

Versioni WCAG: confronto

Conseguenze legali della non conformità

La non conformità a WCAG comporta rischi gravi. Nel 2025, la European Accessibility Act (EAA) è entrata in vigore, richiedendo WCAG 2.1 AA per tutti i siti web pubblici e le applicazioni mobili nell'UE. Le multe possono raggiungere fino al 5% del fatturato annuo dell'azienda. L'importo medio di transazione delle cause negli USA è di $25 000–$50 000. Gli audit di accessibilità dovrebbero essere condotti in ogni fase dello sviluppo, non solo prima del rilascio.

Quattro principi di WCAG: POUR

POUR è un acronimo di quattro principi WCAG: Perceivable (percepibile), Operable (utilizzabile), Understandable (comprensibile), Robust (robusto). Ogni principio contiene linee guida e le linee guida contengono criteri di successo testabili. WCAG 2.2 ha 13 linee guida e 86 criteri di successo. Ogni criterio ha livello A, AA o AAA.

Perceivable — Percepibile

Il principio Perceivable richiede che il contenuto sia presentato in una forma che l'utente possa percepire. Linee guida: 1.1 Text Alternatives (alternative testuali), 1.2 Time-based Media (sottotitoli, trascrizioni), 1.3 Adaptable (contenuto senza perdita al cambio di formato), 1.4 Distinguishable (contrasto 4.5:1, colore, suono). Il criterio chiave 1.4.3 Contrast Minimum (AA) è il più violato: l'86% delle pagine non lo rispetta secondo WebAIM.

Operable — Utilizzabile

Il principio Operable richiede l'utilizzabilità dell'interfaccia. Linee guida: 2.1 Keyboard Accessible, 2.2 Enough Time, 2.3 Seizures, 2.4 Navigable, 2.5 Input Modalities. Il criterio 2.1.1 Keyboard (A) è uno dei più critici: tutte le funzioni devono essere accessibili tramite tastiera senza mouse. Finestre modali che si chiudono solo al clic, menu a tendina senza navigazione da tastiera — violazioni tipiche.

Understandable — Comprensibile

Il principio Understandable richiede la comprensibilità del contenuto e dell'interfaccia. Linee guida: 3.1 Readable, 3.2 Predictable, 3.3 Input Assistance. Il criterio 3.3.4 Error Prevention è particolarmente importante per applicazioni finanziarie e mediche: prevenire conseguenze gravi di errori di input. Il criterio 3.2.6 Consistent Help (nuovo in WCAG 2.2) richiede che i pulsanti di aiuto siano nelle stesse posizioni.

Robust — Robusto

Il principio Robust richiede compatibilità con le tecnologie assistive. Linea guida 4.1 Compatible con il criterio chiave 4.1.2 Name, Role, Value (A): ogni componente dell'interfaccia deve avere nome, ruolo e stato determinabili programmaticamente. Gli attributi ARIA (role, aria-label, aria-expanded) sono lo strumento principale. Senza di essi, gli screen reader non possono determinare se un elemento è un pulsante, un link o una scheda.

Tabella dei principi WCAG

Livelli di conformità WCAG: A, AA, AAA

WCAG definisce tre livelli: A (minimo), AA (standard) e AAA (massimo). Il livello A è il minimo obbligatorio: senza di esso, il contenuto è inaccessibile per alcune categorie di utenti. AA rimuove le principali barriere di accessibilità. AAA è lo standard più alto, ma non può essere raggiunto per tutti i contenuti (ad esempio, alcune lingue dei segni o trascrizioni audio non sono sempre realizzabili).

Livello A (30 criteri): alternative testuali, utilizzabilità da tastiera, tempo sufficiente, nessuno sfarfallio sopra 3 Hz. Livello AA (+24 criteri): rapporto di contrasto 4.5:1, sottotitoli per video, ridimensionamento del testo fino al 200%, focus di tastiera chiaro. Livello AAA (+32 criteri): rapporto di contrasto 7:1, lingua dei segni, disattivazione delle animazioni (2.3.3), trascrizione audio. Per i siti governativi, AA è sufficiente.

Processo di audit WCAG

Un audit di accessibilità WCAG include: test automatizzati (axe DevTools, WAVE, Lighthouse — trova il 30–40% degli errori), test manuali con tastiera e screen reader (VoiceOver, TalkBack, NVDA), audit esperto per criteri complessi e test con utenti con disabilità. Il rapporto di audit dovrebbe contenere il livello di conformità e un elenco di non conformità per ogni criterio.

Novità di WCAG 2.2

WCAG 2.2 ha aggiunto 9 nuovi criteri. Principali: 2.4.11 Focus Appearance (AA) — indicatore di focus >= 2px con contrasto 3:1, 2.5.8 Target Size Minimum (AA) — bersaglio tattile di almeno 24x24 pixel, 3.3.7 Accessible Authentication (AA) — autenticazione senza CAPTCHA. Criterio 2.3.3 Animation from Interactions (AAA) — animazione disattivabile o non oltre 5 secondi.

Focus Appearance è il cambiamento più importante. In precedenza, outline: none senza sostituzione era una violazione, ma non c'erano requisiti chiari. WCAG 2.2 ha stabilito: spessore >= 2px, contrasto 3:1 con lo sfondo, area dell'indicatore almeno l'area dell'elemento. Per pulsanti personalizzati con border-radius, utilizzare box-shadow invece di outline.

Focus Appearance in CSS

/* WCAG 2.2 Focus Appearance (2.4.11 AA) */
:focus-visible {
    outline: 3px solid #0066CC;
    outline-offset: 2px;
}

.button:focus-visible {
    outline: none;
    box-shadow:
        0 0 0 3px #FFFFFF,
        0 0 0 6px #0066CC;
}

@media (prefers-color-scheme: dark) {
    :focus-visible { outline-color: #66B2FF; }
}

@media (prefers-contrast: more) {
    :focus-visible { outline: 4px solid #000; outline-offset: 3px; }
}

Lo stile di :focus-visible garantisce la conformità al criterio Focus Appearance. Un'alternativa tramite box-shadow funziona per elementi con border-radius. Il tema scuro e High Contrast adattano i colori di focus.

Accessible Authentication

Il criterio 3.3.7 Accessible Authentication (AA) è una delle innovazioni più discusse. CAPTCHA con riconoscimento di oggetti, puzzle, trascinamento di cursori — ora è una violazione se non c'è alternativa. Metodi accettabili: OTP via email/SMS, biometria (Face ID, Touch ID), codici QR, Magic link. Questo semplifica la vita non solo alle persone con disturbi cognitivi, ma a tutti gli utenti.

WCAG per applicazioni mobili

WCAG si applica ad applicazioni native iOS e Android. I quattro principi POUR coprono completamente le interfacce mobili. Criteri specifici: 2.5.1 Pointer Gestures (gesti senza alta precisione), 2.5.2 Pointer Cancellation (annullamento tocco accidentale), 2.5.3 Label in Name (il testo del pulsante corrisponde all'etichetta di accessibilità). iOS utilizza UIKit/UIAccessibility, Android utilizza AccessibilityService e ContentDescription.

Più frequentemente violati nelle applicazioni mobili: 1.1.1 Non-text Content — icone senza contentDescription, 2.4.3 Focus Order — ordine di navigazione errato, 2.5.8 Target Size — pulsanti più piccoli di 24x24dp, 1.4.3 Contrast — testo su immagini di sfondo. iOS fornisce Accessibility Inspector in Xcode, Android fornisce Accessibility Scanner per audit automatizzati.

Codice SwiftUI conforme WCAG

import SwiftUI

struct AccessibleButton: View {
    let action: () -> Void
    let title: String
    let icon: String

    var body: some View {
        Button(action: action) {
            HStack {
                Image(systemName: icon)
                Text(title)
            }
            .padding(16)
            .background(Color.blue)
            .foregroundColor(.white)
            .cornerRadius(12)
            .frame(minWidth: 48, minHeight: 48)
        }
        .accessibilityLabel(title)
        .accessibilityHint("Clicca per azione")
        .accessibilityAddTraits(.isButton)
    }
}

struct AccessibleForm: View {
    @State private var email = ""

    var body: some View {
        VStack(spacing: 16) {
            VStack(alignment: .leading) {
                Text("Email")
                TextField("Inserisci email", text: $email)
                    .textContentType(.emailAddress)
                    .keyboardType(.emailAddress)
                    .autocapitalization(.none)
                    .accessibilityLabel("Campo di inserimento email")
                    .accessibilityHint("Inserisci indirizzo email")
            }
            AccessibleButton(
                action: { },
                title: "Invia",
                icon: "paperplane.fill"
            )
        }
        .padding()
    }
}

I componenti SwiftUI con accessibilityLabel, accessibilityHint e minWidth/minHeight >= 48pt garantiscono la conformità a WCAG 2.5.8 (Target Size) e 2.5.3 (Label in Name). Utilizzare Xcode Accessibility Inspector per verificare il focus VoiceOver, l'ordine di navigazione e le dimensioni dei bersagli tattili. Requisiti simili si applicano a Jetpack Compose tramite Modifier.semantics.