Accessibilità
Progettare e sviluppare interfacce digitali significa decidere continuamente chi includere, o escludere, dall’esperienza di utilizzo e fruizione, a seconda delle proprie caratteristiche, conoscenze, capacità o condizioni di disabilità, temporanee o meno
FondamentiMetadati e link per approfondire
L’accessibilità al centro
Per realizzare servizi pubblici digitali semplici, accessibili e inclusivi
Abbiamo scelto di considerare l'accessibilità by design parte di ogni processo e risorsa del design system del Paese, non solo come un orizzonte ideale o una risposta alle norme. Nel design system trovi risorse quindi accessibili by default per PA e fornitori, da cui partire per realizzare siti e servizi facili da usare e inclusivi, con più efficacia, minor tempo e costi.
Per cambiare la visione dell’accessibilità: da adempimento a opportunità
Il design system del Paese, .italia, open source e in continuo aggiornamento, rende la progettazione di servizi pubblici digitali più efficiente.
Identità
La semplicità d’uso è il primo elemento distintivo dell’esperienza che i servizi digitali pubblici di qualità devono proiettare verso le persone.
Linee guida e criteri di successo
Il livello di conformità richiesto per i siti della Pubblica Amministrazione dalla norma tecnica europea armonizzata UNI CEI EN 301549:2021 (Requisiti di accessibilità per prodotti e servizi ICT), corrisponde ai livelli “A” e “AA” della W3C Recommendation WCAG 2.1.
I criteri di successo oggetto di verifica previsti nelle WCAG 2.1 consistono in istruzioni testabili che non dipendono dalla tecnologia utilizzata. I criteri sono divisi in tredici linee guida che forniscono gli obiettivi e che rispondono a loro volta a livello più alto ai quattro principi che fanno da pilastri all'accessibilità del Web.
Chiunque voglia utilizzare il Web deve disporre di contenuto che sia:
- Percepibile - Le informazioni e i componenti dell'interfaccia utente devono essere presentati agli utenti in modi in cui essi possano percepirli.
- Questo significa che gli utenti devono essere in grado di percepire le informazioni presentate (non possono essere invisibili a tutti i loro sensi).
- Utilizzabile - I componenti e la navigazione dell'interfaccia utente devono essere utilizzabili.
- Questo significa che gli utenti devono essere in grado di utilizzare l'interfaccia (l'interfaccia non può richiedere un'interazione che l'utente non è in grado di eseguire).
- Comprensibile - Le informazioni e le operazioni dell'interfaccia utente devono essere comprensibili.
- Questo significa che gli utenti devono essere in grado di comprendere le informazioni e il funzionamento dell'interfaccia utente (il contenuto o il funzionamento non possono essere al di là della loro comprensione).
- Robusto - Il contenuto deve essere abbastanza robusto per essere interpretato in maniera affidabile da una grande varietà di programmi utente, comprese le tecnologie assistive.
- Questo significa che gli utenti devono essere in grado di accedere ai contenuti con il progredire delle tecnologie (con l'evoluzione delle tecnologie e degli interpreti, i contenuti devono rimanere accessibili).
Nota sulle nuove WCAG 2.2
La nuova versione delle WCAG 2.2 è una W3C Recommendation dal 5 ottobre 2023 che dichiara la retrocompabilità con le WCAG 2.1, ossia un contenuto conforme alle WCAG 2.2 è conforme anche alle WCAG 2.1, attualmente obbligo normativo secondo la UNI CEI EN 310549:2021. Si consiglia pertanto, ove possibile, di lavorare già in ottica WCAG 2.2 per avere una conformità con la norma tecnica attuale e con i dettami della futura norma tecnica armonizzata di recepimento dell'European Accessibility Act.
Profili coinvolti nella cura dell'accessibilità
L’accessibilità è una qualità da curare e testare fin dal principio del progetto, e poi far evolvere nel tempo, al pari della redazione dei contenuti e della manutenzione tecnologica.
I profili coinvolti nella cura dell'accessibilità, oltre gli esperti di dominio che indirizzano e validano il lavoro, sono tutti quelli coinvolti nelle diverse fasi del progetto digitale: i responsabili progetto, dalla raccolta dei requisiti alla validazione di processi e risultati; i designer e gli sviluppatori nel realizzare e manutenere progetti accessibili by design, definendo processi che abilitino il miglioramento continuo e testando fin dall'inizio del progetto; la redazione curando i contenuti nel tempo.
È quindi importante che tutti i profili coinvolti approfondiscano le norme, le specifiche tecniche di riferimento e le buone pratiche sul tema accessibilità per il proprio ambito di competenza, con particolare attenzione a facilitare i passaggi di conoscenza tra le diverse fasi del progetto e tra le diverse competenze.
Il design system non è tutto
I «pezzi» del design system del Paese non sono tutto: l’accessibilità è principalmente una questione semantica, di significato degli elementi e dei comportamenti. L’utilizzo di componenti accessibili non rende automaticamente un applicativo accessibile, tuttavia sono un aiuto fondamentale per compiere by default un processo nel modo più ottimale possibile.
Il percorso costruito attraverso il design system del Paese è proprio incentrato sul concetto di accessibilità by default. Per ogni attività devono essere utilizzabili elementi, strutture, procedure, che sono già passati attraverso i necessari processi di validazione (documentazione, mockup, framework, template, ecc). Al termine del processo le attività di verifica e di ottimizzazione potranno essere più limitate, per poi liberare risorse per la gestione di casi più complessi o attivare supporti più innovativi.
Standard, open design e partecipazione
Processi e risorse per l'evoluzione del design system e del suo ecosistema di risorse
Lo stato di accessibilità dei componenti
Nelle schede di documentazione dei componenti è prevista una tabella che riporta quattro valutazioni soggettive sull'accessibilità del componente e delle sue varianti nel framework di sviluppo Bootstrap Italia:
- Visivamente accessibile - uso e contrasto colori, leggibilità
- Amichevole con i lettori di schermo - struttura titolazioni, etichette e testi alternativi
- Navigabile - focus, struttura, navigazione da tastiera o altri device
- Comprensibile - comprensibile, prevedibile, gestione semplice dell'errore
Per svolgere i test è possibile isolare l'anteprima del componente in una finestra dedicata, con il pulsante in alto a destra dell'anteprima. Questa funzionalità permette di giudicare le caratteristiche intrinseche del componente isolate dal contesto documentazione, semplificando la necessità di implementare ambienti di test ad hoc.
Per completare il passaggio della presente documentazione alle versioni stabili, è iniziato un nuovo ciclo completo di test che si svolgeranno tra Q1 e Q2 del 2024.
Workflow per migliorare lo sviluppo dei componenti
Abbiamo costruito un promemoria minimo e non esaustivo di attività e controlli da fare, per supportare l’integrazione e la revisione dei componenti del design system durante le attività di sviluppo. Il promemoria suggerisce come condurre alcune verifiche di accessibilità su componenti, pattern, e su proposte evolutive, per evidenziare criticità e opportunità durante le lavorazioni di sviluppo.
Per svolgere analisi di accessibilità è necessario coinvolgere esperti qualificati (es. Web Accessibility Expert) e, ogni qualvolta possibile, predisporre sessioni di test di usabilità con panel rappresentativi di utenti.
Il flusso di lavoro che segue prende a riferimento le implementazioni per il framework del design system Bootstrap Italia: è da considerare una traccia da seguire come aiuto allo sviluppo, rispetto al lavoro più completo da fare con gli esperti di dominio e con i test di usabilità.
Test validazione HTML
- Implementato nelle automazioni (CI/CD) del repository di Bootstrap Italia tramite HTMLProofer.
Test automatici
I test automatici di accessibilità possono essere condotti con molteplici soluzioni, sia generaliste che dedicate a particolari aspetti, e sono talvolta essenziali per l’individuazione di problematiche specifiche; va sottolineato tuttavia che tali soluzioni non sono soddisfacenti per una rilevazione efficace di numerose tipologie di criteri di successo.
Una lista esaustiva, ma non validata, di tali tecnologie è disponibile sul sito del W3C.
Le soluzioni "minime" suggerite per l'uso durante lo sviluppo sono:
- controllo codice durante la scrittura (eg. con axe-linter per VS Code, anche implementato nelle automazioni (CI/CD) di Bootstrap Italia);
- test condotti sul DOM in-browser con estensioni (a titolo di esempio):
- test condotti con script:
- Pa11y (implementato nelle automazioni (CI/CD) di Bootstrap Italia).
Test manuali
I test manuali sono una fase critica che richiede competenze in materia di accessibilità in chi la esegue. Il workflow che segue è utile per individuare durante lo sviluppo ad esempio errori nelle interazioni e nel labeling non rilevabili dai test automatici, ma non sostituisce il test manuale condotto da esperti qualificati.
Interazioni via tastiera
Da verificare anche rispetto ai pattern ARIA:
- Tab: si sposta sul successivo elemento focusable;
- Shift + Tab: si sposta sul precedente elemento focusable;
- Invio: attiva link, pulsanti e altri elementi interattivi;
- Spazio: attiva radio button, checkbox e pulsanti;
- Frecce: navigano i radio button e le opzioni di select e dropdown, e scrollano la pagina.
Alcune delle funzionalità da verificare durante i test:
- l'ordine di tab è logico;
- il focus è visibile;
- non sono presenti "keyboard traps";
- comportamento delle modali.
Ingrandimento
Supportare l'ingrandimento, nativo del browser, fino a 400% per viewport larghe 1280px, e laddove esistano elementi con scroll orizzontale, per viewport larghe 1024px.
Verificare assenza di:
- errori nel ridimensionamento testo;
- scroll orizzontale non desiderato (o verticale per elementi con scroll orizzontale);
- sovrapposizioni;
- tagli di contenuto;
- perdita di funzionalità.
Lettore di schermo (screen reader)
Sono disponibili diversi screen reader a seconda del sistema operativo utilizzato. In Europa lo screen reader più utilizzato è l’open source NVDA, seguito da JAWS (a pagamento) e VoiceOver (integrato nei sistemi operativi Apple). Il browser più utilizzato è Chrome, seguito da Edge e Safari. Dovendo individuare una soluzione unica per il test durante le lavorazioni, la combinazione suggerita è Windows+Chrome+Jaws.
Controlli da eseguire:
- controllo sequenza lettura;
- controllo etichette (label, label nascoste, label ARIA) e ruoli degli elementi;
- controllo elementi interattivi;
- controllo struttura e gerarchia titolazioni (heading), in special modo nei template di pagina;
- controllo testi alternativi (alt text);
- controllo annuncio cambi dinamici del DOM (aria-live).