Go to Menu
Celebrando 25 anni di voce 🎉

Guida semplificata all’accessibilità dei contenuti web: Capire le Linee guida per l’accessibilità dei contenuti web (WCAG)

È difficile sapere da dove cominciare con le linee guida WCAG. Questa semplice guida all’accessibilità dei contenuti web può esserti utile.

2 Ottobre 2024 by Amy Foxwell
Una donna scrive su un libro mentre indossa le cuffie. È seduta alla scrivania davanti a un laptop.

Se la tua organizzazione ha un sito web, questo deve essere accessibile alle persone con disabilità. Dal punto di vista etico, hai la responsabilità di accogliere il maggior numero possibile di utenti; non esistono motivi validi per ignorare una parte importante del tuo pubblico. Questo vale per tutti i siti web pubblici e privati, a prescindere che tu gestisca un’azienda, una scuola, un’agenzia governativa o qualsiasi altra istituzione.

Secondo l’Organizzazione Mondiale della Sanità (OMS), oltre 1 miliardo di persone nel mondo vive con almeno una disabilità. Questo valore potrebbe essere sottostimato. Nel 2022, più di un quarto (27,0%) della popolazione dell’EU di età pari o superiore a 16 anni presentava una disabilità (limitazione delle attività) e il numero è destinato ad aumentare a causa delle tendenze demografiche.

Fornire un’esperienza migliore a quante più persone possibile: questo è l’obiettivo dell’accessibilità digitale. Questa affermazione include persone con un’ampia gamma di disabilità quali ad esempio:

  • Utenti sordi e persone con disabilità uditive
  • Persone con disabilità visive
  • Persone con differenze neurocognitive
  • Persone con disabilità fisiche
  • Persone con problemi di salute mentale

In che modo un sito web può accogliere tutti questi utenti? Come fare per testare i contenuti per essere certi di essere sulla strada giusta?

C’è una buona notizia: esiste un documento con tutte le regole da seguire. Le linee guida per l’accessibilità dei contenuti web (WCAG) sono pubblicate dal World Wide Web Consortium (W3C), un’organizzazione di portata internazionale che crea anche gli standard per i linguaggi di programmazione HTML e CSS. Ti spiegheremo qui di seguito in che modo il rispetto delle linee guida WCAG potrà aiutarti a raggiungere un maggior numero di persone e a migliorare la conformità all’Americans with Disabilities Act (ADA) e ad altre leggi.

Il ruolo delle linee guida WCAG nella conformità all’accessibilità

Molte leggi sui diritti delle persone disabili citano direttamente le linee guida WCAG, mentre altre (come gli Revised Section 508 Standards del governo statunitense) integrano le linee guida a titolo di riferimento. Parleremo di queste leggi qui di seguito; prima, però, spieghiamo brevemente come sono strutturate le linee guida WCAG.

Le linee guida WCAG sono organizzate secondo dichiarazioni chiamate “criteri di successo”, che possono avere due esiti: “Conforme” oppure “Non conforme”. Questi criteri di successo vengono utilizzati per verificare l’accessibilità digitale dei contenuti. Le linee guida sono state concepite per essere applicate praticamente a tutti i tipi di contenuti on-line, incluse le applicazioni mobile e i documenti consegnati tramite web (come ad esempio i PDF di Adobe).

I criteri di successo sono organizzati secondo tre livelli di conformità. “Conformità” significa seguire volontariamente le linee guida. Ecco i tre livelli di conformità ai criteri di successo WCAG:

Immagine schematica dei criteri di successo delle WCAG. I criteri vengono discussi uno per uno nel testo di questo blog dopo l’immagine.
  • Il livello A comprende i requisiti più essenziali (e meno rigorosi).
  • Il livello AA comprende i criteri aggiuntivi. La maggior parte dei siti web dovrebbe puntare alla conformità al livello AA.
  • Il livello AAA comprende i requisiti più severi. Alcuni tipi di contenuti potrebbero non essere in grado di soddisfare tutti i criteri di successo del livello AAA.

Ogni livello comprende tutti i criteri di successo del livello precedente. In altre parole, per essere conformi al livello AA delle linee guida WCAG, dovrai rispettare anche tutti i requisiti del livello A delle WCAG.

Legislazione internazionale in materia di accessibilità

Sempre più paesi hanno in vigore delle leggi sull’accessibilità: anche se la tua azienda non ha uffici in un determinato paese, ma vi opera, sei tenuto a rispettare la legislazione applicabile in materia di accessibilità di quel determinato paese.

Tutte queste leggi definiscono che i siti web pubblici e privati devono essere accessibili agli utenti con disabilità:

  • La Direttiva europea (UE) 2016/2102 in materia di accessibilità, relativa all’accessibilità dei siti web e delle applicazioni mobile degli enti pubblici è in vigore dal 26 ottobre 2016. L’Atto europeo sull’accessibilità (EAA), che si applicherà in tutta l’Unione europea a partire da giugno 2025, si pone l’obiettivo di migliorare il funzionamento del mercato dei prodotti e dei servizi accessibili eliminando gli ostacoli creati da norme divergenti nei diversi Stati membri. Questa legislazione europea, così come la direttiva del Parlamento europeo in materia di accessibilità dei siti web, richiede che i siti web pubblici e privati siano accessibili agli utenti con disabilità. Il tasso di accessibilità di un sito viene calcolato verificando i criteri basati sulle linee guida WCAG.
  • Negli Stati Uniti si applica l’Americans with Disabilities Act (ADA).
  • In Canada, l’AODA (Accessibility for Ontarians with Disabilities Act) richiede che tutti i siti web pubblici soddisfino la maggior parte dei criteri di successo delle linee guida WCAG 2.0 di Livello AA.
  • In Australia, in base al DDA (Disability Discrimination Act), simile all’ADA, il governo ha identificato il Livello A delle linee guida WCAG come standard di ragionevole conformità.
  • In Corea del Sud, la normativa in materia di protezione dei disabili, il Disability Protection Act, richiede la conformità alle linee guida coreane per l’accessibilità dei contenuti web, che sono pressoché identiche ai criteri di successo delle linee guida WCAG 2.0 di livello AA.

Questo elenco non è esaustivo. Mentre queste leggi (e le sanzioni che impongono) variano da Paese a Paese, le linee guida WCAG forniscono solo un quadro semplice per migliorare la conformità digitale. Offrono inoltre un potente strumento per la creazione di contenuti aziendali inclusivi: i siti web accessibili beneficiano generalmente di un posizionamento migliore nei risultati di ricerca e offrono a tutti gli utenti affetti da disabilità un’esperienza migliore. “Conformità alle linee guida WCAG” significa semplicemente seguire le migliori pratiche di progettazione dei contenuti web e prendere in considerazione l’esperienza degli utenti con disabilità quando fruiscono dei tuoi contenuti.

Perché l’accessibilità digitale è un bene per le aziende

Come abbiamo spiegato sopra, l’accessibilità digitale è un imperativo legale. Ma questo non è di certo l’unico motivo per garantire che il proprio sito web, prodotto o servizio sia accessibile. Più il tuo sito è accessibile, più grande sarà il tuo mercato!

Logicamente, se le persone con disabilità possono accedere al tuo sito web, avrai modo di raggiungere anche queste persone. Se fai in modo che il tuo sito sia conforme alle linee guida WCAG, la tua portata sarà decisamente più ampia. In quanto azienda socialmente responsabile, naturalmente vuoi risultare accessibile a tutti. Grazie alla tua scelta anche le persone senza disabilità potranno beneficiare di una migliore accessibilità.

Tutto questo ti aiuterà a mantenere la soddisfazione e la fedeltà dei tuoi clienti.

WCAG 101: I quattro principi fondamentali dell’accessibilità

Ora che abbiamo spiegato perché le linee WCAG sono importanti, parliamo di come funzionano. A prima vista, le linee guida WCAG possono sembrare opprimenti, ma sono suddivise in piccole linee guida logiche, organizzate secondo quattro principi generali. Affrontando ciascuno di questi elementi in successione, sarà possibile evitare il caos e migliorare l’accessibilità su base continua.

A prima vista, le linee guida WCAG possono sembrare opprimenti, ma sono suddivise in piccole linee guida logiche, organizzate secondo quattro principi generali.

Come abbiamo notato, le disabilità possono colpire le persone in modi estremamente diversi. Alcune persone con disabilità visive usano un software di lettura dello schermo, mentre altre possono servirsi di una lente di ingrandimento. Le persone affette da patologie neurocognitive potrebbero modificare le impostazioni del browser per visualizzare i contenuti con un carattere specifico, mentre le persone con disabilità fisiche potrebbero preferire l’uso della sola tastiera per la navigazione.

Le disabilità possono colpire le persone in modi estremamente diversi. E allora in che modo un unico insieme di standard può migliorare l’esperienza di quasi tutti gli utenti disabili?

I criteri di successo delle linee guida WCAG si snodano attorno a quattro principi fondamentali, che creano una solida base per una progettazione accessibile. Applicando questi principi nella progettazione del tuo sito web (o dell’applicazione mobile, o di qualsiasi altro prodotto digitale), creerai dei contenuti migliori.

Non ignorare i principi dell’accessibilità. Sono essenziali per comprendere e applicare le raccomandazioni delle linee guida WCAG. Quando la tua azienda si impegna a rispettare questi principi, potrai costruire una strategia sostenibile.

I quattro principi dell’accessibilità possono essere ricordati grazie a un acronimo facile da tenere a mente”POUR”: I contenuti devono essere Perceivable, Operable, Understandable e Robust. Forniremo qui seguito la definizione delle linee guida WCAG per ogni principio, insieme alla nostra interpretazione.

Immagine schematica dei quattro principi dell'accessibilità. I criteri vengono discussi uno per uno nel testo di questo blog dopo l’immagine.

1. Percepibile

“Le informazioni e i componenti dell’interfaccia utente devono essere presentati agli utenti in modi in cui essi possano percepirli”.

Ciò significa che i contenuti non si basano su un solo tipo di percezione sensoriale. Ad esempio, se il tuo sito web include un video senza didascalie o descrizioni audio, quel video non sarà percepibile dalle persone con disabilità visive.

2. Utilizzabile

“I componenti e la navigazione dell’interfaccia utente devono essere utilizzabili”.

Le persone devono essere in grado di utilizzare il tuo sito web indipendentemente dai metodi che scelgono di utilizzare. Molte persone, ad esempio, si servono di una tastiera per navigare in Internet (non usano il mouse).

Se il tuo sito web non è accessibile agli utenti con tastiera, non sarà utilizzabile per questi ultimi, in quanto richiede un tipo di interazione che loro non sono in grado di eseguire. Per esempi di navigazione con tastiera utilizzabile, rimandiamo alla nostra guida all’accessibilità della tastiera per lo strumento ReadSpeaker webReader.

3. Comprensibile

“Le informazioni e le operazioni dell’interfaccia utente devono essere comprensibili”.

Supponiamo che il tuo sito web sia accessibile con la tastiera, ma che, grazie ad alcuni JavaScript particolarmente fantasiosi, gli utenti debbano premere il tasto Invio invece del tasto Tab per scorrere la pagina.

Questa scelta non gioca a favore dell’accessibilità, in quanto non è quello che gli utenti si aspettano. In assenza di istruzioni chiare all’utente, quest’ultimo non potrà capire come utilizzare l’interfaccia. Nella migliore delle ipotesi, il tuo sito web causerà un sentimento di frustrazione per queste persone; nella peggiore delle ipotesi, potresti impedire loro di riprendere il controllo del computer fino a che non indovineranno il comando corretto.

4. Robusto

“Il contenuto deve essere abbastanza robusto per essere interpretato in maniera affidabile da una grande varietà di programmi utente, comprese le tecnologie assistive”.

Le tecnologie assistive (TA) sono dispositivi hardware e software che consentono alle persone con disabilità di servirsi di Internet in modo più efficiente. Un esempio comune è il software di lettura dello schermo, che converte il testo in parlato umano utilizzando la tecnologia di sintesi vocale text-to-speech (TTS), e questo è solo un esempio dei numerosi casi di utilizzo di questa tecnologia.

Il contenuto è robusto se utilizza codice e markup accurati. Ad esempio, se il tuo sito web utilizza correttamente l’HTML semantico e WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) per un sito complesso in JavaScript, offrirai un’esperienza migliore agli utenti di screen-reader. C’è anche una buona probabilità che il tuo sito funzioni bene per le persone che si servono di altri tipi di tecnologia assistiva, comprese le tecnologie non ancora ampiamente disponibili.

Come applicare le linee guida WCAG a siti web e applicazioni mobile

Il modo migliore per utilizzare le linee guida WCAG è quello di fare regolarmente riferimento alle linee guida durante le fasi di progettazione e sviluppo dei contenuti. Se aspetti che il tuo sito sia pubblicato per iniziare a pensare all’accessibilità, dovrai impegnare più tempo (e denaro) per risolvere i problemi. Detto questo, ci sono dei semplici accorgimenti che puoi adottare per migliorare l’accessibilità dei siti web già attivi e funzionanti, e almeno un errore importante da evitare.

Un processo in 3 fasi per migliorare l’accessibilità dei siti web (e 1 errore da evitare)

Quando inizi a cercare informazioni sull’accessibilità web, molto probabilmente ti imbatterai in aziende che offrono plugin di accessibilità multi-funzione. Queste soluzioni si chiamano “accessibility overlay”. Se i fornitori di questi overlay ti promettono di risolvere tutti i problemi di accessibilità in una volta sola, beh – non farti trarre in inganno.

L’accessibilità si affronta meglio se viene vista come una filosofia globale di progettazione, non come un “problema” che una singola soluzione può risolvere. Ancora peggio, alcuni accessibility overlay possono interferire con gli screen-reader e con altri dispositivi di tecnologia assistiva. E questo non migliora le cose – al contrario, le peggiora!

Anziché correre ai ripari cercando una soluzione che risolva tutti i problemi in una sola volta, affronta i singoli difetti di accessibilità uno per uno. Ecco un processo in tre fasi per organizzare la tua iniziativa di accessibilità digitale.

Fase 1: Fai l’inventario del tuo sito.

I difetti di accessibilità sono più facili da individuare quando si ha a disposizione un elenco dettagliato delle pagine, delle funzioni dell’interfaccia utente e delle risorse digitali del sito. Questo inventario ti aiuterà a organizzare i tuoi sforzi per migliorare l’accessibilità.

Fase 2: Testa il tuo sito per verificare la conformità alle linee guida WCAG.

Eseguire dei test con una certa frequenza è indubbiamente il modo migliore per misurare il livello di conformità alle linee guida WCAG. Un approccio che miscela automatismi e attività manuali è sempre il metodo più efficace. Per maggiori dettagli ti invitiamo a consultare il capitolo Test dei contenuti per la conformità alle linee guida WCAG.

Fase 3: Aggiungi funzionalità che eliminino i difetti di accessibilità.

I test ti indicheranno i punti in cui il tuo sito non è accessibile come dovrebbe essere. Ci sono molti modi per risolvere questi problemi (e molti potenziali problemi da risolvere). Potresti integrare uno strumento opzionale di sintesi vocale text-to-speech. Potresti includere funzioni aggiuntive del sito, come l’ingrandimento del testo, le maschere di pagina o la sintesi vocale text-to-speech con l’evidenziazione simultanea. In alternativa potresti dover ricorrere a un approccio manuale, ad esempio scrivendo descrizioni di testo alternativo chiare per tutte le immagini.

Come abbiamo ribadito all’inizio di questo articolo, ogni criterio di successo delle linee guida WCAG è scritto come una semplice dichiarazione che viene valutata “conforme” o “non conforme”. Diamo un’occhiata a diversi criteri di successo e agli errori più comuni che potrebbero far sì che i tuoi contenuti non soddisfino i requisiti.

Immagine schematica e ricca di testo che mostra le definizioni dei criteri di successo WCAG. I criteri vengono discussi uno per uno nel testo di questo blog dopo l’immagine.

Criterio di successo 1.1.1 per le linee guida WCAG 2.1: Contenuti non testuali

“Tutti i contenuti non testuali che vengono presentati all’utente hanno un’alternativa testuale che serve allo stesso scopo”

Il primissimo criterio delle linee guida WCAG richiede un’alternativa testuale per tutti i contenuti non testuali, con limitate eccezioni. Ciò è particolarmente importante per le immagini: Ogni immagine deve contenere un testo alternativo (chiamato anche “alt text” o “image alt tag”) che ne descriva lo scopo e la funzione.

Le alternative al testo mancante sono spesso citate nelle cause sull’accessibilità del web, tra cui Robles v. Domino’s Pizza LLC, un caso emblematico che ha contribuito a stabilire che l’ADA si applica ai contenuti on-line.

Per seguire questo criterio, è sufficiente includere un testo alternativo per immagini, grafici, animazioni e altri tipi di contenuti in prima battuta visivi.

Criterio di successo 1.4.3 per le linee guida WCAG 2.1: Contrasto (minimo)

“La rappresentazione visiva del testo e di immagini contenenti testo ha un rapporto di contrasto di almeno 4.5:1 […] Testo grande e immagini contenenti testo grande devono avere un rapporto di contrasto di almeno 3:1”.

Il rapporto di contrasto è la differenza di luminanza (o luce) tra il testo e lo sfondo. Il testo a basso contrasto può risultare difficile da leggere per alcuni utenti, in particolar modo per le persone con deficit di visione a colori e altre disabilità visive.

I problemi di contrasto dei colori sono estremamente comuni, ma con un po’ di attenzione questo errore può essere facilmente evitato. I progettisti web dovrebbero verificare il rapporto di contrasto di tutte le coppie di colori servendosi di strumenti on-line gratuiti come a11y® Color Contrast Accessibility Validator.

Criterio di successo 1.3.1 per le linee guida WCAG 2.1: Informazioni e correlazioni

“Le informazioni, la struttura e le correlazioni trasmesse attraverso la presentazione possono essere determinate programmaticamente oppure sono disponibili nel testo”.

Determinato programmaticamente significa che le informazioni sono disponibili per il software. Ad esempio, se hai un modulo web con dei campi obbligatori, gli utenti dovranno capire che i campi sono obbligatori. Se non sono in grado di inviare il modulo perché manca uno di questi campi, il software deve essere in grado di dire loro perché. Agli utenti che preferiscono l’informazione visiva è possibile comunicare questa informazione delineando il campo in rosso, ma chi non è in grado di percepire le informazioni visive avrebbe bisogno di un altro tipo di indicazione. Un modo semplice per fornire queste informazioni: Contrassegna i campi obbligatori con un asterisco, quindi includi “campi obbligatori contrassegnati da un asterisco” nelle istruzioni del modulo.

Criterio di successo 2.4.4 per le linee guida WCAG 2.1: Scopo del collegamento (nel contesto)

“Lo scopo di ogni link può essere determinato dal solo testo del link o dal testo del link insieme al suo contesto di collegamento determinato programmaticamente, tranne quando lo scopo del link potrebbe risultare ambiguo per gli utenti in generale”

In parole povere, le persone dovrebbero essere in grado di guardare un collegamento ipertestuale – o di ascoltare il testo di ancoraggio con uno screen-reader – e determinarne il funzionamento. Se il testo del tuo link recita “clicca qui” o “leggi altro”, non stai fornendo agli utenti informazioni sufficienti. Il testo del link deve essere descrittivo: Non “leggi altro”, ma “leggi altro su X, Y o Z”. Ad esempio, se stiamo linkando un articolo sull’intelligenza artificiale nell’istruzione, il testo del link potrebbe essere semplicemente “intelligenza artificiale nell’istruzione” Questa scelta fornisce agli utenti informazioni sufficienti per decidere se seguire il link.

Criterio di successo 1.2.2 per le linee guida WCAG 2.1: Sottotitoli (preregistrati)

“I sottotitoli vengono forniti per tutti i contenuti audio preregistrati in supporti sincronizzati, tranne quando il supporto è un’alternativa al testo ed è chiaramente etichettato in quanto tale”

Questo requisito si riferisce generalmente a video multimediali, presentazioni e altri contenuti che combinano audio e video.

I sottotitoli permettono alle persone di capire i tuoi media, anche se non possono (o scelgono di non) sentire l’audio. Fornendo i sottotitoli raggiungerai un pubblico molto più ampio: Uno studio di Facebook ha rilevato che gli annunci video con didascalia aumentano il tempo di visualizzazione dei video di una media del 12%.

Questi sono solo alcuni esempi dei circa 80 criteri di successo presenti nella versione 2.1 linee delle linee guida WCAG. (Forniremo spiegazioni sulle versioni delle linee guida WCAG nella sezione successiva) Tuttavia, a prescindere da quale criterio tu prenda in considerazione, il modo migliore per determinare il successo rimane lo stesso: i test di accessibilità.

Testare i contenuti per verificarne la conformità alle linee guida WCAG

Se un sito web segue volontariamente tutti i criteri di successo delle linee guida WCAG di livello A e AA, è generalmente considerato accessibile per la maggior parte delle persone. Per scoprire se i tuoi contenuti sono conformi, dovrai testarli rispetto alle linee guida con una certa frequenza.

Per scoprire se i tuoi contenuti sono conformi alle linee guida WCAG, dovrai testarli rispetto alle linee guida con una certa frequenza.

Ogni versione delle linee guida WCAG aggiunge nuovi criteri di successo e il W3C raccomanda di testare i contenuti in base alle ultime raccomandazioni ufficiali se si desidera garantire un livello di accessibilità ottimale.

A quale versione delle linee guida WCAG ci si deve conformare? Sebbene ciò dipenda senza ombra di dubbio dal momento in cui stai leggendo questo articolo, al momento della nostra pubblicazione (febbraio 2023), la versione attualmente in vigore è la WCAG 2.1, mentre la WCAG 2.2 dovrebbe essere rilasciata nel corso dell’anno. Ogni versione delle linee guida WCAG 2 è retro-compatibile. Ciò significa che le linee guida WCAG 2.2 contengono tutti i criteri di successo delle linee guida WCAG 2.1.

Nel frattempo, al momento della nostra pubblicazione, le linee guida WCAG 3.0 sono in fase di bozza, con una data di rilascio indeterminata fissata fra diversi “anni” nel futuro. Secondo i suoi autori, le linee guida WCAG 3 introdurranno nuovi meccanismi di punteggio, quindi non saranno retro-compatibili con le linee guida WCAG 2.

Due modi per testare la conformità alle linee guida WCAG

Le linee guida WCAG 2.1 contengono un totale di 78 criteri di successo e le linee guida WCAG 2.2 dovrebbero introdurre 9 nuovi criteri di successo. Come puoi fare per testare i tuoi contenuti rispetto a decine di requisiti?

La maggior parte degli esperti in materia di accessibilità digitale consiglia di utilizzare una combinazione di due tecniche:

  • Gli audit automatizzati si servono dell’intelligenza artificiale (AI) per verificare la presenza di determinate carenze delle linee guida WCAG. I test condotti dall’intelligenza artificiale sono economici e veloci, ma non così approfonditi come quelli manuali.
  • I test manuali vengono eseguiti da esperti qualificati in materia di accessibilità. Idealmente, i test manuali dovrebbero essere gestiti da persone con disabilità o con una significativa esperienza con software screen-reader e altre tecnologie assistive (AT).

Sebbene i test automatizzati siano economici, non sono perfetti: alcuni criteri di successo richiedono un giudizio umano. Ad esempio, uno strumento di intelligenza artificiale può dirti se le tue immagini hanno un testo alternativo, ma non sarà in grado di giudicare se il testo alternativo descrive l’immagine in modo accurato.

Sebbene i test automatizzati siano economici, non sono perfetti: alcuni criteri di successo richiedono un giudizio umano.

Utilizzando entrambe le tecniche, avrai modo di testare a fondo i tuoi contenuti mantenendo intatto il budget. Ti forniremo qui di seguito alcuni suggerimenti aggiuntivi per testare i tuoi contenuti.

  • Non assegnare i test WCAG a una sola persona o a un solo team. Questo approccio non è sostenibile: se quella persona abbandona la tua organizzazione, dovrai ricominciare da zero.
  • Accertati che tutti comprendano gli obiettivi dell’accessibilità. Ogni membro del tuo team può fare la sua parte: i designer devono scegliere combinazioni di colori adeguate; gli sviluppatori devono scrivere un codice pulito e compatibile con i dispositivi di tecnologia assistiva e gli autori di contenuti dovranno usare sottotitoli ed elenchi (esattamente come questo) per mantenere i contenuti leggibili.
  • Testa frequentemente i tuoi prodotti. Inizia a condurre i test fin dalle prime fasi di sviluppo.
  • Pubblica una dichiarazione di accessibilità che illustri i passi compiuti e gli obiettivi a lungo termine. Non dimenticare di includere informazioni di contatto e ascolta i feedback che ricevi dai tuoi utenti.

Essere trasparenti sui propri sforzi di accessibilità è sempre una buona idea. Se affidi un controllo a un servizio di verifica dell’accessibilità di terzi, condividi liberamente i risultati. A titolo di esempio, ecco l’ultimo Audit sull’accessibilità di ReadSpeaker realizzato dalla società di consulenza ILUNION Accesibilidad S.A.

Ed ecco un altro esempio: Ecco la più recente Dichiarazione di accessibilità per la soluzione di sintesi vocale text-to-speech (TTC) webReader di ReadSpeaker.

Se intendi offrire prodotti o servizi alle agenzie federali degli Stati Uniti, dovrai anche pubblicare un documento chiamato “Voluntary Product Accessibility Template” (Modello volontario di accessibilità del prodotto), o VPAT®. Questo documento attesta la conformità agli standard federali della Sezione 508 per l’accessibilità. Ti interessa scoprire come è strutturato questo documento? Ecco il VPAT per la soluzione webReader.

Il primo passo per risolvere un problema di accessibilità: Comprendere l’intento

Leggendo le WCAG e testando i tuoi contenuti, potresti trovare decine di problemi da risolvere prima di pubblicare il tuo sito web o un altro prodotto digitale.

In alcuni casi, tuttavia, la risoluzione di un problema potrebbe introdurre una barriera all’accessibilità completamente nuova. Potrebbe, ad esempio, essere necessario aggiungere un testo alternativo alle immagini; se le descrizioni non sono accurate, o se sono estremamente lunghe, non stiamo effettivamente migliorando l’accessibilità.

Le WCAG forniscono una guida per affrontare ogni criterio di successo, che si può trovare qui WCAG 2.1 Capire la documentazione. Affrontando con attenzione ogni problema, si capirà lo scopo di ogni requisito.

Prima di affrontare una barriera di accessibilità, dovrai porti alcune domande rapide:

  • Perché questo elemento costituisce un problema?
  • In che modo influisce sugli utenti?
  • Qual è il modo migliore per risolvere il problema?
  • In che modo la risoluzione del problema influirà sul resto dei miei contenuti?

Le WCAG sono più efficaci se tratti l’accessibilità digitale come una priorità. Porsi delle domande potrà aiutarti a capire l’intento che sta alla base dei requisiti (ed evitare di intervenire più volte sugli stessi problemi).

Perché le linee guida WCAG sono più di un semplice elenco di controllo

È vero che seguire tutti i criteri di successo WCAG di livello A/AA può migliorare la conformità digitale. Tuttavia, l’obiettivo dell’accessibilità digitale è quello di fornire a tutti la migliore esperienza possibile, non di spuntare le caselle di un elenco di standard. Per creare contenuti digitali veramente accessibili, l’accessibilità deve essere un principio guida che influenza ogni decisione di progettazione. È un grande impegno.

Perché spingersi oltre? Tanto per cominciare, l’accessibilità è un aspetto che va a vantaggio di tutti, anche delle persone che non hanno disabilità o condizioni che influenzano il loro comportamento in fase di navigazione. Più volte abbiamo visto che le tecnologie orientate all’accessibilità sono diventate caratteristiche standard per tutti i tipi di utenti.

L’accessibilità va a vantaggio di tutti, anche delle persone che non hanno disabilità o condizioni che influenzano il loro comportamento di navigazione.

Per esempio, le modalità ad alto contrasto (“modalità scure”) sono state originariamente progettate per rendere il testo più leggibile per le persone con problemi di percezione cromatica, ma si sono rapidamente diffuse tra milioni di utenti che preferiscono un’estetica più scura. Le didascalie sono state sviluppate per le persone con disabilità uditive, ma molte persone, tra cui il 70% degli spettatori della Gen Z, preferiscono semplicemente fruire dei contenuti video con i sottotitoli. Più in generale, in un sondaggio solo il 5% degli studenti universitari utilizza tecnologie assistive a causa della disabilità, ma il 18% degli studenti considera tali strumenti “necessari”.

La tecnologia di sintesi vocale text-to-speech (TTS) è forse il miglior esempio di miglioramento dell’accessibilità digitale con profonde implicazioni per tutti. I primi sistemi di sintesi vocale text-to-speech (TTS) sono stati sviluppati per portare i contenuti scritti alle persone con disabilità visive, ma oggi sono diventati una parte essenziale del panorama tecnologico: se oggi hai parlato con Alexa, Siri o un altro assistente vocale, hai usato la sintesi vocale text-to-speech. Anche i software di lettura dello schermo usano la sintesi vocale text-to-speech e il feedback della comunità dei disabili ha aiutato i fornitori a creare voci di sintesi vocale text-to-speech con un feedback accurato e realistico al tempo stesso.

Sintesi vocale text-to-speech conforme alle linee guida WCAG: ReadSpeaker e la Library of Congress

Il sito web pubblico della Library of Congress, congress.gov, si serve di un plug-in di sintesi vocale text-to-speech di ReadSpeaker per attivare l’audio del testo su richiesta dell’utente. Questo strumento è conforme agli standard AA delle linee guida WCAG 2.1 AA – e ovviamente la sintesi vocale text-to-speech aiuta il sito a risultare conforme alle linee guida WCAG nella sua globalità.

Questo strumento opzionale di sintesi vocale text-to-speech non interferisce con gli screen reader: per utilizzarlo, il visitatore del sito deve semplicemente fare clic sul pulsante Ascolta o su un menu a tendina con opzioni aggiuntive (ingrandimento del testo, maschere pagina, download di MP3, ecc. Questo è un esempio di strumento di sintesi vocale text-to-speech che fornisce funzionalità aggiuntive ai lettori che le desiderano, senza creare problemi agli utenti di dispositivi assistivi tradizionali.

La collaborazione tra la Library of Congress e ReadSpeaker illustra il valore degli strumenti di sintesi vocale text-to-speech flessibili per migliorare la conformità alle WCAG e l’accessibilità che tale conformità dimostra.

Noi di ReadSpeaker facciamo del nostro meglio per fornire la tecnologia di sintesi vocale text-to-speech a tutti, il che significa trovare nuove opportunità per creare esperienze on-line coinvolgenti.

Sappiamo inoltre che l’accessibilità digitale non si esaurisce con le linee guida WCAG. Quando le organizzazioni considerano l’accessibilità come un valore fondamentale e cercano modi per espandere i propri contenuti, gli utenti reali ne traggono vantaggio e anche le aziende. Le persone sono più propense a sostenere i brand con valori forti e, nel tempo, l’accessibilità ha un enorme ritorno sull’investimento. Se hai preso un impegno per l’accessibilità, la tecnologia di sintesi vocale text-to-speech di ReadSpeaker può aiutare la tua azienda a fare i passi successivi.

Related articles
Inizia a usare Text To Speech oggi

Rendi i tuoi prodotti più coinvolgenti con le nostre soluzioni vocali.

Contattaci