Un parto lungo, molto lungo, fa nascere le WCAG 2.2 il 5 ottobre 2023. In molti aspettavamo la loro uscita, e tra i molti metto anche le realtà che si occupano di normazione tecnica. Quindi ora cambia tutto? Non proprio.

Le novità delle WCAG 2.2 in breve

Riservandoci di fare una serie di articoli dedicati alle novità, ecco un breviario delle novità apportate dalle WCAG 2.2.

Nuovi criteri di successo

Sono stati aggiunti 9 nuovi criteri di successo (la traduzione in italiano è temporanea, per la versione definitiva è necessario attendere la traduzione ufficiale):

  • 2.4.11 Focus non oscurato (minimo) (AA)
  • 2.4.12 Focus non oscurato (avanzato) (AAA)
  • 2.4.13 Aspetto del focus (AAA)
  • 2.5.7 Movimenti di trascinamento (AA)
  • 2.5.8 Dimensione obiettivo (minimo) (AA)
  • 3.2.6 Aiuto coerente (A)
  • 3.3.7 Inserimento ridondante (A)
  • 3.3.8 Autenticazione accessibile (minimo) (AA)
  • 3.3.9 Autenticazione accessibile (avanzato) (AAA)

I nuovi criteri di successo possono fare riferimento a nuovi termini che sono stati aggiunti al glossario e fanno parte dei requisiti normativi dei criteri di successo.

Le WCAG 2.2 introducono inoltre nuove sezioni che descrivono in dettaglio gli aspetti delle specifiche che potrebbero avere un impatto sulla privacy e sulla sicurezza.

Modifiche a criteri di successo esistenti

Le WCAG 2.2 hanno rimosso dopo ampia discussione, un criterio di successo, 4.1.1 Analisi sintattica (Parsing) lasciando la seguente nota:

Questo criterio è stato originariamente adottato per risolvere i problemi che la tecnologia assistiva presentava durante l’analisi diretta dell’HTML. La tecnologia assistiva non ha più bisogno di analizzare direttamente l’HTML. Di conseguenza, questi problemi non esistono più o vengono affrontati con altri criteri. Questo criterio non ha più utilità e viene rimosso.

https://www.w3.org/TR/WCAG22/#parsing

L’intento di questo criterio di successo era garantire che i programmi utente, comprese le tecnologie assistive, possano interpretare e analizzare accuratamente i contenuti. Da quando sono state pubblicate le WCAG 2.0, le specifiche (come HTML) e i browser hanno migliorato la gestione degli errori di analisi. È anche vero che la tecnologia assistiva prima eseguiva la propria analisi del markup, ma ora si affida al browser. Per questo motivo questo criterio di successo è stato eliminato. Molte questioni che avrebbero portato a non superare questo criterio violeranno il criterio di successo 1.3.1 «Informazioni e correlazioni» oppure 4.1.2 «Nome, Ruolo, Valore». Altre questioni sono escluse dalla parte del criterio “tranne quando le specifiche consentono queste caratteristiche”.

Una guida con personas

Un nuovo documento non normativo, le novità nelle WCAG 2.2 introducono i nuovi criteri di successo con citazioni di persone che illustrano i problemi di accessibilità.

Ad esempio per il criterio di successo 2.4.11 viene descritto in breve:

Cosa fare

Assicurati che quando un elemento viene attivato dalla tastiera, sia almeno parzialmente visibile.

Perché è importante

Le persone che non sanno usare il mouse devono vedere cosa ha il focus della tastiera.

Esempio di persona: un giornalista con lesioni da stress ripetitivo che utilizza un software di riconoscimento vocale.

Problema

“Questa pagina ha un grande banner sempre in basso. (un piè di pagina fisso) Quando sposto lo stato attivo sugli elementi, alcuni sono nascosti dietro il banner e non riesco a vederli”.

Funziona bene

“Quando sposto lo stato attivo sugli elementi, posso vederli tutti”.

Conformità rispetto alle precedenti WCAG

Le WCAG 2.2 si basano e sono retrocompatibili con le WCAG 2.1, il che significa che le pagine web conformi alle WCAG 2.2 sono accessibili almeno quanto le pagine conformi alle WCAG 2.1.

E se volessi usare le WCAG 2.2?

Ove siano presenti regolamentazioni che richiedono di conformarsi alle WCAG 2.0 o 2.1 nessuno vieta di lavorare anche in ottica di WCAG 2.2 essendo le stesse retro-compatibili.

Esiste però il problema del criterio di successo 4.1.1 che non sparisce dalle WCAG 2.1 ma solo dalle WCAG 2.2, e che pertanto porta a dover continuare a testare il criterio di successo 4.1.1.

Su questo tema, onde evitare disallineamenti, il 21 settembre 2023 sono state aggiornate anche le WCAG 2.1, alle quali è stata aggiunta una nota:

Da quando questo criterio è stato scritto, l’HTML Living Standard ha adottato requisiti specifici che governano il modo in cui i programmi utente devono gestire tag incompleti, annidamento errato degli elementi, attributi duplicati e ID non univoci.

Sebbene lo standard HTML tratti alcuni di questi casi come non conformi per gli autori, si ritiene di “consentire queste funzionalità” ai fini di questo criterio di successo perché la specifica richiede che gli interpreti programmi supportino la gestione di questi casi in modo coerente. In pratica, questo criterio non fornisce più alcun beneficio alle persone con disabilità di per sé.

Problemi come ruoli mancanti a causa di elementi nidificati in modo inappropriato o stati o nomi errati a causa di un ID duplicato sono coperti da diversi criteri di successo e dovrebbero essere segnalati in base a tali criteri piuttosto che come problemi con 4.1.1.

https://www.w3.org/TR/WCAG21/#parsing

Pertanto, a differenza di quanto si legge in rete, ciò che prevedeva il criterio di successo 4.1.1 ove effettivamente crei problemi con tecnologie assistive, viene gestito da altri criteri di successo (ad esempio, 1.3.3) ma deve essere comunque rendicontato anche come 4.1.1 per conformità con le WCAG 2.1. Saranno poi oggetto di valutazione, rispetto alle WCAG 2.2, solamente per gli altri criteri di successo violati senza considerare il 4.1.1.

Quanti sono i criteri di successo da verificare?

Considerato che nelle WCAG 2.1, per conformità normativa (livello “A” e “AA” delle WCAG) erano oggetto di analisi 50 criteri di successo, con l’aggiunta dei 6 nuovi criteri (2 di livello “A” e 4 di livello “AA”) e la rimozione del criterio di successo 4.1.1, i criteri da verificare diventano 55.

Quando iniziare a progettare secondo WCAG 2.2?

La risposta è semplice: da oggi. Grazie alla retrocompatibilità sopra descritta e facendo attenzione alla violazione dell’attuale criterio di successo 4.1.1 è auspicabile (direi consigliabile) usare già da oggi la nuova specifica, estendendo i 6 nuovi criteri di successo nelle fasi di progettazione e sviluppo.

Con tale ottica di sviluppo, le soluzioni create saranno comunque conformi alle vigenti normative tecniche e legislative e saranno già predisposte all’aggiornamento tecnico-normativo futuro, ovvero all’aggiornamento della norma tecnica EN 301 549 nella sua estensione per l’European Accessibility Act.

Nel frattempo…

A breve inizieranno le attività di traduzione delle WCAG 2.1. La chiamata al lavoro è già stata fatta e il gruppo è bello corposo. Se avete voglia e tempo da dedicarci, vi aspettiamo.