UI, UX & Research

Cosa c'è di nuovo nelle WCAG 2.2?

L'aggiornamento 2.2 delle Web Content Accessibility Guidelines (WCAG) è stato rilasciato il 5 ottobre. Sappiamo che non hai voglia di rileggerti tutte le WCAG, quindi abbiamo riassunto per te tutto ciò che è cambiato rispetto alle versioni precedenti.

Sara Bianchini Sara Bianchini
15 dicembre 2023 — 3 min

Il 5 ottobre è stato rilasciato l’aggiornamento 2.2 delle Web Content Accessibility Guidelines (WCAG). Sappiamo che non hai voglia di rileggerti tutte le WCAG, quindi abbiamo riassunto per te tutto ciò che è cambiato rispetto alle versioni precedenti!

La maggior parte degli aggiornamenti consiste nella semplice formalizzazione di pratiche già considerate best practice. La novità più rilevante riguarda i flussi di registrazione e autenticazione.‍

Deprecazione del Parsing

La prima novità è la deprecazione del Success Criterion 4.1.1 Parsing. La motivazione è che l’evoluzione dei browser e delle tecnologie assistive lo ha reso obsoleto.

Maggiore enfasi sulla visibilità del focus

La visibilità del focus era già trattata dal Success Criterion 2.4.7 Focus Visible, livello AA. Le WCAG 2.2 estendono il requisito, specificando che l’elemento interattivo non solo deve avere uno stato di focus, ma deve anche essere almeno parzialmente visibile e non coperto da altri componenti (Success Criterion 2.4.11 Focus not Obscured, Minimum, livello AA).

Al livello AAA il requisito viene ulteriormente rafforzato, indicando che l’elemento deve essere completamente visibile (Success Criterion 2.4.12 Focus not Obscured, Enhanced) e, aspetto ancora più interessante, che lo stile del focus deve rispettare determinati criteri (Success Criterion 2.4.13 Focus Appearance).

Vengono definite l’area minima e il contrasto minimo che lo stile del focus deve avere (2 pixel rispetto al perimetro del componente e un rapporto di contrasto di 3:1).

__wf_reserved_inherit

Lo stile del focus in Adobe Spectrum

Drag & drop e dimensione dei target

All’interno della Linea guida 2.5 sulle modalità di input vengono aggiunti due nuovi criteri (Success Criterion 2.5.7 Dragging Movements e 2.5.8 Target Size).

Il primo riguarda i movimenti di drag & drop (e quindi anche gli slider!) e richiede che la stessa azione possa essere eseguita con un singolo click o tramite un campo di input che permetta di specificare lo stesso valore.

Il secondo prevede che le aree cliccabili abbiano almeno una dimensione di 24x24 pixel, o che siano racchiuse in un’area vuota di almeno 24x24 pixel. Era già una best practice consolidata, ma non ancora formalizzata nelle WCAG.

Sebbene le WCAG parlino solo di aree vuote interne al componente, è comunque preferibile che quest’area sia cliccabile.

__wf_reserved_inherit

Uno slider nel Carbon Design System

Aiuto coerente

Il Success Criterion 3.2.6 Consistent Help viene introdotto seguendo la logica del 3.2.3 Consistent Navigation. Quest’ultimo richiede che la navigazione sia coerente all’interno di un gruppo di pagine simili. Il criterio 3.2.6 estende il requisito ai meccanismi di aiuto, come contatti, link alle FAQ o chatbot.

Inserimento ridondante

Il Success Criterion 3.3.7 Redundant Entry, livello A, incoraggia a limitare le situazioni in cui l’utente deve inserire più volte gli stessi dati. La soluzione è l’uso di campi precompilati: oltre a essere un criterio di accessibilità, è anche una best practice di user experience.

Registrazione e autenticazione

Due nuovi criteri hanno impatto sui flussi di registrazione e autenticazione: Success Criterion 3.3.8 Accessible Authentication (Minimum), livello AA, e Success Criterion 3.3.9 Accessible Authentication (Enhanced), livello AAA.

Il primo stabilisce che i metodi di autenticazione basati su test cognitivi, incluso il dover ricordare una password o una sequenza numerica (OTP compresi), non dovrebbero più essere utilizzati. È però considerato soddisfatto se il campo password consente l’autocompletamento del browser e se è possibile copiare e incollare l’OTP (anche tra due dispositivi diversi).

Il criterio ha impatto anche sui CAPTCHA, escludendo tutti quelli che richiedono di riconoscere lettere o di eseguire operazioni matematiche. Quelli basati sul riconoscimento di immagini sono invece considerati accessibili.

Il secondo criterio rende il primo più stringente, escludendo dalle eccezioni anche il riconoscimento di immagini.

__wf_reserved_inherit

Autenticazione tramite magic link in SlashID

In conclusione, è evidente che dare priorità a questi due criteri ha un impatto significativo sull’evoluzione dei metodi di autenticazione. La crescente adozione di magic link e di autenticazione biometrica ne è una dimostrazione. Questo cambiamento si allinea perfettamente alla tendenza verso l’autenticazione passwordless, una trasformazione che aumenta la sicurezza e migliora notevolmente l’accessibilità per gli utenti. Il futuro dell’autenticazione è su una strada promettente e centrata sulle persone.

Sara Bianchini
Sara Bianchini UX/UI Designer

Sara is a designer at Buildo, specializing in User Research and UX. Her passion for research enables her to gain a deep understanding of users' needs and translate them into intuitive and user-friendly designs.

NEWSLETTER

Ehi, c'è anche una Newslettero!
Sì, proprio con la o.

Ogni mese scegliamo articoli utili ma anche idee fresche e stimolanti. Proprio quello che vorremmo trovare noi in una newsletter!