compliance
Normative UK sull'Accessibilità: Guida al PSBAR
Guida completa alle Public Sector Bodies Accessibility Regulations (PSBAR) del Regno Unito: chi deve conformarsi, cosa richiedono, l'applicazione e come soddisfare lo standard.
Cosa sono le Public Sector Bodies Accessibility Regulations del Regno Unito?
Le Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 — comunemente indicate come PSBAR, PSB Regulations, o semplicemente «le normative UK sull’accessibilità» — sono entrate in vigore nel settembre 2018. Recepiscono nel diritto britannico la direttiva UE sull’accessibilità del web (Web Accessibility Directive, WAD) e continuano ad applicarsi dopo la Brexit nell’ambito del sistema britannico di diritto UE trattenuto.
Il PSBAR richiede agli enti del settore pubblico di rendere accessibili i propri siti web e applicazioni mobili alle persone con disabilità. La conformità è misurata rispetto alle Web Content Accessibility Guidelines (WCAG) 2.1 Livello AA, e tutte le organizzazioni interessate sono tenute a pubblicare e mantenere una dichiarazione di accessibilità.
Chi deve conformarsi?
Il PSBAR si applica agli enti del settore pubblico come definiti dalle normative. Si tratta di una categoria ampia che include:
- Dipartimenti governativi centrali e agenzie esecutive
- Enti pubblici non dipartimentali (NDPB) e organismi indipendenti
- Autorità locali e consigli comunali
- Trust NHS ed enti sanitari
- Università e istituti di istruzione superiore (con alcune sfumature)
- Polizia, vigili del fuoco e altri servizi di emergenza
- Scuole statali e multi-academy trust
- Biblioteche, musei e istituzioni culturali gestite da enti pubblici
Le organizzazioni del settore privato non sono coperte dal PSBAR. Tuttavia, se un’azienda privata fornisce servizi digitali per conto di un ente del settore pubblico — ad esempio gestendo il portale dei pagamenti online di un consiglio comunale — l’ente pubblico resta responsabile di garantire che tali servizi siano accessibili.
Cosa significa «nell’ambito di applicazione» per i contenuti?
Le normative coprono tutti i siti web e le applicazioni mobili disponibili pubblicamente gestiti dagli enti del settore pubblico. Questo include intranet ed extranet dove sono accessibili al pubblico.
Tuttavia, diverse categorie di contenuti sono esplicitamente esentate:
- Formati di file da ufficio (PDF, documenti Word, foglio di calcolo) pubblicati prima del 23 settembre 2018, a meno che non siano necessari per usare un servizio
- Media basati sul tempo pre-registrati (video, audio) pubblicati prima del 23 settembre 2020
- Video in diretta (i sottotitoli live non sono obbligatori, sebbene la best practice sia fornirli quando possibile)
- Mappe online — a condizione che le informazioni di navigazione essenziali siano fornite in modo accessibile
- Contenuti di terze parti che l’ente del settore pubblico non finanzia, sviluppa o controlla
- Collezioni storiche e contenuti archiviati che non possono essere rese accessibili senza un onere sproporzionato
- Intranet ed extranet dove il contenuto precede settembre 2019 e non è stato sostanzialmente rivisto
L’esenzione per i file da ufficio storici è spesso mal interpretata. Si applica ai documenti pubblicati prima della data pertinente — non a tutti i PDF mai creati. Qualsiasi nuovo documento, o qualsiasi documento esistente aggiornato dopo la data di entrata in vigore, deve soddisfare lo standard.
Lo standard tecnico: WCAG 2.1 Livello AA
Il PSBAR richiede la conformità con le WCAG 2.1 Livello AA. Questo standard, pubblicato dal W3C, comprende 50 criteri di successo organizzati in quattro principi:
Percepibile — le informazioni e i componenti dell’interfaccia devono essere presentabili in modi che gli utenti possano percepire. I requisiti principali includono:
- Alternative testuali per i contenuti non testuali (immagini, icone, grafici)
- Sottotitoli per i contenuti video
- Contrasto cromatico sufficiente (4,5:1 per il testo normale, 3:1 per il testo grande e i componenti dell’interfaccia)
- Contenuto che può essere presentato in modi diversi senza perdere informazioni
Utilizzabile — i componenti dell’interfaccia e la navigazione devono essere utilizzabili. I requisiti principali includono:
- Piena accessibilità da tastiera — tutte le funzionalità devono funzionare senza mouse
- Nessuna trappola da tastiera
- Nessun contenuto che lampeggia più di tre volte al secondo
- Titoli di pagina, intestazioni e testo dei link descrittivi
- Un indicatore di focus visibile per la navigazione da tastiera
Comprensibile — il contenuto e l’interfaccia devono essere comprensibili. I requisiti principali includono:
- Lingua dichiarata nell’HTML (attributo
lang) - Navigazione ed etichettatura coerenti
- Messaggi di errore descrittivi con istruzioni per la correzione
- Etichette e istruzioni per tutti i campi dei moduli
Robusto — il contenuto deve essere sufficientemente robusto da poter essere interpretato dalle tecnologie assistive. I requisiti principali includono:
- HTML valido e ben strutturato
- Uso corretto di ruoli, stati e proprietà ARIA
- Messaggi di stato comunicati alle tecnologie assistive senza richiedere il focus
Le WCAG 2.1 hanno aggiunto 17 nuovi criteri di successo rispetto alle WCAG 2.0, con particolare attenzione all’accessibilità mobile, agli utenti ipovedenti e alle disabilità cognitive e dell’apprendimento. I nuovi criteri includono:
- 1.3.4 Orientamento — il contenuto non deve essere bloccato su un singolo orientamento dello schermo
- 1.3.5 Identificazione dello scopo dell’input — i campi dei moduli che raccolgono informazioni personali devono usare attributi di autocompletamento
- 1.4.10 Reflow — il contenuto deve ridisporsi a 320px senza scorrimento orizzontale
- 1.4.11 Contrasto non testuale — i componenti dell’interfaccia e gli oggetti grafici devono soddisfare un contrasto di 3:1
- 1.4.12 Spaziatura del testo — gli utenti devono poter regolare la spaziatura del testo senza perdita di contenuto
- 1.4.13 Contenuto al passaggio del mouse o al focus — il contenuto aggiuntivo attivato dal passaggio del mouse o dal focus deve essere eliminabile e persistente
- 2.5.3 Etichetta nel nome — i nomi accessibili dei componenti devono contenere l’etichetta testuale visibile
L’obbligo della dichiarazione di accessibilità
Uno degli obblighi più distintivi del PSBAR — e uno in cui molti enti del settore pubblico non sono all’altezza — è la dichiarazione di accessibilità obbligatoria.
Ogni sito web e applicazione mobile nell’ambito di applicazione deve pubblicare una dichiarazione di accessibilità che:
- Indichi quale standard il sito si propone di soddisfare — tipicamente WCAG 2.1 AA
- Elenchi i problemi di accessibilità noti — barriere specifiche identificate e non ancora risolte, con una descrizione di ciascuna
- Includa una dichiarazione di onere sproporzionato (se applicabile) — una giustificazione documentata del motivo per cui alcuni contenuti non sono stati rese accessibili
- Fornisca un meccanismo di feedback — un modo per gli utenti di contattare l’organizzazione per segnalare barriere di accessibilità o richiedere alternative accessibili
- Indichi la procedura di applicazione — indirizzando gli utenti non satisfatti della risposta all’organismo di applicazione competente
- Mostri la data di revisione — quando la dichiarazione è stata aggiornata l’ultima volta
Il Government Digital Service (GDS) pubblica un modello standard di dichiarazione di accessibilità. Gli enti del settore pubblico sono incoraggiati (e in pratica ci si aspetta) a usare questo modello o uno che copra tutti gli elementi richiesti.
Errori comuni nelle dichiarazioni di accessibilità:
- Affermare la piena conformità WCAG 2.1 AA senza prove
- Non elencare problemi noti quando chiaramente esistono
- Fornire un meccanismo di contatto che è esso stesso inaccessibile
- Pubblicare una dichiarazione non revisionata da oltre un anno
- Usare una dichiarazione generica copiata da un’altra organizzazione senza personalizzarla per il sito effettivo
Una dichiarazione di accessibilità che travisa la conformità non è solo non conforme — mina la fiducia degli utenti e crea un rischio reputazionale quando le barriere effettive vengono segnalate.
Onere sproporzionato
Il PSBAR consente agli enti del settore pubblico di richiedere un’esenzione per onere sproporzionato per contenuti specifici dove il costo o lo sforzo di renderli accessibili sarebbe sproporzionato rispetto al beneficio per gli utenti con disabilità. Non è un’esenzione generale e deve essere applicata a contenuti specifici e identificati — non a un intero sito web.
Per richiedere l’onere sproporzionato, l’organizzazione deve:
- Condurre una valutazione formale che pesi i costi di rendere il contenuto accessibile rispetto al beneficio per gli utenti con disabilità
- Considerare le dimensioni, le risorse dell’organizzazione e la natura del contenuto
- Documentare la valutazione
- Dichiarare la richiesta nella dichiarazione di accessibilità, identificando il contenuto e la base della richiesta
- Rivedere periodicamente la richiesta
Le linee guida del GDS sono chiare sul fatto che l’onere sproporzionato non può essere usato per evitare di rendere accessibili i percorsi utente principali. Richiedere l’onere sproporzionato per un modulo di pagamento o una richiesta di servizio non sarebbe considerato valido.
L’applicazione nel Regno Unito
L’applicazione del PSBAR è gestita diversamente dal contenzioso sull’accessibilità negli Stati Uniti. Il Regno Unito non ha un diritto di azione privata analogo all’ADA Title III per l’accessibilità dei siti web. Invece, l’applicazione è strutturata intorno a:
Monitoraggio del Government Digital Service (GDS) — il GDS è responsabile del monitoraggio della conformità degli enti del settore pubblico al PSBAR. Conducono audit a campione di siti web e applicazioni mobili, e riportano i risultati di conformità alla Commissione Europea (per i periodi di rendicontazione pre-Brexit) e ora nell’ambito degli obblighi trattenuti dal Regno Unito.
Il Cabinet Office supervisiona il quadro generale di conformità, incluso il requisito che i dipartimenti abbiano piani di accessibilità.
L’Equality Act 2010 fornisce una via parallela. L’Equality Act richiede ai fornitori di servizi (inclusi gli enti del settore pubblico) di apportare accomodamenti ragionevoli per le persone con disabilità. Un sito web del settore pubblico con barriere di accessibilità che impedisce a una persona con disabilità di accedere ai servizi può costituire discriminazione illegale ai sensi della legge. A differenza del PSBAR, l’Equality Act supporta le azioni individuali — gli utenti con disabilità possono presentare ricorsi a un tribunale del lavoro o a una corte di contea.
Ofcom gestisce l’applicazione per i requisiti relativi alla trasmissione. La Financial Conduct Authority (FCA) e altri organismi di regolamentazione settoriali possono anche applicare aspettative di accessibilità specifiche del settore.
In pratica, l’applicazione del PSBAR è stata relativamente leggera — il GDS pubblica dati di conformità e si impegna con le organizzazioni per migliorare, piuttosto che perseguire azioni di applicazione formali. Tuttavia, questo non riduce l’obbligo legale, e le azioni ai sensi dell’Equality Act rimangono un rischio reale.
Situazione post-Brexit
Il PSBAR è stato recepito dalla direttiva UE sull’accessibilità del web nell’ambito dell’European Communities Act. Dopo la Brexit, è mantenuto come diritto interno britannico ai sensi del Retained EU Law (Revocation and Reform) Act 2023. Le normative restano interamente in vigore; dopo la Brexit, il Regno Unito non è più obbligato a seguire gli aggiornamenti della WAD dell’UE o dello standard armonizzato EN 301 549, ma le WCAG 2.1 AA rimangono lo standard tecnico applicabile.
Le organizzazioni che operano sia nel Regno Unito che nell’UE devono conformarsi sia al PSBAR sia alle relative implementazioni della direttiva sull’accessibilità del web da parte degli stati membri dell’UE — che fanno anch’esse riferimento alle WCAG 2.1 AA, creando allineamento in pratica.
Applicazioni mobili
Il PSBAR si applica alle applicazioni mobili così come ai siti web. Le app mobili gestite da enti del settore pubblico devono:
- Soddisfare i criteri di successo delle WCAG 2.1 Livello AA applicabili alle app mobili native
- Avere una dichiarazione di accessibilità (che può essere pubblicata sul web, all’interno dell’app o nella scheda dell’app store)
- Essere compatibili con le funzioni di accessibilità della piattaforma (VoiceOver su iOS, TalkBack su Android)
L’accessibilità mobile è valutata rispetto allo standard EN 301 549, che incorpora le WCAG 2.1 e aggiunge requisiti specifici per il mobile riguardanti la dimensione dei target tattili, l’orientamento e l’uso delle API della piattaforma.
Una roadmap pratica per la conformità al PSBAR
1. Verifica la tua conformità attuale
Inizia con una valutazione onesta di dove ti trovi. Gli strumenti di scansione automatizzata possono identificare rapidamente una parte significativa dei problemi WCAG — problemi di contrasto cromatico, testo alternativo mancante, problemi di etichettatura dei moduli. Ma gli strumenti automatizzati rilevano in modo affidabile solo il 30–40% dei problemi di accessibilità. Un audit manuale di accessibilità che utilizza screen reader e navigazione solo da tastiera è essenziale per un quadro completo.
2. Dai priorità alle tue correzioni
Correggi prima le barriere che impediscono più direttamente agli utenti di accedere ai servizi principali. Per un consiglio comunale locale, questo potrebbe essere: il portale delle domande di pianificazione, il modulo per i sussidi abitativi, la pagina di contatto e la navigazione principale. Affronta i percorsi transazionali prima del contenuto informativo.
3. Pubblica una dichiarazione di accessibilità conforme
Usa il modello del GDS. Sii onesto sui problemi noti. Fornisci un meccanismo di contatto funzionante. Se stai richiedendo un onere sproporzionato per qualsiasi contenuto, documenta la valutazione e dichiaralo chiaramente.
4. Correggi e ritesta
Dopo ogni correzione, verifica che la soluzione risolva il problema e non abbia introdotto regressioni. Questo richiede sia un nuovo test automatizzato sia una verifica manuale con tecnologia assistiva.
5. Integra l’accessibilità nel tuo flusso di pubblicazione
Ogni nuova pagina pubblicata, ogni documento caricato, ogni funzionalità distribuita può introdurre nuove barriere. La formazione sulla gestione dei contenuti, le liste di controllo pre-pubblicazione e la scansione automatizzata nel flusso di pubblicazione individuano i problemi prima che raggiungano gli utenti.
6. Rivedi la tua dichiarazione di accessibilità annualmente
La dichiarazione deve riflettere lo stato attuale del tuo sito. Una revisione annuale — combinata con un audit aggiornato — la mantiene precisa e dimostra un impegno continuo.
Riepilogo
Il PSBAR è un obbligo legale vincolante per gli enti del settore pubblico del Regno Unito. Richiede la conformità alle WCAG 2.1 Livello AA su siti web e applicazioni mobili, e impone una dichiarazione di accessibilità accurata e aggiornata per ogni sito nell’ambito di applicazione.
Le normative non sono linee guida aspirazionali — sono legge, rafforzata dal dovere dell’Equality Act 2010 di apportare accomodamenti ragionevoli. Gli enti del settore pubblico che trattano l’accessibilità come una pratica di qualità continua, piuttosto che una casella di conformità da spuntare, troveranno più facile soddisfare lo standard, rispondere al monitoraggio del GDS e servire l’intera gamma dei loro utenti.
Se gestisci un sito web del settore pubblico e non sei sicuro della tua posizione di conformità attuale, una scansione di accessibilità gratuita è il primo passo più rapido. Per un audit completo mappato rispetto alle WCAG 2.1 AA e ai requisiti PSBAR, contatta il nostro team.
Verifica l'accessibilità del tuo sito del settore pubblico