Risorse per l'accessibilità

Una breve storia dell'accessibilità web

Molto prima che esistesse il web, la legislazione federale statunitense aveva già iniziato a costruire l'impalcatura giuridica a cui l'accessibilità si sarebbe poi agganciata. La Sezione 504 del Rehabilitation Act del 1973 vietava la discriminazione sulla base della disabilità da parte di qualsiasi programma che ricevesse assistenza finanziaria federale, con i regolamenti attuativi firmati solo il 28 aprile 1977, e solo dopo il famoso sit-in 504, in cui gli attivisti per i diritti delle persone con disabilità occuparono un edificio federale a San Francisco per 25 giorni, la più lunga occupazione nonviolenta di un edificio federale nella storia degli Stati Uniti. La Sezione 508 della stessa legge fu aggiunta per emendamento nel 1986 ma non aveva alcun potere di applicazione; la versione sostanzialmente rivista a cui i professionisti fanno riferimento oggi fu promulgata nel 1998 come parte del Workforce Investment Act, imponendo alle agenzie federali statunitensi di rendere accessibile la propria tecnologia elettronica e informatica. L'Americans with Disabilities Act del 1990 è la più ampia legge sui diritti civili che vieta la discriminazione per disabilità, ed è l'ADA (non la Sezione 508) a essere invocata nelle cause sui siti web del settore privato.

Il W3C lanciò la Web Accessibility Initiative (WAI) nel 1997 per coordinare il lavoro sull'accessibilità web nell'intera comunità che definisce gli standard. L'impostazione di Tim Berners-Lee (secondo cui il valore del web poggia sull'universalità, e l'accesso da parte di tutti, a prescindere dalla disabilità, è essenziale) divenne la premessa fondativa della WAI.

La cronologia delle versioni delle WCAG

• WCAG 1.0: W3C Recommendation, 5 maggio 1999. Organizzava i consigli sull'accessibilità attorno a 14 linee guida con punti di controllo classificati come Priorità 1, 2 o 3 (i livelli di conformità A, AA e AAA derivano da questo schema). Saldamente orientata all'HTML e allo stack del web delle origini di fine anni '90.
• WCAG 2.0: W3C Recommendation, 11 dicembre 2008. Riorganizzò l'intero framework attorno ai quattro principi POUR. Introdusse il modello di conformità a tre livelli ancora attuale (A / AA / AAA). Adottata come ISO/IEC 40500:2012 nell'ottobre 2012.
• WCAG 2.1: W3C Recommendation, 5 giugno 2018. Aggiunse 17 nuovi criteri di successo rivolti agli utenti mobili (orientamento dello schermo, gesti del puntatore, attivazione tramite movimento), agli utenti ipovedenti (ridistribuzione a 320 pixel CSS, contrasto non testuale 3:1 per i componenti dell'interfaccia, tolleranza nella spaziatura del testo) e alle persone con disabilità cognitive e dell'apprendimento (scopo del campo per il riempimento automatico, aiuto sui timeout). «WCAG 2.1 AA» resta lo standard più citato nelle leggi sull'accessibilità di tutto il mondo.
• WCAG 2.2: W3C Recommendation, 5 ottobre 2023, con aggiornamenti di manutenzione editoriale pubblicati a dicembre 2024. Aggiunse nove nuovi criteri di successo, tra cui Focus Not Obscured (2.4.11/2.4.12), Dragging Movements (2.5.7), Target Size Minimum (2.5.8 (almeno 24×24 pixel CSS), Consistent Help (3.2.6), Redundant Entry (3.3.7) e Accessible Authentication (3.3.8/3.3.9) i flussi di accesso non possono richiedere CAPTCHA a rompicapo senza un'alternativa accessibile). Ha rimosso l'obsoleto criterio 4.1.1 Parsing. Questa è la versione attualmente pubblicata.
• WCAG 3.0: ancora una Working Draft. Progettata con un modello di punteggio più flessibile e un ambito più ampio (app, strumenti di authoring, piattaforme di pubblicazione, tecnologie emergenti). Il W3C è chiaro sul fatto che le WCAG 3 non sostituiranno immediatamente le WCAG 2: le WCAG 2 continueranno a essere mantenute per diversi anni dopo la finalizzazione delle 3. I professionisti che redigono dichiarazioni di accessibilità nel 2026 dovrebbero ancora fare riferimento alle WCAG 2.2 (o 2.1) come standard operativo.

I quattro principi POUR spiegati in parole semplici

Percepibile chiede: l'utente riesce davvero a recepire ciò che è sullo schermo? Una fotografia senza testo alternativo non è percepibile per chi usa uno screen reader. Un video senza sottotitoli non è percepibile per chi è sordo. Un testo in grigio scuro a 9 punti su un grigio appena meno scuro non è percepibile per molte persone ipovedenti. «Percepibile» non significa «bello da vedere», significa «l'informazione è presente in una forma che i sensi e gli strumenti di questo utente possono cogliere?»

Utilizzabile chiede: l'utente riesce davvero a usare l'interfaccia? Un sito che richiede di passare il mouse sopra gli elementi non è utilizzabile per chi usa la tastiera o il touch. Un timeout di 60 secondi non è utilizzabile per chi ha bisogno di più tempo per leggere. Una finestra modale che intrappola il focus della tastiera senza via d'uscita non è utilizzabile.

Comprensibile chiede: l'utente riesce a dare un senso a ciò che accade? Un modulo che dice «Errore 47» e nient'altro non è comprensibile. Una pagina in cui la navigazione si riorganizza in modo diverso a ogni visita non è comprensibile.

Robusto chiede: il contenuto continuerà a funzionare man mano che gli user agent e le tecnologie assistive si evolvono? I componenti personalizzati che non espongono ruoli, nomi e stati adeguati all'albero dell'accessibilità falliscono questo principio. Il consiglio pratico più comune: preferire gli elementi HTML standard ai widget JavaScript personalizzati quando possibile; quando costruisci widget personalizzati, segui i pattern ARIA documentati dal W3C.

WAI-ARIA, il complemento per le applicazioni ricche

WAI-ARIA è una specifica W3C separata che definisce ruoli, stati e proprietà che l'HTML può trasportare per comunicare alle tecnologie assistive lo scopo e lo stato attuale dei componenti dinamici dell'interfaccia. ARIA serve perché l'HTML da solo non può descrivere pattern moderni come schede, finestre di dialogo, combo box con completamento automatico, viste ad albero e regioni live che si aggiornano senza ricaricare la pagina. Cronologia delle versioni: WAI-ARIA 1.0 Recommendation del 20 marzo 2014; 1.1 il 14 dicembre 2017; 1.2 il 6 giugno 2023, la versione attuale. Le cinque «regole d'uso di ARIA» si riducono a: preferire l'HTML nativo; non cambiare la semantica degli elementi esistenti; garantire l'operabilità da tastiera; non nascondere mai gli elementi attivabili dalle tecnologie assistive; e dare sempre un nome accessibile a ogni elemento interattivo.

Il panorama giuridico, giurisdizione per giurisdizione

Negli Stati Uniti, le cause sull'accessibilità web vengono intentate quasi interamente in base all'ADA Title III. Due cause hanno definito il panorama moderno. National Federation of the Blind v. Target Corp. (depositata il 7 febbraio 2006, transatta ad agosto 2008 per 6 milioni di dollari più 3,7 milioni di dollari di spese legali) fu la prima grande class action statunitense sull'accessibilità web. Robles v. Domino's Pizza: sentenza del Ninth Circuit del 15 gennaio 2019; la Corte Suprema rifiutò di esaminare l'appello il 7 ottobre 2019, confermando che l'ADA si estende a qualsiasi piattaforma online di un'azienda statunitense con sedi fisiche. Il risultato è stato un boom costante di depositi: 4.187 cause federali sull'accessibilità digitale nel 2024, con più di 4.000 ogni anno dal 2021. Circa un quarto dei casi del 2024 coinvolgeva aziende che erano già state citate in giudizio in precedenza. In particolare, più di 1.000 dei convenuti del 2024 avevano già installato un «widget di accessibilità» (gli script in stile overlay molto pubblicizzati alle piccole imprese) che non ha impedito la causa.

Ad aprile 2024 il Dipartimento di Giustizia degli Stati Uniti ha finalizzato una norma a lungo attesa che applica il Title II dell'ADA ai contenuti web e alle app mobili delle amministrazioni statali e locali. La norma è stata pubblicata nel Federal Register il 24 aprile 2024 e ha adottato le WCAG 2.1 Livello AA come standard tecnico. Ad aprile 2026 il DOJ ha esteso le scadenze originarie di un anno tramite un Interim Final Rule: i grandi enti pubblici hanno ora tempo fino al 26 aprile 2027, i piccoli enti fino al 26 aprile 2028.

L'European Accessibility Act è la Direttiva (UE) 2019/882, adottata ad aprile 2019. Gli Stati membri dovevano recepirla nel diritto nazionale entro il 28 giugno 2022, e i requisiti sostanziali di accessibilità hanno iniziato ad applicarsi il 28 giugno 2025. L'EAA copre un'ampia gamma di prodotti e servizi di consumo immessi sul mercato dell'UE: computer e sistemi operativi, smartphone e tablet, lettori di e-book, sportelli bancomat e macchine per la biglietteria/il check-in, siti di e-commerce, servizi bancari, e-book, servizi di media audiovisivi e informazioni sul trasporto passeggeri. Le microimprese (meno di 10 dipendenti, fatturato inferiore a €2 milioni) che forniscono servizi sono esentate. Lo standard tecnico armonizzato è EN 301 549, pubblicato congiuntamente da CEN, CENELEC ed ETSI; la versione attuale 3.2.1 (marzo 2021) incorpora il testo completo delle WCAG 2.1.

Altri importanti quadri normativi nazionali: l'AODA dell'Ontario (Accessibility for Ontarians with Disabilities Act), promulgato nel 2005 con l'obiettivo dichiarato della piena accessibilità entro il 2025; l'RGAA francese (Référentiel Général d'Amélioration de l'Accessibilité) v4.1.2 (2022), un insieme di 106 criteri tecnici mappati alle WCAG 2.1 AA, con sanzioni sostanziali per l'inadempienza da parte del settore pubblico e delle grandi aziende private (fatturato annuo pari o superiore a €250 milioni).

Chi usa davvero il tuo sito, il panorama delle tecnologie assistive

I dati più affidabili sulle combinazioni di screen reader e browser provengono dalla WebAIM Screen Reader User Survey. L'edizione più recente, la Survey #10, è stata condotta a dicembre 2023, gennaio 2024 e ha raccolto 1.539 risposte valide. Numeri principali: come screen reader primario, JAWS 40,5%, NVDA 37,7%, VoiceOver 9,7%. Come «più comunemente usato in assoluto» (scelta multipla), NVDA 65,6%, JAWS 60,5%, VoiceOver 43,9%: circa il 71,6% degli intervistati usa più di uno screen reader. Le combinazioni più comuni sono JAWS + Chrome (24,7%), NVDA + Chrome (21,3%), JAWS + Edge (11,4%), NVDA + Firefox (10,0%) e VoiceOver + Safari (7,0%).

• JAWS (Job Access With Speech), screen reader commerciale per Windows, rilasciato originariamente nel 1989 da Ted Henter tramite Henter-Joyce, ora parte di Vispero. Dominante nelle aziende e nella pubblica amministrazione statunitensi.
• NVDA (NonVisual Desktop Access), il principale screen reader open source gratuito per Windows, rilasciato per la prima volta ad aprile 2006 da Michael Curran e James Teh (entrambi non vedenti). L'organizzazione no-profit NV Access fu fondata all'inizio del 2007. La crescita di NVDA è stata la tendenza più sorprendente nel mercato degli screen reader nell'ultimo decennio.
• VoiceOver: integrato nei sistemi operativi di Apple. Debuttò in Mac OS X 10.4 Tiger (2005); aggiunto a iOS con l'iPhone 3GS (2009). Ora è incluso in macOS, iOS, iPadOS, tvOS e watchOS.
• TalkBack: lo screen reader integrato equivalente su Android, mantenuto da Google.

Altre tecnologie assistive nell'ecosistema più ampio: ingranditori di schermo (ZoomText per Windows, l'ingranditore integrato di macOS), software di riconoscimento vocale (Dragon NaturallySpeaking), dispositivi a scansione per utenti con controllo motorio limitato, tastiere alternative e puntatori a testa, sistemi di tracciamento oculare e display braille aggiornabili. I criteri WCAG si rivolgono a tutti questi anche quando la pagina pensa solo agli screen reader.

Il contrasto dei colori, il modello WCAG 2 e il candidato APCA

Le WCAG 2.x misurano il contrasto come rapporto di luminanza tra due colori, un numero da 1:1 (nessun contrasto) a 21:1 (bianco puro su nero puro). Le soglie: Livello AA, testo normale 4,5:1; testo grande (18 pt o 14 pt in grassetto) 3:1; Livello AAA, testo normale 7:1; testo grande 4,5:1. Il §1.4.11 Non-Text Contrast delle WCAG 2.1 ha aggiunto un requisito di 3:1 al livello AA per i componenti dell'interfaccia e gli oggetti grafici che veicolano informazioni.

Il modello del rapporto di luminanza ha debolezze note, in particolare il fatto che sovrastima il contrasto percepito dei colori scuri: una coppia 4,5:1 di due colori scuri può essere di fatto illeggibile anche se tecnicamente supera la soglia. L'APCA (Accessible Perceptual Contrast Algorithm), sviluppato da Andrew Somers, è un sostituto basato sulla percezione, progettato per gli schermi auto-illuminati. È il metodo di contrasto candidato per le WCAG 3.0, attualmente non incluso in nessuna versione pubblicata delle WCAG. L'APCA produce un numero con segno su una scala che va all'incirca da -108 a +108 (negativo quando il testo chiaro è su uno sfondo scuro). I professionisti che pubblicano nel 2026 dovrebbero comunque effettuare i test rispetto ai rapporti delle WCAG 2.x come requisito legale, trattando i punteggi APCA come controlli percettivi di buon senso supplementari.

Lo stato del settore, in numeri

L'istantanea annuale più citata è il report Million di WebAIM, che dal 2019 esegue controlli automatici di accessibilità sulle home page del milione di siti web più visitati al mondo. L'edizione WebAIM Million 2026, pubblicata a marzo 2026, è la più recente al momento in cui scriviamo. Il 95,9% delle home page presentava errori WCAG 2 rilevati (in aumento rispetto al 94,8% del 2025, la prima inversione di una tendenza al miglioramento durata sei anni). La pagina media aveva 56,1 errori di accessibilità rilevati, un aumento del 10,1% su base annua. I sei tipi di errore più comuni rappresentano circa il 96% di tutti i problemi rilevati:

1. Testo a basso contrasto: 83,9% delle pagine, in media ~34 istanze per pagina
2. Testo alternativo mancante sulle immagini, 53,1%
3. Etichette di modulo mancanti: 51,0%
4. Link vuoti: 46,3%
5. Pulsanti vuoti: 30,6%
6. Dichiarazione della lingua del documento mancante: 13,5%

Per contesto: 1,3 miliardi di persone in tutto il mondo) circa il 16% della popolazione globale, ovvero all'incirca 1 persona su 6, vivono con una disabilità significativa, secondo la scheda informativa dell'Organizzazione Mondiale della Sanità aggiornata l'ultima volta il 7 marzo 2023.

Da dove provengono le risorse di questa directory

La directory qui sopra attinge dal ristretto numero di organizzazioni e progetti che di fatto definiscono il settore:

• W3C Web Accessibility Initiative (WAI). L'ente normatore stesso. I due gruppi di lavoro più attivi per i team dei siti sono l'Accessibility Guidelines Working Group (che mantiene le WCAG) e l'ARIA Working Group (che mantiene WAI-ARIA). La WAI pubblica pagine di panoramica, specifiche tecniche approfondite, la Quick Reference e corsi formativi gratuiti su edX.
• WebAIM (Web Accessibility In Mind). Fondata nel 1999 presso il Center for Persons with Disabilities della Utah State University. Gestisce lo strumento di valutazione WAVE, conduce la Screen Reader User Survey e il WebAIM Million, e pubblica una delle raccolte più consultate di articoli pratici sull'accessibilità sul web.
• Deque Systems. Fondata nel 1999, con sede a Herndon, in Virginia. Editrice del motore di regole axe-core, reso open source nel giugno 2015. Deque gestisce anche Deque University e produce l'estensione per browser axe DevTools, ormai il tester automatico predefinito del settore.
• A11Y Project. Una risorsa e libreria di pattern open source guidata dalla community, fondata nel 2013. Nota soprattutto per la sua checklist di accessibilità ampiamente condivisa; l'intero sito è su GitHub per il contributo della community.
• International Association of Accessibility Professionals (IAAP). Ente professionale fondato il 19 marzo 2014, divenuto una divisione di G3ict a luglio 2016. Amministra le certificazioni di settore riconosciute (CPACC, WAS, CPWA, ADS).
• MDN Web Docs. Il riferimento per sviluppatori di Mozilla, inclusa la sezione sull'accessibilità mantenuta che documenta ARIA, la semantica e i pattern di accessibilità dal punto di vista dell'implementazione lato sviluppatore.

Mettendo tutto insieme: la risposta pratica a «a quale standard dovrei conformarmi» nel 2026 è WCAG 2.1 AA come base minima (perché la maggior parte delle leggi la cita ancora) e WCAG 2.2 AA come obiettivo orientato al futuro. La risposta pratica sugli strumenti di test è axe DevTools per l'automazione più un vero screen reader (NVDA + Chrome su Windows, VoiceOver + Safari su macOS) per le parti che nessuno strumento automatico può rilevare; Deque stessa presenta axe come capace di rilevare «fino all'80% dei problemi», e la maggior parte delle stime indipendenti colloca il rilevamento automatico al 30-50% della conformità WCAG totale. Il test manuale con un vero screen reader è ancora necessario.