Come rendere un sito web accessibile: guida completa a WCAG, POUR, ARIA e accessibilità web

Rendere un sito web accessibile non significa semplicemente aggiungere un attributo alt alle immagini, aumentare il contrasto dei colori o verificare che il sito funzioni con il tasto Tab.

L’accessibilità web è un tema molto più ampio: riguarda il modo in cui un sito viene progettato, sviluppato, scritto, testato e mantenuto.

Un sito accessibile dovrebbe permettere al maggior numero possibile di persone di percepire i contenuti, comprendere le informazioni, navigare tra le pagine e utilizzare le funzionalità disponibili, anche quando l’utente utilizza una tecnologia assistiva o presenta una disabilità.

Esiste però una distinzione che considero fondamentale e che dovrebbe essere alla base di qualsiasi progetto di accessibilità:

La conformità alla normativa è un requisito. L’accessibilità dovrebbe essere un criterio di progettazione.

Un sito può infatti essere conforme a determinati requisiti tecnici e avere comunque un’esperienza poco piacevole, poco intuitiva o inutilmente difficile da utilizzare.

In questa guida vedremo quindi come rendere un sito web accessibile, partendo dalle basi e arrivando agli aspetti più tecnici: WCAG, livelli A e AA, principi POUR, HTML semantico, ARIA, immagini e alt text, tipografia, contrasto, tastiera, focus, moduli, multimedia, responsive design, test automatici e manuali, Legge Stanca, European Accessibility Act e ruolo dei Web Accessibility Expert.

L’obiettivo non è soltanto capire come superare un controllo di conformità, ma capire come progettare un sito che funzioni davvero per le persone.

Cosa significa rendere un sito web accessibile?

Un sito web accessibile è un sito progettato in modo da ridurre le barriere che possono impedire alle persone di accedere alle informazioni o utilizzare le funzionalità disponibili.

Quando si parla di accessibilità si pensa spesso esclusivamente alle persone con disabilità permanenti. È sicuramente una parte fondamentale del problema, ma l’accessibilità riguarda situazioni molto più ampie.

Una persona può avere una disabilità visiva e utilizzare uno screen reader. Una persona con una disabilità motoria può navigare esclusivamente tramite tastiera o altri dispositivi di input. Una persona con una disabilità uditiva può avere bisogno dei sottotitoli.

Ma anche una persona senza una disabilità permanente può incontrare temporaneamente una barriera:

• un braccio immobilizzato può rendere difficile utilizzare il mouse;
• un ambiente molto rumoroso può impedire di ascoltare un video;
• una connessione lenta può rendere inutilizzabile un’interfaccia che dipende completamente da contenuti dinamici;
• la luce diretta del sole può rendere difficile leggere un testo con poco contrasto;
• la stanchezza o la difficoltà di concentrazione possono rendere particolarmente frustrante un’interfaccia complessa.

Per questo l’accessibilità non dovrebbe essere vista come una caratteristica destinata a una piccola percentuale di utenti.

Un’interfaccia accessibile tende semplicemente a essere più robusta e più utilizzabile per tutti.

Accessibilità e conformità non sono la stessa cosa

Questo è il concetto più importante da chiarire.

Le Web Content Accessibility Guidelines, meglio conosciute come WCAG, forniscono criteri tecnici utilizzabili per valutare l’accessibilità dei contenuti web.

Le WCAG definiscono tre livelli di conformità: A, AA e AAA. Il livello AA comprende tutti i criteri di livello A e tutti quelli di livello AA.

In molti contesti normativi il livello AA rappresenta il riferimento più utilizzato. In Italia, per i soggetti e gli strumenti informatici rientranti nell’ambito della normativa sull’accessibilità, i requisiti tecnici fanno riferimento anche alle WCAG 2.1 e alla norma tecnica EN 301 549.

Ma questo non significa che:

WCAG 2.1 AA = sito perfettamente accessibile.

Le WCAG sono uno standard fondamentale, ma non rappresentano l’intero concetto di buona progettazione inclusiva.

Faccio un esempio molto semplice: la scelta del carattere tipografico.

Possiamo scegliere un font che rispetta i requisiti tecnici relativi al contrasto e alla presentazione del testo e che quindi non ci crea necessariamente un problema di conformità, ma che risulta comunque difficile o fastidioso da leggere.

Se scelgo quel font perché “le WCAG non lo vietano”, sto ragionando in termini di conformità.

Se invece mi chiedo “questo carattere è realmente leggibile dalle persone che dovranno leggere questa pagina?”, sto ragionando in termini di accessibilità.

La conformità dovrebbe essere il punto di partenza, non il punto di arrivo.

Cosa sono le WCAG?

Le WCAG, Web Content Accessibility Guidelines, sono le linee guida internazionali per l’accessibilità dei contenuti web sviluppate dal W3C, il World Wide Web Consortium.

Le WCAG non sono una semplice lista di “trucchi” da applicare a un sito. Sono organizzate in una struttura composta da:

• 4 principi fondamentali;
• 13 linee guida;
• criteri di successo verificabili;
• tecniche e documentazione di supporto.

Le quattro fondamenta delle WCAG sono i principi POUR: Perceivable, Operable, Understandable e Robust.

Questi quattro principi rappresentano il punto di partenza per comprendere l’accessibilità web e verranno approfonditi più avanti in questa guida.

WCAG 2.1 e WCAG 2.2

Le WCAG 2.2 sono la versione più recente delle WCAG. Il W3C raccomanda l’utilizzo della versione più recente, mentre WCAG 2.2 mantiene la compatibilità con WCAG 2.1.

Questo è importante anche per chi lavora in Italia: quando una specifica normativa, un contratto o un requisito di progetto richiede espressamente WCAG 2.1, bisogna rispettare quel riferimento. Quando invece si sta progettando un nuovo sito senza un vincolo specifico, è opportuno conoscere anche i criteri introdotti da WCAG 2.2.

Tra le novità di WCAG 2.2 troviamo criteri relativi, tra le altre cose, alla visibilità del focus, ai movimenti di trascinamento, alla dimensione dei target, all’autenticazione accessibile e alla gestione delle informazioni ridondanti.

I livelli A, AA e AAA

Le WCAG classificano i criteri di successo in tre livelli di conformità: A, AA e AAA.

Livello A

È il livello minimo di conformità e comprende i criteri considerati fondamentali per evitare alcune delle barriere più importanti.

Un sito che non rispetta un criterio di livello A presenta quindi una non conformità rispetto a quel requisito.

Livello AA

Comprende tutti i criteri di livello A e tutti quelli di livello AA.

È il livello di riferimento più comune nei progetti professionali e nei contesti normativi che richiedono conformità alle WCAG.

Quando si sente dire che un sito deve essere “WCAG AA”, quindi, significa che deve soddisfare sia i criteri A sia quelli AA applicabili.

Livello AAA

Comprende anche i criteri AAA.

È il livello più elevato, ma non dovrebbe essere interpretato come un requisito generale per qualsiasi sito. Le stesse WCAG spiegano che non è sempre possibile soddisfare tutti i criteri AAA per determinati contenuti.

Raggiungere il livello AA, quindi, non significa che non esista più nulla da migliorare.

Questo è il concetto alla base di questa guida: la conformità a uno standard non dovrebbe essere confusa con la qualità complessiva dell’esperienza.

WCAG e accessibilità: qual è il livello da raggiungere?

Le WCAG definiscono tre livelli di conformità:

• Livello A: rappresenta il livello minimo di conformità;
• Livello AA: aggiunge ulteriori requisiti ed è il livello comunemente utilizzato come riferimento per molti progetti e requisiti normativi;
• Livello AAA: rappresenta un livello ancora più elevato, ma non è generalmente realistico richiedere che un intero sito soddisfi tutti i criteri AAA.

Quando si parla di un sito “conforme alle WCAG 2.1 livello AA”, quindi, si sta indicando un preciso insieme di criteri di successo soddisfatti secondo le regole di conformità delle WCAG.

Ma anche in questo caso è importante non confondere la frase “conforme alle WCAG 2.1 AA” con “perfettamente accessibile per chiunque”.

Le WCAG sono uno standard fondamentale, ma l’accessibilità reale dipende anche dal contesto, dalle persone, dai contenuti, dalle tecnologie utilizzate e dalla qualità dell’implementazione.

WCAG 2.1 o WCAG 2.2?

Un’altra domanda frequente riguarda la versione delle WCAG.

Le WCAG 2.2 sono l’evoluzione delle WCAG 2.1 e introducono nuovi criteri di successo e alcune modifiche rispetto alla versione precedente.

Tra le novità troviamo, per esempio, criteri relativi alla visibilità del focus, alla dimensione dei target di interazione, all’autenticazione accessibile e ad altri aspetti dell’esperienza utente.

Quando si parla di conformità legale, però, non bisogna scegliere autonomamente una versione delle WCAG soltanto perché è quella più recente.

È necessario verificare quale standard e quale versione siano effettivamente richiamati dalla normativa applicabile al progetto.

Dal punto di vista progettuale, invece, non vedo alcun motivo per fermarsi volontariamente a una versione precedente quando una buona pratica più recente può migliorare l’esperienza delle persone.

Se una soluzione rende il sito più accessibile, più chiaro e più facile da utilizzare, perché non adottarla?

I principi POUR: la base dell’accessibilità web

I quattro principi POUR aiutano a capire cosa significa rendere un contenuto accessibile anche prima di entrare nei singoli criteri tecnici.

• Perceivable – Percepibile
• Operable – Utilizzabile
• Understandable – Comprensibile
• Robust – Robusto

Puoi approfondire questo argomento nel mio articolo dedicato ai principi POUR dell’accessibilità web.

1. Perceivable: percepibile

Le informazioni e i componenti dell’interfaccia devono poter essere percepiti dagli utenti.

Un’immagine informativa, per esempio, deve avere un’alternativa testuale appropriata. Un video può richiedere sottotitoli. Un’informazione non dovrebbe essere comunicata esclusivamente attraverso il colore.

La domanda da porsi è:

Se una persona non può percepire questo contenuto nel modo in cui lo sto presentando, esiste un’alternativa?

2. Operable: utilizzabile

Gli elementi dell’interfaccia devono poter essere utilizzati.

Questo significa, tra le altre cose, che il sito non dovrebbe dipendere esclusivamente dal mouse.

Menu, link, pulsanti, modali, tab, form e altri componenti devono poter essere utilizzati con modalità di input accessibili e, quando richiesto, tramite tastiera.

La domanda da porsi è:

Posso completare le attività importanti anche senza utilizzare il mouse?

3. Understandable: comprensibile

Il contenuto e il comportamento dell’interfaccia devono essere comprensibili.

Un form dovrebbe fornire istruzioni chiare. Un errore dovrebbe spiegare cosa è successo e come correggerlo. La navigazione dovrebbe essere prevedibile.

La comprensibilità riguarda quindi sia il contenuto sia l’interfaccia.

4. Robust: robusto

Il contenuto dovrebbe poter essere interpretato in modo affidabile da diversi browser, dispositivi e tecnologie assistive.

Qui diventa fondamentale la qualità del codice: HTML semantico, struttura corretta e utilizzo appropriato di ARIA contribuiscono alla robustezza dell’interfaccia.

In altre parole, non dovremmo progettare un’interfaccia che funziona soltanto in una determinata combinazione di browser, dispositivo e modalità di interazione.

Un sito robusto deve essere in grado di comunicare correttamente la propria struttura e il proprio comportamento anche a tecnologie diverse da quelle che abbiamo utilizzato durante lo sviluppo.

HTML semantico: l’accessibilità comincia dal codice

Uno degli errori più frequenti è pensare che l’accessibilità possa essere aggiunta a un sito alla fine del progetto.

In realtà, una parte importante dell’accessibilità nasce direttamente dall’HTML.

Un pulsante dovrebbe essere un vero pulsante:

<button type="button">Apri il menu</button>

Un link dovrebbe essere un vero link:

<a href="/contatti">Contattaci</a>

Un titolo dovrebbe essere un vero heading:

<h2>I nostri servizi</h2>

Al contrario, costruire tutto con div e span e poi cercare di ricostruire tramite JavaScript il comportamento degli elementi nativi significa creare complessità inutile.

Quando HTML offre già un elemento che descrive semanticamente ciò che vogliamo creare, è quasi sempre preferibile utilizzare quell’elemento.

Struttura semantica della pagina

Una pagina accessibile non dovrebbe essere costruita soltanto pensando all’aspetto visivo.

La struttura HTML deve comunicare la gerarchia dei contenuti.

Per esempio:

<h1>Come rendere un sito web accessibile</h1>

<h2>Cosa sono le WCAG</h2>

<h2>I principi POUR</h2>

<h3>Perceivable</h3>
<h3>Operable</h3>
<h3>Understandable</h3>
<h3>Robust</h3>

Gli heading non servono quindi soltanto a rendere una porzione di testo più grande o più evidente.

Devono rappresentare la gerarchia logica dei contenuti.

Una persona che utilizza uno screen reader può utilizzare gli heading per orientarsi rapidamente all’interno della pagina. Se utilizziamo semplicemente dei div stilizzati come titoli, questa informazione strutturale viene persa.

Allo stesso modo, è importante utilizzare gli elementi semantici HTML5 quando descrivono realmente la funzione di una determinata area:

<header>
    ...
</header>

<nav>
    ...
</nav>

<main>
    ...
</main>

<aside>
    ...
</aside>

<footer>
    ...
</footer>

Questi elementi aiutano a comunicare la struttura della pagina sia al browser sia alle tecnologie assistive.

Cosa sono ARIA e WAI-ARIA?

ARIA, acronimo di Accessible Rich Internet Applications, è un insieme di attributi che permette di fornire informazioni aggiuntive alle tecnologie assistive quando il normale HTML non è sufficiente a descrivere correttamente un’interfaccia.

Per esempio:

<button aria-expanded="false">
    Menu
</button>

L’attributo aria-expanded può comunicare lo stato di un componente espandibile.

Oppure:

<nav aria-label="Navigazione principale">
    ...
</nav>

può aiutare a identificare quella specifica area di navigazione.

La regola più importante di ARIA

ARIA è molto potente, ma esiste una regola fondamentale:

Non utilizzare ARIA per sostituire HTML quando HTML è già sufficiente.

Per esempio:

<div role="button">Invia</div>

non dovrebbe essere la soluzione preferita quando possiamo utilizzare:

<button>Invia</button>

Il primo elemento richiede molto più lavoro per replicare correttamente il comportamento del secondo.

Un vero <button> possiede già una semantica conosciuta dal browser, è raggiungibile da tastiera e presenta comportamenti nativi che non dobbiamo ricostruire manualmente.

Al contrario, un div con role="button" non diventa automaticamente un pulsante completamente accessibile. Potrebbe essere necessario gestire manualmente focus, tastiera, eventi e altri comportamenti.

La regola pratica è quindi:

HTML nativo prima. ARIA quando serve.

Nome accessibile: cosa deve sapere una tecnologia assistiva?

Ogni controllo interattivo dovrebbe avere un nome accessibile che permetta all’utente di capire quale sia la sua funzione.

Un pulsante con un’icona può essere perfettamente comprensibile visivamente, ma non necessariamente lo sarà per una persona che utilizza uno screen reader.

Per esempio:

<button type="button" aria-label="Chiudi">
    <svg aria-hidden="true">
        ...
    </svg>
</button>

In questo caso l’icona viene nascosta alle tecnologie assistive e il nome accessibile del pulsante viene fornito attraverso aria-label.

Naturalmente, se il pulsante contiene già un testo visibile sufficientemente descrittivo, non è necessario aggiungere un aria-label ridondante.

Anche in questo caso vale la regola di fondo: utilizzare ARIA per comunicare informazioni che altrimenti andrebbero perse, non per aggiungere attributi senza una reale necessità.

Come rendere le immagini accessibili: l’importanza dell’alt text

Le immagini sono uno degli elementi più importanti da rendere accessibili.

Quando un’immagine trasmette un’informazione che l’utente deve poter comprendere, quella informazione deve essere disponibile anche in una forma alternativa.

È qui che entra in gioco l’alt text, cioè il testo alternativo dell’immagine.

Un esempio:

<img src="grafico-vendite.jpg"
     alt="Grafico che mostra una crescita delle vendite del 35% nel 2025">

Il testo alternativo non dovrebbe descrivere necessariamente ogni dettaglio visibile nell’immagine.

Deve comunicare il significato che quell’immagine ha nel contesto della pagina.

Evita alt text inutili

Descrizioni come:

alt="immagine"

oppure:

alt="foto"

non aiutano l’utente.

Se l’utente utilizza uno screen reader, sentirà già che sta incontrando un’immagine. Il valore dell’alt text consiste nel fornire l’informazione che l’immagine comunica.

Per approfondire questo argomento tu consiglio di leggere l’articolo completo Alt text nelle immagini: guida definitiva per capire quando serve (e quando è meglio lasciarlo vuoto).

La leggibilità dei testi è parte dell’accessibilità

Uno dei miei punti di vista sull’accessibilità è proprio questo: non dobbiamo limitarci a ciò che è esplicitamente richiesto da un criterio di conformità.

La tipografia ne è un esempio perfetto.

Quando scegliamo un font per un sito web dovremmo chiederci:

È leggibile?

e non soltanto:

Rispetta i requisiti WCAG?

La leggibilità dipende da moltissimi fattori:

• forma delle lettere;
• dimensione del carattere;
• peso del font;
• contrasto;
• lunghezza delle righe;
• altezza della linea;
• spaziatura;
• gerarchia tipografica;
• utilizzo del corsivo;
• uso delle maiuscole;
• rendering sui diversi dispositivi.

Un testo può quindi rispettare alcuni requisiti tecnici e risultare comunque scomodo da leggere. Per questo, nella progettazione accessibile, la domanda non dovrebbe essere soltanto “questo testo è conforme?”, ma anche “questo testo è realmente facile da leggere?”.

Non basta rispettare i requisiti di contrasto minimo, devi tenere in considerazione anche interlinea, tipo di font selezionato, spaziatura e altri aspetti che aiutano a migliorare la leggibilità del testo.

Per approfondire le buone pratiche per rendere un testo leggibile puoi leggere l’articolo Come rendere i testi di un sito web accessibili: contrasto, font, spaziatura.

Non comunicare le informazioni soltanto attraverso il colore

Il colore può essere utilizzato per rafforzare un’informazione, ma non dovrebbe essere l’unico modo attraverso cui quell’informazione viene comunicata.

Un esempio classico è un form in cui i campi obbligatori vengono indicati esclusivamente con il colore rosso.

Una persona che non distingue correttamente i colori potrebbe non comprendere quali campi siano obbligatori.

È quindi preferibile utilizzare anche un’indicazione testuale o un altro elemento identificativo.

<label for="email">
    Email <span aria-hidden="true">*</span>
</label>

Il principio è semplice: il colore può comunicare, ma non dovrebbe essere l’unico canale di comunicazione.

Navigazione da tastiera: il sito deve funzionare anche senza mouse

Una delle verifiche più semplici che possiamo fare su un sito è anche una delle più utili: provare a utilizzarlo soltanto con la tastiera.

Premendo il tasto Tab dovremmo poter raggiungere i principali elementi interattivi della pagina.

Premendo Shift + Tab possiamo invece tornare all’elemento precedente.

Il tasto Enter permette normalmente di attivare un link o un pulsante, mentre la Spacebar può essere utilizzata per attivare determinati controlli, come alcuni pulsanti e checkbox.

Durante questo test possiamo verificare diversi aspetti:

• tutti gli elementi interattivi sono raggiungibili?
• l’ordine di navigazione è logico?
• il focus è sempre visibile?
• possiamo aprire e chiudere il menu?
• possiamo utilizzare i form?
• possiamo interagire con modali, tab e accordion?
• possiamo raggiungere il contenuto principale senza attraversare ogni volta tutta la navigazione?

Se una funzionalità è utilizzabile esclusivamente con il mouse, esiste una barriera di accessibilità.

Il focus deve essere visibile

Quando un utente naviga con la tastiera, deve poter capire quale elemento è attualmente attivo.

Per questo è fondamentale non eliminare indiscriminatamente il contorno di focus attraverso CSS.

Un codice come questo:

:focus {
    outline: none;
}

può rendere molto difficile capire dove si trova il focus.

Se il design richiede un focus personalizzato, è possibile crearne uno più coerente con l’interfaccia, purché rimanga chiaramente visibile.

:focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 3px;
}

Il focus è un elemento fondamentale dell’interazione da tastiera.

Componenti di User Interface

Skip link: saltare direttamente al contenuto principale

Quando una pagina contiene una navigazione molto lunga, un utente che utilizza la tastiera potrebbe essere costretto a premere Tab molte volte prima di raggiungere il contenuto principale.

Una soluzione semplice è utilizzare uno skip link, cioè un collegamento che permette di saltare direttamente al contenuto principale.

<a class="skip-link" href="#main-content">
    Vai al contenuto principale
</a>

<main id="main-content">
    ...
</main>

Lo skip link può essere inizialmente nascosto visivamente e comparire quando riceve il focus da tastiera.

È un piccolo componente, ma può migliorare notevolmente l’esperienza di navigazione per chi utilizza la tastiera o altre modalità di input.

Link e pulsanti: non sono la stessa cosa

Un altro errore molto comune nello sviluppo web consiste nell’utilizzare link e pulsanti come se fossero intercambiabili.

Dal punto di vista visivo possono sembrare molto simili, ma hanno funzioni semantiche diverse.

Un link serve principalmente a portare l’utente verso una nuova destinazione:

<a href="/contatti">Contattaci</a>

Un button, invece, serve generalmente a eseguire un’azione all’interno della pagina:

<button type="button">Apri il menu</button>

Per esempio, se cliccando un elemento l’utente viene portato alla pagina dei contatti, dovremmo utilizzare un link. Se invece cliccando l’elemento apriamo una finestra modale, mostriamo un menu o inviamo un form, normalmente dovremmo utilizzare un pulsante.

Questa distinzione è importante anche per l’accessibilità perché browser e tecnologie assistive conoscono già il comportamento di questi elementi nativi.

Utilizzare il componente corretto significa quindi ottenere una parte importante dell’accessibilità “gratis”, senza dover ricreare manualmente comportamenti che il browser già gestisce.

Il testo dei link deve essere comprensibile

Un link dovrebbe comunicare chiaramente la propria destinazione.

Testi come:

<a href="/accessibilita">Clicca qui</a>

non sono una scelta ideale.

Il problema diventa ancora più evidente quando una persona utilizza uno screen reader e naviga tra i link della pagina senza ascoltare necessariamente tutto il contenuto circostante.

È molto più utile utilizzare un testo descrittivo:

<a href="/accessibilita">
    Scopri come rendere un sito web accessibile
</a>

In questo modo il link mantiene il proprio significato anche quando viene estratto dal contesto.

Lo stesso principio vale per link come “Leggi di più”, “Approfondisci” o “Scopri”. Se nella stessa pagina sono presenti molti link con lo stesso testo, può diventare difficile capire quale contenuto verrà aperto.

Il testo del link dovrebbe essere sufficientemente descrittivo da permettere di comprenderne la destinazione.

Moduli accessibili: progettare form che le persone possano realmente compilare

I moduli sono tra gli elementi più delicati dal punto di vista dell’accessibilità.

Un form accessibile deve permettere all’utente di:

• capire cosa deve inserire;
• sapere quali campi sono obbligatori;
• comprendere il formato richiesto;
• individuare eventuali errori;
• capire come correggerli;
• compilare il modulo utilizzando la tastiera e le tecnologie assistive.

Utilizzare sempre una label associata al campo

Ogni campo dovrebbe avere un’etichetta comprensibile e correttamente associata al relativo controllo.

<label for="nome">Nome</label>
<input type="text" id="nome" name="nome">

L’attributo for della label deve corrispondere all’id del campo.

In questo modo l’associazione tra etichetta e campo viene comunicata correttamente anche alle tecnologie assistive.

Il placeholder non dovrebbe essere utilizzato come sostituto della label.

<input
    type="email"
    id="email"
    name="email"
    placeholder="nome@esempio.it">

Il placeholder può fornire un esempio del formato richiesto, ma non dovrebbe sostituire l’etichetta che identifica il campo.

Indicare chiaramente gli errori

Quando un utente commette un errore, non è sufficiente colorare il bordo del campo di rosso.

L’errore dovrebbe essere comunicato in modo chiaro e, quando possibile, spiegare anche come risolverlo.

Per esempio:

<label for="email">Email</label>

<input
    type="email"
    id="email"
    name="email"
    aria-invalid="true"
    aria-describedby="email-error">

<p id="email-error">
    Inserisci un indirizzo email valido, ad esempio nome@esempio.it.
</p>

In questo esempio aria-invalid comunica che il valore inserito non è valido, mentre aria-describedby collega il campo al messaggio di errore.

Questo è un buon esempio di utilizzo di ARIA: non stiamo sostituendo un elemento HTML nativo, ma stiamo aggiungendo informazioni utili sullo stato del componente.

Tabelle

Le tabelle dovrebbero essere utilizzate per rappresentare dati tabellari, non per costruire il layout della pagina.

Una tabella semplice dovrebbe identificare correttamente le intestazioni:

<table>
    <caption>Vendite per trimestre</caption>

    <thead>
        <tr>
            <th scope="col">Trimestre</th>
            <th scope="col">Vendite</th>
        </tr>
    </thead>

    <tbody>
        <tr>
            <th scope="row">Q1</th>
            <td>1200 €</td>
        </tr>
    </tbody>
</table>

La presenza di intestazioni semantiche permette alle tecnologie assistive di comprendere meglio la relazione tra celle e intestazioni.

Le tabelle particolarmente complesse richiedono naturalmente una progettazione più attenta, soprattutto quando sono presenti più livelli di intestazione o molte relazioni tra i dati.

Finestre modali

Le modali sono componenti molto comuni, ma possono diventare complesse dal punto di vista dell’accessibilità.

Quando una modale viene aperta, l’utente dovrebbe poter capire che è comparso un nuovo contenuto e interagire con esso senza perdersi nella pagina sottostante.

È necessario considerare almeno:

• nome e ruolo della modale;
• possibilità di raggiungerne i controlli tramite tastiera;
• presenza di un pulsante per chiuderla;
• gestione corretta del focus;
• comportamento del tasto Escape, quando appropriato;
• ritorno del focus all’elemento che ha aperto la modale.

Una modale che appare visivamente ma non viene comunicata correttamente alle tecnologie assistive può creare una situazione molto confusa.

Come già detto, costruire il componente utilizzando HTML semantico e pattern accessibili è molto più efficace che aggiungere ARIA alla fine del lavoro.

Stati dinamici e contenuti aggiornati

Un’altra difficoltà riguarda i contenuti che cambiano senza che la pagina venga ricaricata.

Immaginiamo un form che, dopo l’invio, mostri questo messaggio:

<p>Messaggio inviato correttamente!</p>

Visivamente l’utente può vedere immediatamente il messaggio.

Una persona che utilizza uno screen reader, però, potrebbe non sapere che qualcosa è cambiato.

In situazioni appropriate è possibile utilizzare le live region ARIA per comunicare gli aggiornamenti dinamici.

<p aria-live="polite">
    Messaggio inviato correttamente!
</p>

Con aria-live possiamo indicare che il contenuto di un determinato elemento può cambiare e che la modifica deve essere comunicata alla tecnologia assistiva secondo la modalità specificata.

Come sempre, però, ARIA deve essere utilizzato con attenzione. Una pagina piena di live region che annunciano continuamente qualsiasi cambiamento può diventare estremamente fastidiosa per chi utilizza uno screen reader.

Contenuti PDF e documenti scaricabili

Un sito può essere accessibile dal punto di vista del codice HTML e presentare comunque barriere nei documenti che mette a disposizione.

PDF, documenti Word, presentazioni e altri file possono contenere infatti problemi di accessibilità indipendenti dal sito che li ospita.

Un PDF, per esempio, dovrebbe essere strutturato correttamente utilizzando elementi semantici, un ordine di lettura coerente, testo selezionabile, alternative testuali per le immagini e un titolo appropriato.

Se pubblichiamo un documento importante esclusivamente in un formato non accessibile, non abbiamo realmente risolto il problema fornendo un sito HTML accessibile.

Bisogna quindi considerare l’accessibilità dell’intero ecosistema digitale, non soltanto delle pagine web.

Carousel, slider e componenti interattivi

Carousel e slider possono essere particolarmente problematici perché combinano movimento, controlli, contenuti dinamici e spesso interazioni non intuitive.

Se utilizziamo un carousel, dovremmo verificare almeno che:

• i controlli siano raggiungibili da tastiera;
• i pulsanti abbiano nomi comprensibili;
• l’utente possa capire quale slide è attiva;
• il contenuto non cambi troppo rapidamente;
• sia possibile fermare o controllare il movimento automatico quando necessario;
• il contenuto delle slide sia accessibile anche alle tecnologie assistive.

In molti casi, però, la domanda migliore è ancora più semplice:

Abbiamo davvero bisogno del carousel?

Eliminare un componente complesso è spesso una soluzione di accessibilità migliore rispetto al tentativo di renderlo accessibile dopo averlo progettato.

Video, audio e contenuti multimediali accessibili

L’accessibilità non riguarda soltanto testo e immagini.

Se pubblichiamo un video, dobbiamo considerare anche le persone che non possono ascoltarne l’audio.

I sottotitoli permettono di rendere accessibili le informazioni audio alle persone sorde o con difficoltà uditive e sono utili anche in moltissime situazioni quotidiane, per esempio quando si guarda un video senza audio.

Quando il contenuto audio è particolarmente importante, può essere utile anche una trascrizione.

Per i contenuti video in cui le informazioni visive sono indispensabili per comprendere ciò che viene detto, può essere necessario considerare anche l’audio description, cioè una descrizione delle informazioni visive rilevanti.

Un altro aspetto spesso dimenticato riguarda i contenuti che si avviano automaticamente.

Un video o un audio che parte senza che l’utente lo abbia richiesto può creare problemi, soprattutto per chi utilizza uno screen reader o per chi ha difficoltà cognitive e di concentrazione.

Quando possibile, è quindi preferibile lasciare all’utente il controllo della riproduzione.

Animazioni e movimento: quando il design diventa una barriera

Animazioni, transizioni e microinterazioni possono migliorare l’esperienza utente, ma devono essere utilizzate con attenzione.

Movimenti molto intensi o effetti che occupano una parte significativa dello schermo possono risultare problematici per alcune persone.

È quindi importante rispettare le preferenze dell’utente quando il sistema operativo comunica che è stata richiesta una riduzione del movimento.

@media (prefers-reduced-motion: reduce) {
    *,
    *::before,
    *::after {
        animation:none;
        transition:none;
    }
}

Non significa necessariamente eliminare qualsiasi forma di animazione, ma ridurre o modificare quelle che possono creare una barriera.

Questo è un altro esempio di come progettare pensando alle persone porti a un risultato migliore rispetto al semplice tentativo di “spuntare” una lista di requisiti.

Responsive design e accessibilità

Un sito accessibile deve essere utilizzabile anche su schermi di dimensioni diverse e con differenti modalità di visualizzazione.

L’accessibilità mobile non è un argomento separato dall’accessibilità web: un’interfaccia che funziona bene soltanto su desktop può creare barriere anche quando tutti i criteri tecnici sembrano rispettati.

È quindi importante verificare il comportamento del sito almeno su:

• desktop;
• tablet;
• smartphone;
• schermi con zoom elevato;
• finestre del browser ridimensionate.

Un errore comune consiste nel progettare pensando esclusivamente alla dimensione dello schermo prevista dal designer.

Un utente potrebbe invece utilizzare un monitor molto grande, uno smartphone piccolo oppure un browser ingrandito per rendere i contenuti più leggibili.

Lo zoom non deve rompere il sito

Una persona con difficoltà visive può utilizzare lo zoom del browser per aumentare la dimensione dei contenuti.

Se aumentando lo zoom compaiono elementi sovrapposti, testi tagliati, pulsanti irraggiungibili o contenuti che scompaiono, abbiamo creato una barriera.

Per questo è importante utilizzare layout flessibili e lasciare che i contenuti possano adattarsi alle dimensioni disponibili.

Bisogna inoltre evitare di disabilitare lo zoom tramite il viewport, per esempio attraverso configurazioni che impediscono all’utente di ingrandire la pagina.

Il contenuto deve essere comprensibile

L’accessibilità non riguarda soltanto il codice.

Anche il modo in cui scriviamo i contenuti può creare oppure ridurre barriere.

Un testo accessibile dovrebbe essere:

• chiaro;
• conciso quando possibile;
• organizzato in paragrafi;
• diviso attraverso titoli e sottotitoli;
• supportato da liste quando dobbiamo presentare più elementi;
• coerente nella terminologia;
• comprensibile anche senza affidarsi esclusivamente a elementi grafici.

Non significa necessariamente scrivere sempre contenuti estremamente semplici. Significa invece evitare complessità inutile e costruire una gerarchia che permetta al lettore di capire rapidamente come è organizzata la pagina.

Scrivere titoli realmente descrittivi

Un titolo come “Alcune cose da sapere” comunica molto meno rispetto a “Come scegliere un font leggibile”.

Un titolo descrittivo permette all’utente di capire immediatamente cosa troverà nella sezione.

Questo è particolarmente importante quando la pagina viene consultata utilizzando uno screen reader, perché l’utente può navigare direttamente tra i titoli.

Non creare muri di testo

Un paragrafo estremamente lungo può essere difficile da leggere, anche quando il contenuto è corretto.

Suddividere le informazioni in paragrafi più brevi, utilizzare titoli, liste e spaziatura adeguata aiuta a creare una struttura visiva e semantica più chiara.

La leggibilità, quindi, non dipende esclusivamente dal font scelto.

La struttura editoriale è parte dell’esperienza di accessibilità.

La lingua della pagina deve essere dichiarata

Il documento HTML dovrebbe indicare correttamente la lingua principale della pagina.

<html lang="it">

Questo piccolo attributo è importante perché permette alle tecnologie assistive di sapere quale lingua utilizzare per la pronuncia del contenuto.

Se una pagina italiana non dichiara la propria lingua, uno screen reader potrebbe interpretare il testo con una voce o una pronuncia non appropriata.

Quando all’interno di una pagina compare una porzione significativa di testo in un’altra lingua, può essere utile indicarla attraverso l’attributo lang.

<p>
    Questo è un esempio di testo in
    <span lang="en">English</span>.
</p>

Contenuti e navigazione

Il titolo della pagina deve essere significativo

Il tag <title> è un elemento fondamentale dell’accessibilità e dell’usabilità.

<title>Come rendere un sito web accessibile | Nome del sito</title>

Il titolo dovrebbe descrivere in modo sintetico il contenuto della pagina.

Non è importante soltanto per i motori di ricerca: viene utilizzato anche dalle tecnologie assistive e contribuisce a permettere all’utente di identificare rapidamente la pagina aperta.

È quindi buona pratica evitare titoli generici come “Home”, “Pagina 1” o titoli duplicati su pagine differenti.

Linguaggio tecnico

Quando l’utente incontra un errore, per esempio il sistema non funziona o è stata fatta una scelta sbagliata, è bene non utilizzare il linguaggio tecnico.

Chi visita il sito web potrebbe non avere conoscenze informatiche, per cui bisogna scrivere testi comprensibili per tutti senza tecnicismi.

Quando invece i tecnicismi sono necessari per la natura stessa del contenuto, ad esempio si usano acronimi o riferimenti tecnici specifici, allora si deve spiegare, alla prima occorrenza di quella parola, il suo significato, in modo che chi legge abbia gli strumenti necessari per capire il testo anche senza una conoscenza pregressa di tutti i termini usati.

La navigazione deve essere coerente

Un sito accessibile dovrebbe mantenere una struttura di navigazione coerente.

Se il menu principale cambia posizione o comportamento arbitrariamente tra una pagina e l’altra, l’utente deve ogni volta imparare nuovamente come utilizzarlo.

La coerenza è particolarmente importante per le persone con difficoltà cognitive, ma migliora l’esperienza per tutti.

Gli elementi che svolgono la stessa funzione dovrebbero inoltre essere presentati in modo coerente.

Se in una pagina il pulsante per chiudere una finestra è rappresentato da una “X”, mentre in un’altra pagina utilizziamo la parola “Chiudi”, non stiamo necessariamente creando un problema di conformità, ma possiamo introdurre una piccola inconsistenza nell’esperienza.

La prevedibilità è una caratteristica importante di un’interfaccia accessibile.

Accessibilità e performance: due aspetti che spesso si incontrano

Un sito lento può diventare più difficile da utilizzare.

Questo vale in particolare per le persone che utilizzano dispositivi meno potenti, connessioni lente o tecnologie assistive che devono elaborare una grande quantità di contenuti dinamici.

Ottimizzare immagini, ridurre JavaScript inutile, utilizzare correttamente il caricamento dei contenuti e progettare interfacce non eccessivamente pesanti può quindi contribuire anche a migliorare l’esperienza di accessibilità.

Non significa che performance e accessibilità siano la stessa cosa: sono discipline differenti, con obiettivi e metriche specifiche.

Significa però che una buona progettazione web tende spesso a migliorare contemporaneamente più aspetti dell’esperienza utente.

Se cerchi consigli su come migliorare le performance del tuo sito web, puoi leggere gli articoli della sezione Prestazioni web di questo blog.

Come verificare se un sito web è accessibile? Test automatici e manuali

Una volta applicate le principali tecniche di accessibilità, arriva una fase altrettanto importante: la verifica.

Ed è qui che spesso si commette un altro errore: affidarsi completamente a uno strumento automatico.

Gli strumenti automatici sono estremamente utili, ma nessun software può stabilire da solo se un sito è realmente accessibile.

Le WCAG sono infatti pensate per essere verificate attraverso una combinazione di controlli automatici e valutazione umana. 0

Test automatici

I test automatici possono individuare rapidamente molti problemi comuni, per esempio:

• immagini prive di attributo alt;
• contrasto insufficiente in determinati casi;
• campi dei form privi di label;
• elementi con attributi ARIA non validi;
• problemi nella struttura degli heading;
• link privi di un nome accessibile;
• alcuni problemi relativi alla struttura HTML.

Questi controlli sono preziosi perché permettono di analizzare rapidamente molte pagine e individuare problemi che altrimenti richiederebbero molto tempo.

Ma superare un test automatico non significa automaticamente avere un sito accessibile.

Perché i test automatici non bastano?

Immaginiamo di avere questo codice:

<img src="persona.jpg" alt="Persona">

Un controllo automatico potrebbe considerare corretta la presenza dell’attributo alt.

Ma il vero problema è un altro: quel testo alternativo descrive davvero ciò che l’immagine comunica?

La risposta richiede una valutazione umana.

Lo stesso vale per molti altri aspetti dell’accessibilità:

• un testo può avere contrasto sufficiente ma essere difficile da leggere;
• gli heading possono essere tecnicamente presenti ma avere una gerarchia illogica;
• un pulsante può essere raggiungibile da tastiera ma avere un’etichetta poco comprensibile;
• un messaggio di errore può esistere nel codice ma non spiegare realmente all’utente come correggere il problema;
• un’interfaccia può non presentare errori automatici e risultare comunque confusa da utilizzare.

Per questo l’accessibilità deve essere verificata attraverso test automatici, test manuali e, quando possibile, coinvolgendo persone che utilizzano realmente tecnologie assistive.

Testare un sito con la tastiera

Uno dei test manuali più semplici è anche uno dei primi che consiglio di fare.

Prendi il sito e prova a utilizzarlo senza mouse.

Parti dalla parte superiore della pagina e premi ripetutamente Tab.

Osserva:

• dove si sposta il focus;
• se il focus è sempre visibile;
• se l’ordine degli elementi è logico;
• se tutti i controlli interattivi sono raggiungibili;
• se menu, modali e componenti interattivi possono essere utilizzati;
• se riesci a completare le attività principali del sito.

Non limitarti alla homepage.

Prova anche un percorso reale, per esempio:

1. aprire il menu;
2. raggiungere una pagina interna;
3. compilare un form;
4. correggere un eventuale errore;
5. inviare il modulo;
6. raggiungere una pagina di conferma.

Questo tipo di test permette di scoprire rapidamente problemi che un semplice scanner automatico potrebbe non evidenziare.

Testare il sito con uno screen reader

Un altro livello di verifica consiste nell’utilizzare uno screen reader.

Tra gli screen reader più conosciuti troviamo NVDA su Windows, VoiceOver sui dispositivi Apple e TalkBack su Android.

Non è necessario essere immediatamente esperti di screen reader per iniziare a fare qualche verifica.

Anche un test basilare può aiutare a capire come viene interpretata la struttura della pagina.

Possiamo, per esempio, verificare:

• qual è il titolo della pagina;
• quali heading vengono rilevati;
• come vengono annunciati i link;
• come vengono annunciati i pulsanti;
• se le immagini hanno un’alternativa appropriata;
• se i form hanno label comprensibili;
• se gli errori vengono comunicati;
• se le informazioni importanti sono disponibili anche senza vedere lo schermo.

Un test con screen reader è particolarmente utile perché ci costringe a guardare il sito da una prospettiva completamente diversa da quella del designer o dello sviluppatore.

Usare Lighthouse e altri strumenti automatici

Strumenti come Lighthouse, Mauve ++ e altri accessibility checker possono essere utilizzati come prima fase di controllo.

Il loro vantaggio principale è la velocità: permettono di individuare rapidamente una serie di problemi tecnici.

Ma è importante interpretare correttamente il risultato.

Un punteggio elevato non equivale a una certificazione di accessibilità e un punteggio basso non significa necessariamente che ogni parte del sito sia inaccessibile.

Gli strumenti automatici devono quindi essere considerati strumenti di supporto al processo di valutazione, non sostituti della valutazione umana.

Audit di accessibilità: cosa controllare

Un audit completo dovrebbe prendere in considerazione almeno queste aree:

• Struttura: HTML semantico, heading, landmark e gerarchia dei contenuti.
• Immagini: alt text, immagini decorative e immagini contenenti testo.
• Colore: contrasto e informazioni non comunicate esclusivamente attraverso il colore.
• Tastiera: raggiungibilità, ordine del focus e operabilità.
• Focus: visibilità e gestione corretta dei componenti interattivi.
• Form: label, istruzioni, errori e messaggi di stato.
• ARIA: ruoli, stati, proprietà e utilizzo appropriato degli attributi.
• Multimedia: sottotitoli, trascrizioni e alternative accessibili.
• Responsive: zoom, ridimensionamento e utilizzo su dispositivi differenti.
• Comprensibilità: linguaggio, navigazione, coerenza e prevedibilità.
• Compatibilità: browser, dispositivi e tecnologie assistive.

Un audit serio dovrebbe inoltre concentrarsi sui percorsi più importanti del sito e non soltanto sulla homepage.

Un e-commerce, per esempio, non può essere considerato accessibile soltanto perché la homepage supera un controllo automatico. Bisogna verificare anche ricerca, scheda prodotto, carrello, checkout, pagamento e conferma dell’ordine.

Chi può occuparsi dell’accessibilità di un sito?

L’accessibilità web è un’attività interdisciplinare.

Non dovrebbe essere responsabilità esclusiva dello sviluppatore che interviene sul codice alla fine del progetto.

Un progetto realmente accessibile coinvolge diverse competenze:

• UX Designer, che progetta flussi e interazioni;
• UI Designer, che si occupa dell’interfaccia visiva;
• Web Designer, che traduce i requisiti in componenti e layout;
• Front-end Developer, che realizza HTML, CSS e JavaScript;
• Content Designer o Copywriter, che produce contenuti comprensibili;
• Accessibility Specialist o Web Accessibility Expert, che porta competenze specifiche sull’accessibilità;
• QA e tester, che verificano il comportamento dell’interfaccia.

Chi è un Web Accessibility Expert?

Un Web Accessibility Expert, o Accessibility Specialist, è un professionista con competenze specifiche nell’analisi, nella progettazione, nello sviluppo e nella valutazione dell’accessibilità digitale.

Il ruolo può avere caratteristiche diverse a seconda dell’organizzazione.

Un professionista dell’accessibilità può occuparsi, per esempio, di:

• audit di siti web e applicazioni;
• analisi della conformità alle WCAG;
• test con tastiera e tecnologie assistive;
• consulenza a designer e sviluppatori;
• definizione di design system accessibili;
• formazione dei team;
• supporto nella redazione della documentazione di accessibilità;
• definizione di processi per integrare l’accessibilità durante tutto il ciclo di sviluppo.

Ma c’è un punto importante: l’accessibilità non dovrebbe essere delegata completamente a un Accessibility Expert.

Se un designer realizza un’interfaccia non accessibile e aspetta che qualcuno la corregga durante l’audit finale, il processo è già arrivato troppo tardi.

L’esperto di accessibilità dovrebbe aiutare il team a costruire competenze e processi, non diventare semplicemente il “controllore” che arriva alla fine per compilare una lista di errori.

Accessibilità web e normativa: Legge Stanca ed European Accessibility Act

Parlare di accessibilità web significa inevitabilmente parlare anche di normativa.

È però importante distinguere due concetti: accessibilità come principio di progettazione e accessibilità come obbligo normativo.

La normativa stabilisce quali requisiti devono essere rispettati nei casi in cui un sito o un servizio rientri nel relativo ambito di applicazione. Le WCAG, invece, forniscono criteri tecnici che permettono di valutare molti aspetti dell’accessibilità.

In altre parole, le WCAG non sono una legge. Sono uno standard tecnico che può essere richiamato dalla normativa.

La Legge Stanca

In Italia uno dei principali riferimenti legislativi in materia di accessibilità digitale è la Legge 9 gennaio 2004, n. 4, conosciuta come Legge Stanca.

La legge nasce con l’obiettivo di favorire l’accesso delle persone con disabilità agli strumenti informatici e, nel corso degli anni, è stata modificata per adeguarsi all’evoluzione della normativa europea e del mondo digitale.

La Legge Stanca riguarda in particolare l’accessibilità degli strumenti informatici e stabilisce obblighi per determinati soggetti pubblici e privati che rientrano nel suo campo di applicazione.

Per questo motivo non è corretto dire semplicemente che “tutti i siti web italiani devono essere accessibili secondo la Legge Stanca”.

Bisogna invece chiedersi:

• chi è il soggetto che gestisce il sito?
• che tipo di servizio viene offerto?
• il soggetto rientra nell’ambito di applicazione della normativa?
• quali requisiti tecnici sono richiesti?
• quale normativa europea e nazionale si applica nello specifico caso?

Per progetti professionali è quindi importante non fermarsi a una generica checklist WCAG, ma verificare anche gli obblighi normativi applicabili al caso concreto.

European Accessibility Act

Un altro riferimento fondamentale è l’European Accessibility Act, cioè la Direttiva (UE) 2019/882 sui requisiti di accessibilità dei prodotti e dei servizi.

La direttiva ha l’obiettivo di armonizzare le regole sull’accessibilità all’interno dell’Unione Europea e riguarda diversi prodotti e servizi destinati ai consumatori.

Tra gli ambiti interessati rientrano, a seconda dei casi, servizi come:

• servizi bancari destinati ai consumatori;
• commercio elettronico;
• servizi di comunicazione elettronica;
• alcuni servizi relativi al trasporto;
• e-book e relativo software;
• determinati prodotti e sistemi utilizzati per accedere ai servizi.

L’European Accessibility Act è particolarmente importante per chi realizza siti e servizi digitali perché amplia il tema dell’accessibilità oltre il tradizionale perimetro della Pubblica Amministrazione.

In Italia la direttiva è stata recepita attraverso il Decreto Legislativo 27 maggio 2022, n. 82, relativo ai requisiti di accessibilità dei prodotti e dei servizi.

Per chi lavora sul web è quindi importante conoscere sia la normativa nazionale sia il quadro europeo, soprattutto quando si lavora con e-commerce, servizi digitali e aziende che operano in più Paesi dell’Unione Europea.

La normativa può cambiare e il suo ambito di applicazione dipende dal soggetto e dal servizio. Per questo, quando è in gioco un obbligo legale concreto, è sempre opportuno verificare la normativa aggiornata e, quando necessario, rivolgersi a un professionista qualificato in materia legale.

Conformità WCAG: perché non basta un punteggio

Uno degli errori più diffusi nel mondo dell’accessibilità è cercare un numero che possa dire semplicemente:

“Il mio sito è accessibile al 95%”.

Un punteggio di un accessibility checker non funziona in questo modo.

Le WCAG sono composte da criteri di successo differenti e il rispetto o la violazione di un criterio non può essere trasformato in modo significativo in una percentuale generale di accessibilità.

Ancora più importante: alcuni aspetti richiedono necessariamente una valutazione umana.

Un tool può dirci che un’immagine possiede un attributo alt. Non può sapere con certezza se quel testo alternativo comunica il significato corretto dell’immagine.

Può verificare matematicamente il contrasto tra due colori. Non può decidere se la gerarchia visiva complessiva della pagina sia realmente comprensibile.

Può segnalare la presenza di un heading. Non può necessariamente stabilire se quel titolo descriva bene la sezione che introduce.

Per questo un audit professionale dovrebbe combinare analisi automatica e valutazione manuale.

Accessibilità by design: non correggere il problema alla fine

Il modo più efficace per rendere accessibile un sito è progettare l’accessibilità fin dall’inizio.

Questo approccio viene spesso definito Accessibility by Design.

Significa considerare l’accessibilità già durante:

• analisi dei requisiti;
• architettura delle informazioni;
• UX design;
• wireframe;
• UI design;
• design system;
• sviluppo front-end;
• produzione dei contenuti;
• testing;
• manutenzione del sito.

Immaginiamo di progettare un pulsante.

Se pensiamo all’accessibilità soltanto dopo aver completato il design, potremmo accorgerci che:

• il contrasto è insufficiente;
• il testo è troppo piccolo;
• lo stato di focus non è stato progettato;
• il pulsante non ha abbastanza spazio per essere utilizzato facilmente;
• il componente cambia aspetto soltanto attraverso il colore;
• l’interazione da tastiera non è stata considerata.

A quel punto dobbiamo correggere un componente già progettato.

Se invece l’accessibilità viene considerata durante la progettazione del design system, questi requisiti diventano parte del componente fin dall’inizio.

È molto più semplice progettare un componente accessibile che rendere accessibile un componente progettato senza accessibilità.

Cookie banner e accessibilità

Anche i cookie banner possono creare problemi.

Un banner dovrebbe poter essere utilizzato da tastiera, avere controlli comprensibili e non impedire all’utente di interagire correttamente con il resto dell’interfaccia.

Particolare attenzione dovrebbe essere prestata alla gestione del focus.

Quando compare un banner o una finestra che richiede un’azione, bisogna chiedersi:

• dove si trova il focus?
• l’utente capisce che è comparso un nuovo contenuto?
• può raggiungere tutti i controlli?
• può rifiutare o modificare le proprie preferenze senza difficoltà?
• dopo la chiusura il focus torna in una posizione sensata?

Un’interfaccia che blocca l’intero sito fino a quando l’utente non compie un’azione deve essere progettata con particolare attenzione.

Accessibilità dei pulsanti e dei target di interazione

Un pulsante dovrebbe essere sufficientemente grande e facile da attivare.

Questo è particolarmente importante sui dispositivi touch, dove non esiste la stessa precisione del puntatore del mouse.

WCAG 2.2 ha introdotto un criterio specifico relativo alla dimensione minima dei target di interazione, con alcune eccezioni.

Anche quando una determinata interfaccia rientra in un’eccezione tecnica, però, rimane utile chiedersi se il controllo sia effettivamente facile da utilizzare.

Un’icona minuscola posizionata accanto a un’altra icona minuscola può essere tecnicamente funzionante, ma non necessariamente rappresenta una buona esperienza.

Il fatto che un elemento sia cliccabile non significa automaticamente che sia facile da utilizzare.

Gli errori più comuni quando si cerca di rendere accessibile un sito

Quando un’azienda decide di occuparsi di accessibilità, ci sono alcuni errori che si ripetono molto spesso.

1. Pensare che basti aggiungere gli alt text

Le immagini sono importanti, ma l’accessibilità non si esaurisce con il testo alternativo.

Un sito può avere un alt text per ogni immagine e avere comunque:

• menu inutilizzabili da tastiera;
• form senza label;
• contrasto insufficiente;
• focus invisibile;
• heading utilizzati in modo scorretto;
• componenti JavaScript non accessibili;
• errori non comunicati alle tecnologie assistive.

L’alt text è quindi un tassello dell’accessibilità, non una certificazione di accessibilità.

2. Affidarsi completamente a un accessibility checker

Un altro errore frequente consiste nel lanciare un tool automatico, correggere gli errori segnalati e considerare concluso il lavoro.

Come abbiamo visto, molti aspetti dell’accessibilità richiedono una valutazione umana.

Un software può controllare la presenza di un attributo. Non può comprendere sempre se l’informazione fornita sia appropriata nel contesto.

3. Aggiungere ARIA ovunque

ARIA non è una soluzione universale.

Aggiungere molti attributi ARIA a un’interfaccia non accessibile non la rende automaticamente accessibile.

In alcuni casi può addirittura peggiorare la situazione.

La strategia migliore rimane quella di partire dall’HTML nativo e aggiungere ARIA soltanto quando è realmente necessario.

4. Nascondere il focus perché “rovina il design”

Il focus da tastiera viene talvolta rimosso perché considerato antiestetico.

È un errore importante.

Per una persona che naviga senza mouse, il focus rappresenta l’equivalente visivo del cursore.

Eliminare il focus senza fornire un’alternativa visibile significa rendere molto più difficile capire dove ci si trova nella pagina.

5. Considerare accessibile soltanto la versione desktop

Un sito responsive deve essere verificato anche su dispositivi mobili e con diversi livelli di zoom.

Un componente che funziona perfettamente su un monitor desktop può diventare inutilizzabile su uno smartphone.

L’accessibilità deve quindi essere considerata durante tutto il processo responsive, non soltanto nella versione desktop.

6. Intervenire soltanto dopo la pubblicazione

Correggere l’accessibilità dopo aver terminato lo sviluppo può essere molto più costoso rispetto a integrarla durante la progettazione.

Se un componente è stato progettato senza considerare tastiera, focus, contrasto e tecnologie assistive, correggerlo successivamente potrebbe richiedere modifiche a design, codice e contenuti.

Inserire invece questi requisiti nel processo fin dall’inizio permette di costruire componenti accessibili una sola volta e riutilizzarli in tutto il progetto.

Una checklist pratica per un sito web accessibile

Se vuoi fare una prima verifica del tuo sito, puoi utilizzare questa checklist come punto di partenza.

Struttura e contenuti

• La pagina ha un <title> descrittivo?
• La lingua della pagina è dichiarata correttamente?
• Esiste un solo <h1> principale appropriato?
• Gli heading seguono una gerarchia logica?
• Il contenuto è organizzato in paragrafi e sezioni comprensibili?
• La navigazione è coerente tra le pagine?
• I link descrivono chiaramente la loro destinazione?

Immagini

• Le immagini informative hanno un alt text appropriato?
• Le immagini decorative hanno un’alternativa appropriata?
• Il testo alternativo comunica il significato dell’immagine invece di descriverla inutilmente?
• Le immagini contenenti informazioni importanti non sono l’unico modo per accedere a quelle informazioni?

Tipografia e leggibilità

• Il font utilizzato è facilmente leggibile?
• Il testo ha una dimensione adeguata?
• L’interlinea è sufficiente?
• La lunghezza delle righe è ragionevole?
• Il testo mantiene un contrasto sufficiente?
• La spaziatura tra lettere e parole non compromette la leggibilità?
• Il contenuto rimane leggibile quando l’utente aumenta lo zoom?

Tastiera e interazione

• Tutti gli elementi interattivi sono raggiungibili con la tastiera?
• L’ordine del focus è logico?
• Il focus è sempre visibile?
• Il menu può essere utilizzato senza mouse?
• Modali, accordion, tab e carousel possono essere utilizzati da tastiera?
• È presente uno skip link quando necessario?

Form

• Ogni campo ha una label associata?
• Le istruzioni sono chiare?
• I campi obbligatori sono identificati in modo comprensibile?
• Gli errori sono comunicati anche senza affidarsi esclusivamente al colore?
• I messaggi spiegano come correggere l’errore?
• Gli aggiornamenti dinamici vengono comunicati correttamente?

ARIA e codice

• Viene utilizzato HTML semantico?
• ARIA viene utilizzato soltanto quando necessario?
• Gli elementi interattivi hanno un nome accessibile?
• Gli stati dinamici vengono comunicati correttamente?
• Gli elementi decorativi sono esclusi dalle tecnologie assistive quando appropriato?

Multimedia

• I video hanno sottotitoli quando necessari?
• Esiste una trascrizione quando appropriato?
• Le informazioni visive essenziali vengono rese disponibili anche in altri modi?
• La riproduzione automatica viene evitata o gestita correttamente?
• Le animazioni rispettano le preferenze di riduzione del movimento?

Come integrare l’accessibilità nel processo di sviluppo

La checklist è utile, ma da sola non basta.

Il vero obiettivo dovrebbe essere trasformare l’accessibilità in una parte normale del processo di progettazione e sviluppo.

Un processo efficace potrebbe prevedere questi passaggi:

1. Analisi: identificare utenti, obiettivi, requisiti e obblighi normativi.
2. UX: progettare flussi e architettura delle informazioni accessibili.
3. UI: definire tipografia, colori, componenti e stati accessibili.
4. Sviluppo: utilizzare HTML semantico, CSS e JavaScript in modo accessibile.
5. Contenuti: produrre testi, immagini e multimedia accessibili.
6. Testing: combinare controlli automatici e manuali.
7. Correzione: risolvere i problemi individuati.
8. Manutenzione: verificare l’accessibilità anche dopo la pubblicazione.

Questo approccio evita di trasformare l’accessibilità in un’attività straordinaria da svolgere una sola volta.

Un sito cambia continuamente: vengono pubblicati nuovi articoli, aggiunte nuove immagini, modificati componenti, installati plugin e introdotte nuove funzionalità.

Di conseguenza, anche l’accessibilità deve essere considerata un processo continuo.

Essere conformi non significa necessariamente essere accessibili

Arriviamo quindi al punto più importante di questo articolo.

Quando parlo di accessibilità web, non mi piace ridurre tutto alla domanda: “Il sito è conforme alle WCAG?”

È una domanda importante, soprattutto quando esistono obblighi normativi. Ma non dovrebbe essere l’unica domanda che ci poniamo.

La conformità è un requisito. L’accessibilità è un obiettivo.

Le WCAG ci forniscono criteri fondamentali per valutare l’accessibilità di un sito. La normativa stabilisce, nei casi previsti, quali requisiti devono essere rispettati.

Ma esistono decisioni progettuali che possono migliorare concretamente l’esperienza delle persone anche quando non sono riconducibili a un singolo criterio WCAG obbligatorio.

Pensiamo, per esempio, alla scelta del font.

Possiamo utilizzare un carattere molto particolare, estremamente decorativo e difficile da leggere, e rispettare comunque determinati requisiti tecnici relativi al contrasto e alla dimensione del testo.

Ma se abbiamo la possibilità di scegliere tra quel font e uno più leggibile, perché dovremmo scegliere quello più difficile?

Oppure pensiamo all’interlinea.

Un testo può rispettare determinati requisiti tecnici e contemporaneamente essere molto più faticoso da leggere se le righe sono troppo ravvicinate.

Lo stesso vale per la lunghezza dei paragrafi, la chiarezza delle istruzioni, la prevedibilità delle interazioni, la dimensione dei pulsanti e moltissimi altri aspetti.

Non dovremmo progettare fino al limite minimo della conformità.

Dovremmo utilizzare la normativa e le WCAG come una base, non come il tetto massimo della qualità.

Conclusioni: l’accessibilità non è una checklist

Rendere un sito web accessibile significa molto più che modificare qualche colore, aggiungere gli alt alle immagini e inserire alcuni attributi ARIA.

Significa progettare un’esperienza che possa essere percepita, utilizzata, compresa e interpretata da persone con esigenze differenti.

Le WCAG ci forniscono una base tecnica fondamentale. La normativa ci indica gli obblighi da rispettare quando il nostro progetto rientra nel relativo ambito di applicazione.

Ma il mio consiglio è di non fermarsi lì.

Prima delle WCAG vengono le persone.

Se una scelta progettuale può rendere il contenuto più leggibile, il percorso più comprensibile o l’interazione più semplice, non dovrebbe essere scartata soltanto perché “non è obbligatoria”.

Un font più leggibile, un pulsante più facile da individuare, un messaggio di errore più chiaro, una navigazione più prevedibile o un testo meglio organizzato possono fare una differenza enorme nella vita reale di una persona.

L’accessibilità dovrebbe quindi entrare nel progetto fin dal primo wireframe e rimanere presente fino alla manutenzione del sito.

Non dovrebbe essere il controllo finale prima della pubblicazione.

Non dovrebbe essere una lista di errori da correggere quando il progetto è già terminato.

E soprattutto, non dovrebbe essere vista soltanto come un obbligo burocratico.

Un sito accessibile è semplicemente un sito progettato meglio.

E quando progettiamo pensando prima alle persone e poi alla conformità, spesso scopriamo che le due cose non sono affatto in contrasto: la conformità diventa la base, mentre la qualità dell’esperienza diventa l’obiettivo.

Perché rendere il web accessibile non significa soltanto rispettare una regola. Significa fare in modo che più persone possano davvero utilizzare ciò che abbiamo progettato.

FAQ sull’accessibilità web