Le nuove Linee Guida sull’accessibilità dei contenuti del web
21-10-2023 14:52 - News
Un parto lungo, molto lungo, ha fatto finalmente nascere il 5 ottobre le WCAG 2.2, ovvero l’aggiornamento delle Linee Guida internazionali sull’accessibilità dei contenuti del web. «In molti – scrive Roberto Scano – aspettavamo la loro uscita, e tra i molti metto anche le realtà che si occupano di normazione tecnica. Quindi ora cambia tutto? Non proprio». È lo stesso Scano, uno dei principali “addetti ai lavori” del settore a livello internazionale, a soffermarsi, nel presente approfondimento, sulle varie novità
WCAG 2.2Un parto lungo, molto lungo, ha fatto finalmente nascere il 5 ottobre scorso le WCAG 2.2, ovvero l’aggiornamento delle Linee Guida internazionali sull’accessibilità dei contenuti del web. 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.
Elenchiamo innanzitutto, in modo sintetico, le novità delle WCAG 2.2, a partire dai nuovi “criteri di successo”, ossia gli obiettivi da raggiungere per poter garantire l’accessibilità.
Sono esattamente nove i nuovi criteri di successo, ricordando che la traduzione in italiano è al momento ufficiosa, in attesa della 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 Voce 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” stessi.
Le WCAG 2.2 introducono inoltre nuove sezioni che descrivono in dettaglio gli aspetti i quelle specifiche che potrebbero avere un impatto sulla privacy e sulla sicurezza.
Per quanto poi riguarda le modifiche ai criteri di successo esistenti, dopo ampia discussione, le WCAG 2.2 ne hanno rimosso uno (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.
Occupiamo quindi della 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. Ma 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 appunto le stesse, come detto, retrocompatibili. Esiste però il problema del citato 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 scorso 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».
Pertanto, a differenza di quanto si legge in rete, ciò che prevedeva il criterio di successo 4.1.1 ove effettivamente creasse dei problemi con le tecnologie assistive, viene gestito da altri criteri di successo (ad esempio, 1.3.3), ma deve comunque essere 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 dunque 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.
E infine: quando iniziare a progettare secondo WCAG 2.2? La risposta è semplice: dal 5 ottobre! Grazie infatti alla retrocompatibilità sopra descritta e facendo attenzione alla violazione dell’attuale criterio di successo 4.1.1, è auspicabile (direi anzi 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 (Legge Europea sull’Accessibilità).
WCAG 2.2Un parto lungo, molto lungo, ha fatto finalmente nascere il 5 ottobre scorso le WCAG 2.2, ovvero l’aggiornamento delle Linee Guida internazionali sull’accessibilità dei contenuti del web. 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.
Elenchiamo innanzitutto, in modo sintetico, le novità delle WCAG 2.2, a partire dai nuovi “criteri di successo”, ossia gli obiettivi da raggiungere per poter garantire l’accessibilità.
Sono esattamente nove i nuovi criteri di successo, ricordando che la traduzione in italiano è al momento ufficiosa, in attesa della 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 Voce 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” stessi.
Le WCAG 2.2 introducono inoltre nuove sezioni che descrivono in dettaglio gli aspetti i quelle specifiche che potrebbero avere un impatto sulla privacy e sulla sicurezza.
Per quanto poi riguarda le modifiche ai criteri di successo esistenti, dopo ampia discussione, le WCAG 2.2 ne hanno rimosso uno (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.
Occupiamo quindi della 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. Ma 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 appunto le stesse, come detto, retrocompatibili. Esiste però il problema del citato 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 scorso 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».
Pertanto, a differenza di quanto si legge in rete, ciò che prevedeva il criterio di successo 4.1.1 ove effettivamente creasse dei problemi con le tecnologie assistive, viene gestito da altri criteri di successo (ad esempio, 1.3.3), ma deve comunque essere 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 dunque 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.
E infine: quando iniziare a progettare secondo WCAG 2.2? La risposta è semplice: dal 5 ottobre! Grazie infatti alla retrocompatibilità sopra descritta e facendo attenzione alla violazione dell’attuale criterio di successo 4.1.1, è auspicabile (direi anzi 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 (Legge Europea sull’Accessibilità).
[
] [
]
[
]
[
]
] []
[]
[] 
