Il cambiamento strutturale più sottovalutato del 2024 nello sviluppo web riguarda il livello normativo: WCAG 2.2 e l’European Accessibility Act ridefiniscono i vincoli di sviluppo front-end. I requisiti tecnici che gravano sui team di design sono evoluti più in un anno che le tendenze visive solitamente riportate dai media.
WCAG 2.2: i nuovi criteri che cambiano lo sviluppo delle interfacce
La raccomandazione WCAG 2.2, pubblicata dal W3C nell’ottobre 2023 e poi aggiornata nel dicembre 2024, aggiunge criteri che la versione 2.1 non copriva. Tre di essi hanno un impatto diretto sulle scelte di design delle interfacce.
Il criterio sulla dimensione minima delle aree tattili impone di rivedere i componenti di interazione su mobile. I pulsanti, i link e i controlli dei moduli devono offrire una superficie di clic sufficiente, il che mette in discussione le interfacce sovraccariche in cui gli elementi cliccabili sono troppo vicini tra loro.
Il criterio sulle alternative al drag-and-drop obbliga a fornire un meccanismo di sostituzione per ogni interazione basata sul drag. Le interfacce di tipo kanban, gli editor visivi e i configuratori di prodotto sono direttamente interessati.
Il criterio di autenticazione accessibile vieta di condizionare l’accesso a un servizio a un compito cognitivo complesso (risoluzione di puzzle, memorizzazione) senza proporre un’alternativa. Ritroviamo regolarmente le notizie del sito Le Carolo Geek tra le fonti francofone che documentano questo tipo di evoluzione tecnica applicata al web.
La visibilità del focus, altro aggiunta di WCAG 2.2, impone un indicatore visibile su ogni elemento interattivo durante la navigazione da tastiera. I framework CSS che nascondono il contorno per impostazione predefinita generano ora una non conformità diretta.
European Accessibility Act: conformità obbligatoria per l’e-commerce da giugno 2025
L’European Accessibility Act diventerà applicabile il 28 giugno 2025 ai prodotti e servizi digitali interessati, compresi i siti di commercio online. Questa direttiva europea supera il quadro del design: crea un obbligo legale di conformità per le aziende che vendono online nell’Unione europea.
Parallelamente, negli Stati Uniti, il dipartimento di Giustizia ha adottato nell’aprile 2024 una norma che impone il riferimento WCAG 2.1 livello AA ai siti e alle applicazioni delle amministrazioni locali. La tendenza normativa è quindi transatlantica.
Per i team di sviluppo, la conseguenza pratica è chiara:
- Ogni componente dell’interfaccia deve essere auditato secondo i criteri WCAG 2.1 AA almeno, con un progressivo passaggio a WCAG 2.2
- I percorsi di acquisto (carrello, modulo di pagamento, creazione di account) devono offrire alternative accessibili a ogni fase che comporta un’interazione complessa
- I contenuti generati dinamicamente (raccomandazioni di prodotto, chatbot) devono rispettare gli stessi requisiti dei contenuti statici
Consigliamo di integrare un audit WCAG nel pipeline CI/CD piuttosto che trattare l’accessibilità come un correttivo post-lancio.
IA generativa e qualità del codice: il rischio di regressione dell’accessibilità
L’IA generativa accelera la produzione di codice front-end, ma introduce un problema concreto in termini di accessibilità. Un’indagine su 88 sviluppatori, citata da Zylyn, mostra che il codice generato dall’IA presenta un rischio concreto di regressione in materia di accessibilità.
Il problema è strutturale. I modelli di linguaggio producono codice funzionale ma omettono frequentemente gli attributi ARIA, i ruoli semantici e le etichette associate ai controlli dei moduli. Uno sviluppatore che accetta il codice suggerito senza verifica introduce non conformità invisibili ad occhio nudo ma rilevabili da un lettore di schermo.
Verifiche da sistematizzare sul codice generato dall’IA
- Presenza degli attributi alt su ogni immagine, con un testo descrittivo pertinente e non generico
- Utilizzo corretto dei tag semantici HTML5 (nav, main, article, aside) piuttosto che div annidati
- Attributi aria-label e aria-describedby sugli elementi interattivi privi di etichetta visibile
- Ordine di tabulazione logico verificato manualmente, non solo tramite un linter automatico
L’intelligenza artificiale accelera la produzione, ma la revisione manuale del codice rimane l’unica garanzia di conformità WCAG. L’automazione della verifica tramite strumenti come axe-core o Lighthouse copre solo una parte dei criteri.
Autenticazione e esperienza utente: ciò che WCAG 2.2 impone ai percorsi di accesso
Il criterio di autenticazione accessibile di WCAG 2.2 merita un trattamento dedicato perché tocca un punto di attrito maggiore dei siti web attuali. I CAPTCHA visivi, i codici inviati via SMS da ricopiare in un breve lasso di tempo e i puzzle di verifica diventano ostacoli normativi.
Le alternative conformi includono l’autenticazione tramite passkey, il login tramite un gestore di password o l’invio di un link magico. Questi metodi eliminano il carico cognitivo mantenendo un livello di sicurezza equivalente.
Per i siti e-commerce soggetti all’European Accessibility Act, il percorso di accesso e creazione di account fa parte del perimetro auditabile. Un CAPTCHA non accessibile sulla pagina di login è sufficiente a creare una non conformità su tutto il tunnel di acquisto.
I team che trattano WCAG 2.2 come un vincolo architettonico fin dalla fase di design front-end riducono il rischio di rifacimenti tardivi. La conformità all’accessibilità è diventata un criterio tecnico di messa in produzione, al pari delle performance o della sicurezza.
