L’accessibilità web di basa su quattro principi detti POUR ed è fatta di tecniche e approcci che hanno a che fare con la progettazione grafica, la scrittura di codice, il linguaggio e molti altri aspetti di un prodotto digitale, come un sito web o una web app.
Esistono degli standard internazionali, le Web Content Accessibility Guidelines (WCAG), che definiscono le regole da seguire perché un sistema risulti accessibile.
Le WCAG si basano su quattro principi, che vengono utilizzati anche nella nomenclatura di ogni linea guida: i cosiddetti principi POUR.
Cosa significa POUR?
POUR è un’acronimo inglese che sta per: Perceivable, Operable, Understandable, Robust.
Nello specifico, i quattro principi dicono quanto segue:
- Perceivable (percepibile): i contenuti e gli elementi dell’interfaccia devono essere presentati in modi che gli utenti possano percepirli con i loro sensi (vista, udito, tatto, ecc.).
- Operable (operabile): tutte le funzionalità e la navigazione devono essere facilmente utilizzabili da qualsiasi utente, indipendentemente dal dispositivo o metodo di input.
- Understandable (comprensibile): le informazioni e il funzionamento dell’interfaccia devono essere chiaramente comprensibili.
- Robust (robusto): i contenuti devono essere interpretabili in modo affidabile da una vasta gamma di tecnologie (browser, lettori schermo, assistive tech).
Se ci pensi, sono gli stessi principi che si seguono nel UX/UI design e nello Human-centered design, infatti user experience e accessibilità sono argomenti strettamente legati fra loro, in quanto hanno un obiettivo comune: mettere al centro della progettazione e dello sviluppo le persone che devono usare l’interfaccia. Tutte le persone.
I 4 principi vengono usati nell’organizzazione delle WCAG ma non devi vederli come argomenti separati fra loro: ognuno di questi principi è importante per creare siti web e web application senza barriere.
Esempi pratici
Per farti capire meglio questi quattro principi, ecco alcuni esempi pratici di WCAG.
Perceivable
Queste linee guida riguardano il modo in cui il contenuto viene percepito dall’utente, e servono a far sì che il contenuto possa essere fruito anche nel caso di impedimenti.
La WCAG 1.4.3 Contrasto (minimo) è probabilmente la più famosa ed è una delle linee guida più importanti nell’accessibilità dei testi (se vuoi approfondire, puoi leggere il post Oltre il contrasto: guida definitiva all’accessibilità dei testi).
Questa linea guida stabilisce che i testi devono avere un rapporto di contrasto minimo, rispetto al colore di fondo, di almeno 4.5:1, a meno che il testo non sia più grande di 18 punti o 14 punti nel caso di grassetto, in questi due casi il rapporto di contrasto richiesto scende a 3:1 – ma io preferisco attenermi sempre a un contrasto più alto e applico il rapporto 4,5:1 a tutti i testi.
Un’altra linea guida molto importante ma spesso non rispettata è la 1.1.1 Alternative testuali, secondo la quale i contenuti non testuali (immagini e icone, per esempio) che non sono puramente decorative, devono avere un’alternativa testuale che ne spieghi il contenuto. La tecnica più usata è l’alt text, ovvero un attributo HTML da aggiungere all’immagine che descrive l’elemento, utile ad esempio per utenti con impedimenti visivi che usano screen reader.
Operable
Può sembrare scontato, ma un’interfaccia deve essere utilizzabile.
Dico che sembra scontato, perché spesso pensiamo che gli utenti utilizzino il sito nello stesso modo in cui lo facciamo noi.
Indovina un po’: non è così!
Bisogna tenere conto del fatto che utenti diversi possono usare un’interfaccia in modi diversi dal nostro.
Esempio classico: la tastiera.
Un utente con impedimenti all’uso del mouse o del trackpad possono preferire muoversi nella pagina e interagire con essa usando solo la tastiera, in particolare usando i tasti TAB e SHIFT + TAB, le frecce direzionali, la barra spaziatrice e il tasto INVIO.
La WCAG 2.1.1 Tastiera parla proprio di questo: tutte le funzionalità devono poter essere utilizzate solo da tastiera.
Per questo motivo uno dei test di accessibilità che ti consiglio di fare sempre è mollare mouse e trackpad e usare il tuo sito web solo con la tastiera. In questo modo capirai se il focus viene attivato correttamente, se tutti i bottoni e i link possono essere attivati e disattivati senza problemi, se puoi chiudere una modale usando il tasto ESC e se puoi muoverti fra i pannelli di un componente a tabs usando le frecce direzionali.
Understandable
Questo principio è molto legato alle buone pratiche di user experience, se hai familiarità con le euristiche di Nielsen scoprirai che ci sono molti punti in comune.
Una delle mie WCAG preferite è la 3.3.3 Suggerimenti per gli errori, secondo cui quando l’utente compie un errore il sistema non deve limitarsi a segnalare l’errore, ma se possibile suggerire anche uno o più modi per risolverlo.
Mi ricorda molto l’euristica 9 di Nielsen: “Aiuta gli utenti a riconoscere, diagnosticare ed uscire dalle situazioni di errore”!
Dunque l’accessibilità web non riguarda solo codice HTML e CSS, ma anche linguaggio e comunicazione.
Robust
Le WCAG legate al quarto principio sono pochissime ma molto tecniche, perché servono a fare in modo che l’interfaccia venga interpretata correttamente da una moltitudine di tecnologie diverse, comprese le tecnologie assistive come gli screen reader.
La WCAG a cui darei priorità in questo senso è la 4.1.2 Nome, ruolo, valore, che stabilisce che gli elementi della pagina devono avere sempre questi tre elementi (un nome, un ruolo o role e un valore).
Immagina un bottone che serve a creare un nuovo articolo del blog.
Per essere correttamente interpretato, ha bisogno di queste informazioni:
- Nome: per esempio il testo “Nuovo articolo” inserito dentro il tag <button> oppure nell’attributo aria-label
- Ruolo: usando il tag <button> il ruolo implicito dell’elemento sarà quello di “button”. Se per qualche motivo non è possibile usare quel tag, allora si può aggiungere l’attributo aria role=”button”
In alcuni elementi interattivi come gli input di un form, i checkbox o i radio, esiste anche il value, ovvero deve essere possibile capire programmaticamente se un certo campo è stato compilato e se il checkbox o il radio sono attivati o disattivati. Questo perché una persona con impedimenti visivi, ad esempio, non può capire se un checkbox è attivo basandosi sul suo aspetto grafico.
Conclusioni sui 4 principi di accessibilità web
L’accessibilità web non si basa solamente su codice HTML e CSS, ma anche su aspetto visivo, linguaggio, comunicazione, user experience.
Le WCAG sono il punto di riferimento da seguire per rendere un sito web accessibile e sono divise in quattro macro sezioni che identificano i principi POUR, ovvero i pilastri dell’accessibilità dei contenuti web.
Vuoi imparare di più sull’accessibilità web senza impazzire fra normative e documentazione tecnica? Dai un’occhiata al Libro Switch on: Accessibilità, una guida pratica da web designer a web designer che spiega come applicare le regole di accessibilità fin dalla progettazione grafica di un sito web!