Che cos’è WCAG? Le Web Content Accessibility Guidelines spiegate

Quasi il 94,8% dei primi un milione di siti web non soddisfa gli standard di accessibilità di base, con una media di circa 51 errori rilevabili per homepage. Nel frattempo, solo negli Stati Uniti nel 2025 sono state intentate oltre 5.100 cause legali relative all’accessibilità digitale ai sensi dell’ADA — e i costi legali e reputazionali dell’ignorare l’accessibilità stanno aumentando rapidamente. Che tu gestisca un negozio e-commerce, una piattaforma SaaS o un portale governativo, un documento si trova al centro di quasi ogni conversazione sull’accessibilità: le WCAG, le Web Content Accessibility Guidelines. Se ti sei mai chiesto esattamente cosa sono le WCAG, perché esistono e cosa richiedono concretamente da te, questa guida è la spiegazione in inglese semplice che stavi cercando.

Le origini delle WCAG: da dove nasce lo standard

Le WCAG sono pubblicate dalla Web Accessibility Initiative (WAI), un programma del World Wide Web Consortium (W3C) — lo stesso organismo internazionale che standardizza HTML, CSS e la maggior parte delle tecnologie fondamentali del web. Le linee guida esistono perché il web, per sua natura, porta con sé una promessa di accesso universale. In pratica, senza scelte progettuali deliberate, quella promessa si sgretola per milioni di utenti.

Le radici delle linee guida per l’accessibilità del web risalgono al 1995, quando Gregg Vanderheiden compilò la prima linea guida per l’accessibilità del web subito dopo che Tim Berners-Lee menzionò l’accesso per le persone con disabilità in un keynote alla Second International Conference on the World-Wide Web. Negli anni successivi emersero oltre 38 diverse linee guida per l’accesso al web da vari autori e organizzazioni, che alla fine confluirono nelle Unified Web Site Accessibility Guidelines presso l’Università del Wisconsin–Madison. La versione 8 di quel documento, pubblicata nel 1998, divenne il punto di partenza per le WCAG 1.0, che il 5 maggio 1999 divennero una Raccomandazione ufficiale del W3C.

Le WCAG 2.0 arrivarono nel dicembre 2008 e furono abbastanza significative da essere adottate come standard ISO — ISO/IEC 40500:2012 — nell’ottobre 2012. Le WCAG 2.1, pubblicate nel giugno 2018, hanno esteso i criteri delle 2.0 con 17 nuovi criteri di successo incentrati sull’usabilità mobile, la bassa visione e l’accessibilità cognitiva. E l’attuale versione, WCAG 2.2, è stata pubblicata come Raccomandazione W3C il 5 ottobre 2023 ed è stata successivamente approvata come ISO/IEC 40500:2025. Il W3C incoraggia tutti a usare l’ultima versione, e per una buona ragione: i contenuti che soddisfano le WCAG 2.2 soddisfano automaticamente anche le WCAG 2.1 e 2.0.

Vale la pena essere chiari su cosa sono e cosa non sono le WCAG. Sono uno standard tecnico — una specifica precisa e verificabile sviluppata attraverso un rigoroso processo W3C multi-stakeholder in collaborazione con individui e organizzazioni di tutto il mondo. Non sono di per sé un documento legale, ma sono state incorporate per riferimento in leggi e regolamenti in decine di giurisdizioni, diventando di fatto il regolamento di riferimento per l’accessibilità digitale a livello mondiale.

A chi sono destinate le WCAG

Le WCAG affrontano le barriere di accessibilità per persone con un’ampia gamma di disabilità, tra cui disabilità visive, uditive, fisiche, del linguaggio, cognitive, linguistiche, dell’apprendimento e neurologiche. Si tratta di una popolazione straordinariamente ampia. L’Organizzazione Mondiale della Sanità stima che circa 1,3 miliardi di persone — circa il 16% della popolazione globale — vivano con una forma di disabilità che influisce sulla loro vita quotidiana e sull’accesso online. Ognuna di queste persone potrebbe essere in questo momento un potenziale cliente, cittadino, studente o dipendente che cerca di usare il tuo sito web.

Ma i benefici della conformità alle WCAG vanno ben oltre gli utenti con disabilità permanenti. Le linee guida aiutano anche le persone anziane con limitazioni legate all’età — riduzione della vista, perdita dell’udito, rallentamento dei movimenti — e spesso migliorano l’usabilità per tutti. Si pensi ai sottotitoli nei video: sono stati progettati per le persone sorde, ma avvantaggiano anche chi guarda in ambienti rumorosi, i non madrelingua che seguono il contenuto e chiunque preferisca leggere piuttosto che ascoltare. Allo stesso modo, la navigabilità da tastiera aiuta gli utenti esperti che trovano il mouse lento, e un contrasto di colore sufficiente aiuta chiunque stia strizzando gli occhi davanti a uno schermo luminoso all’aperto.

Le WCAG coprono inoltre contenuti su praticamente ogni tipo di dispositivo digitale — desktop, laptop, chioschi e dispositivi mobili — e sono intenzionalmente neutre rispetto alla tecnologia. I criteri di successo sono scritti come enunciati verificabili che non prescrivono una tecnologia specifica, il che significa che restano pertinenti man mano che HTML, i framework JavaScript e le tecnologie assistive continuano a evolversi.

I principi POUR: il fondamento concettuale delle WCAG

Ogni criterio di successo nelle WCAG — tutti e 86 nella versione 2.2 — è organizzato sotto quattro principi di alto livello, conosciuti collettivamente con l’acronimo POUR. Questi principi forniscono il fondamento concettuale dell’intero standard. Comprenderli ti offre un modello mentale intuitivo per l’accessibilità, ancora prima di leggere un singolo criterio specifico.

• Perceivable (Percepibile): Le informazioni e i componenti dell’interfaccia utente devono essere presentabili agli utenti in modi che possano percepire. In pratica, ciò significa che i contenuti non possono essere invisibili a tutti i sensi di un utente. Se un utente non può vedere un’immagine, deve esserci un’alternativa testuale che possa ascoltare tramite uno screen reader. Se un video ha una narrazione parlata, devono esserci sottotitoli per gli utenti che non possono sentire. I requisiti pratici sotto questo principio includono il testo alternativo per le immagini, i sottotitoli per i video, un contrasto di colore sufficiente tra testo e sfondo e la possibilità di ridimensionare il testo senza perdita di contenuto.
• Operable (Utilizzabile): I componenti dell’interfaccia utente e la navigazione devono essere utilizzabili. Nessuna interazione può richiedere un input che un utente non è in grado di fornire. L’implicazione più comune: tutte le funzionalità devono essere fruibili con la sola tastiera, non solo con il mouse. Questo principio copre anche il dare agli utenti tempo sufficiente per leggere e interagire con i contenuti, evitare contenuti che potrebbero scatenare crisi epilettiche e fornire più modi per navigare in un sito.
• Understandable (Comprensibile): Le informazioni e il funzionamento dell’interfaccia utente devono essere comprensibili. I contenuti non possono essere così complessi o confusi da impedire agli utenti di usarli come previsto. Ciò riguarda un linguaggio leggibile (inclusa la specifica della lingua della pagina nel codice affinché gli screen reader usino la pronuncia corretta), un comportamento prevedibile della pagina, istruzioni chiare e messaggi di errore utili che dicano agli utenti cosa è andato storto e come correggerlo.
• Robust (Robusto): I contenuti devono essere sufficientemente robusti da essere interpretati in modo affidabile da una vasta gamma di user agent, incluse le tecnologie assistive. Un sito robusto utilizza un markup semantico pulito e valido, in modo che screen reader, display Braille e altri strumenti assistivi possano analizzare e trasmettere correttamente i contenuti — sia oggi che man mano che la tecnologia evolve.

Pensa a POUR come a quattro filtri attraverso cui deve passare ogni elemento del tuo sito web. Se un componente non supera anche solo uno dei quattro filtri, è probabile che rappresenti una barriera per alcuni dei tuoi utenti.

Questi quattro principi sono rimasti stabili in tutte le versioni delle WCAG — 2.0, 2.1 e 2.2 — anche se i criteri di successo specifici al di sotto di essi sono cresciuti ed evoluti. Questa stabilità rende POUR una lente durevole per valutare l’accessibilità indipendentemente dalla versione a cui fa riferimento una determinata legge.

Livelli di conformità: A, AA e AAA spiegati

Sotto i quattro principi POUR si trovano 13 linee guida, e sotto queste linee guida si trovano gli 86 criteri di successo verificabili — i requisiti effettivi e specifici che devi soddisfare per poter dichiarare la conformità alle WCAG. Ogni criterio di successo è assegnato a uno di tre livelli di conformità.

• Livello A è il minimo. Si tratta dei requisiti più critici, che rappresentano barriere così gravi che alcuni utenti non possono affatto accedere ai contenuti. Esempi includono la fornitura di alternative testuali per i contenuti non testuali e l’assicurare che tutte le funzionalità siano accessibili da tastiera. Il solo livello A non è sufficiente per la maggior parte degli scopi normativi, ma non soddisfarlo significa un fallimento fondamentale.
• Livello AA è lo standard intermedio ed è quello richiesto dalla grande maggioranza delle leggi e dei regolamenti a livello globale. Soddisfa tutti i criteri di livello A più requisiti aggiuntivi come garantire rapporti di contrasto tra testo e sfondo di almeno 4,5:1, fornire una navigazione coerente tra le pagine e offrire sottotitoli per i video preregistrati. La maggior parte delle leggi globali sull’accessibilità — inclusa la Section 508 negli Stati Uniti, la EN 301 549 in Europa e l’AODA in Ontario, Canada — richiede la conformità al livello AA. Questo è l’obiettivo che quasi tutte le organizzazioni dovrebbero prioritizzare.
• Livello AAA è lo standard più elevato e include criteri che sono più aspirazionali che universalmente raggiungibili. Lo stesso W3C riconosce che non è possibile soddisfare tutti i criteri AAA per tutti i tipi di contenuto, quindi questi criteri non sono generalmente fissati come requisito di policy generale. Esempi includono l’interpretazione nella lingua dei segni per tutti i contenuti audio e un livello di lettura non più difficile della scuola secondaria inferiore.

Una sfumatura importante: i livelli di conformità sono cumulativi. Raggiungere il livello AA significa soddisfare anche tutti i criteri di livello A. Raggiungere il livello AAA significa soddisfare anche A e AA. E, cosa cruciale, la conformità è “tutto o niente” a ciascun livello — non puoi dichiarare la conformità AA se anche un solo criterio AA non è soddisfatto in una determinata pagina.

Per la maggior parte delle organizzazioni, WCAG 2.2 livello AA è l’obiettivo giusto. È il livello incorporato nelle leggi, il livello che i tribunali usano come riferimento e il livello che apre in modo significativo la tua esperienza digitale al pubblico più ampio possibile.

Cosa è cambiato nelle WCAG 2.2: i nove nuovi criteri di successo

Le WCAG 2.2, pubblicate nell’ottobre 2023, hanno aggiunto nove nuovi criteri di successo in aggiunta a tutto ciò che era presente nelle WCAG 2.1. Queste aggiunte sono state guidate da ricerche continue su dove gli utenti con disabilità — in particolare con disabilità cognitive, compromissioni motorie e bassa visione — incontrassero ancora barriere frequenti che le linee guida precedenti non affrontavano in modo adeguato. Le WCAG 2.2 non rimuovono né modificano alcun requisito esistente delle WCAG 2.1; li estendono semplicemente.

Dei nove nuovi criteri, quattro sono di livello AA (e quindi giuridicamente rilevanti per la maggior parte delle organizzazioni), due sono di livello A e tre sono di livello AAA. Ecco cosa significa in pratica ciascun criterio di livello AA e inferiore:

• 2.4.11 Focus Not Obscured — Minimum (AA): Quando un utente da tastiera naviga verso un componente interattivo, quel componente non deve essere completamente nascosto da altri contenuti creati dall’autore. Questa è una risposta diretta a un diffuso pattern di design moderno: intestazioni fisse, banner per i cookie e footer fissi che scorrono sopra i contenuti della pagina e inghiottono silenziosamente il focus da tastiera, lasciando gli utenti bloccati senza alcuna indicazione visibile di dove si trovino nella pagina.
• 2.5.7 Dragging Movements (AA): Qualsiasi funzionalità che richiede un’azione di trascinamento — si pensi al drag-and-drop per il caricamento di file, agli elementi di liste ordinabili o agli slider personalizzati — deve avere un’alternativa a singolo puntatore che non richieda il trascinamento. Per un utente con tremori alle mani o limitato controllo motorio fine, mantenere una pressione continua mentre si sposta un puntatore sullo schermo può essere quasi impossibile. Fornire alternative come clic-per-selezionare e poi clic-per-posizionare, o pulsanti su/giù su liste ordinabili, risolve questo problema.
• 2.5.8 Target Size — Minimum (AA): I target interattivi come pulsanti e link devono essere almeno 24×24 pixel CSS. I target di tocco piccoli sono un problema di usabilità ben documentato per gli utenti mobili con compromissioni motorie, per le persone anziane e, in realtà, per chiunque stia digitando su un telefono mentre fa più cose contemporaneamente.
• 3.3.8 Accessible Authentication — Minimum (AA): I processi di autenticazione non possono richiedere agli utenti di risolvere un test di funzione cognitiva — come un CAPTCHA tradizionale che richiede il riconoscimento di caratteri o la risoluzione di puzzle — a meno che non venga fornita un’alternativa. Questo è un criterio significativo per qualsiasi sito che utilizzi sfide CAPTCHA standard nei flussi di login o registrazione. Le soluzioni includono il supporto per i password manager, i link “magici” via email o SMS, l’autenticazione biometrica o alternative basate sul riconoscimento di oggetti.
• 3.2.6 Consistent Help (A): Se un sito fornisce un meccanismo di aiuto (come un pulsante di live chat, un link alle FAQ o un numero di telefono per il supporto) su più pagine, quel meccanismo deve apparire nella stessa posizione relativa tra le pagine. Gli utenti con disabilità cognitive che hanno bisogno di aiuto traggono grande beneficio dal sapere esattamente dove trovarlo senza dover cercare ogni volta.
• 3.3.7 Redundant Entry (A): Le informazioni precedentemente inserite da un utente in un processo a più fasi devono essere compilate automaticamente o selezionabili, invece di richiedere un nuovo inserimento. Questo riduce l’attrito per gli utenti con disabilità cognitive o motorie per i quali la compilazione di moduli è particolarmente gravosa.

Le WCAG 2.2 hanno anche formalmente rimosso un criterio delle 2.1: 4.1.1 Parsing. Questo criterio richiedeva originariamente un HTML strettamente valido per garantire che le tecnologie assistive potessero analizzare correttamente il markup. È stato ritirato perché i browser moderni e le tecnologie assistive ora gestiscono in modo robusto il markup non valido attraverso i propri meccanismi di correzione degli errori, rendendo il criterio non più praticamente significativo per l’accessibilità.

WCAG e legge: cosa costa davvero la non conformità

Le WCAG sono uno standard tecnico, non una legge. Ma sono state intrecciate nel tessuto giuridico dell’accessibilità digitale nella maggior parte delle principali giurisdizioni, il che significa che la non conformità comporta una reale esposizione legale.

Negli Stati Uniti, sebbene né l’ADA né la Section 508 menzionino esplicitamente le WCAG 2.2 nel testo, le WCAG sono costantemente utilizzate come riferimento tecnico nelle controversie e nelle attività di enforcement. Il Department of Justice ha pubblicato nel 2024 una Final Rule che stabilisce le WCAG 2.1 livello AA come standard ufficiale per la conformità alla Section 508 e all’ADA Title II per i governi statali e locali. L’ADA Title III — che si applica ai luoghi di pubblico accomodamento, inclusa la maggior parte delle imprese private che operano online — è attivamente applicato tramite cause private. Nel 2024 sono state intentate oltre 4.000 cause ADA relative a proprietà digitali nei tribunali federali e statali, e la tendenza è continuata al rialzo nel 2025. Le sanzioni civili per la prima violazione dell’ADA sono state adeguate all’inflazione nel 2024 e possono ora raggiungere i 115.231 $, salendo a 230.464 $ per le recidive.

In Europa, il quadro è altrettanto significativo. L’European Accessibility Act (EAA) è diventato giuridicamente applicabile negli Stati membri dell’UE il 28 giugno 2025, richiedendo che siti web, app, e-book, piattaforme di e-commerce e PDF siano conformi ai criteri WCAG 2.1 AA. Lo standard europeo EN 301 549 attualmente fa riferimento alle WCAG 2.1, e la prossima versione dovrebbe aggiornarsi alle WCAG 2.2. Per le organizzazioni con una presenza in Europa, la conformità all’EAA non è più facoltativa.

I dati sulle controversie legali mettono inoltre in luce un modello particolarmente doloroso per le piccole imprese: l’idea che restare piccoli ti mantenga al sicuro è un mito. Nel 2023, il 77% delle cause ADA relative all’accessibilità digitale ha preso di mira aziende con meno di 25 milioni di dollari di fatturato annuo. L’e-commerce rimane di gran lunga il settore più colpito dalle cause. E, cosa fondamentale, essere citati in giudizio una volta non offre alcuna protezione contro ulteriori cause — quasi la metà di tutte le cause recenti in materia di accessibilità digitale ha preso di mira aziende che avevano già affrontato almeno un reclamo precedente.

Le violazioni WCAG più comuni (e come individuarle)

Considerato che quasi il 95% dei siti web non soddisfa gli standard di accessibilità di base, vale la pena sapere quali violazioni specifiche sono più diffuse. Il rapporto annuale WebAIM Million, che analizza le homepage dei primi un milione di siti web, identifica costantemente la stessa manciata di problemi che compaiono sulla stragrande maggioranza delle pagine:

• Basso contrasto di colore: Il testo a basso contrasto ha interessato il 79,1% delle homepage nell’analisi del 2025, con una media di quasi 30 istanze per pagina. Questo è contemporaneamente il fallimento più comune e uno dei più facili da rilevare con strumenti automatici. Il testo deve avere un rapporto di contrasto di almeno 4,5:1 rispetto allo sfondo (3:1 per il testo grande) per soddisfare il livello AA.
• Testo alternativo mancante: Il testo alternativo mancante interessa il 55,5% delle pagine. Per gli utenti di screen reader che sono ciechi o ipovedenti, un’immagine senza testo alternativo è semplicemente invisibile — la tecnologia assistiva la salterà in silenzio o leggerà un nome file privo di significato. Le immagini collegate senza testo alternativo interrompono completamente la navigazione.
• Etichette dei moduli mancanti: I campi di input dei moduli senza etichette associate significano che un utente di screen reader non può capire quali informazioni siano richieste in un campo. Questo crea una barriera impenetrabile in qualsiasi modulo di checkout, registrazione o contatto.
• Link vuoti: I link senza testo descrittivo — spesso link costituiti solo da icone o immagini senza testo alternativo — lasciano gli utenti da tastiera e gli utenti di screen reader senza alcun contesto sulla destinazione del link.
• Lingua del documento mancante: Non dichiarare la lingua di una pagina nell’HTML significa che gli screen reader potrebbero leggere i contenuti usando le regole di pronuncia della lingua sbagliata, rendendo il testo incomprensibile.

Ciò che colpisce di questo elenco è che nessuno di questi è un caso limite esotico che richiede ingegneria avanzata. Si tratta di semplici decisioni di markup e design. Il fatto che persistano sulla stragrande maggioranza del web riflette un divario strutturale nel modo in cui l’accessibilità è (o non è) integrata nei tipici flussi di lavoro di sviluppo web, non una barriera tecnica fondamentale.

Come affrontare la conformità alle WCAG come organizzazione

Passare dalla situazione in cui si trovano oggi la maggior parte dei siti web a una reale conformità alle WCAG 2.2 livello AA richiede un approccio sistematico. Non è un progetto una tantum — è un processo continuo, perché i contenuti cambiano, i framework si aggiornano e i componenti di terze parti vengono sostituiti. Ecco come strutturare lo sforzo in modo efficace.

Inizia con un audit di base. Prima di poter correggere qualcosa, devi sapere cosa non funziona. Gli strumenti di scansione automatica possono identificare rapidamente e su larga scala una parte significativa dei problemi — problemi di contrasto di colore, testo alternativo mancante, etichette dei moduli assenti. Tuttavia, gli strumenti automatici hanno limiti ben noti; possono rilevare circa il 30–40% dei problemi WCAG. Il resto richiede test manuali: navigare nel tuo sito usando solo la tastiera, testare con screen reader reali come NVDA o JAWS su Windows e VoiceOver su macOS e iOS e, idealmente, coinvolgere persone con disabilità nel processo di test.

Prioritizza in base a impatto e frequenza. Non tutti i problemi hanno lo stesso peso. Un testo alternativo mancante su un’icona decorativa è molto meno critico di una trappola da tastiera che impedisce a un utente di uscire da una finestra modale, o di un modulo di login completamente inutilizzabile con uno screen reader. Concentrati nel tuo primo sprint di correzione sulle barriere che bloccano i percorsi utente fondamentali — checkout, creazione account, ricerca, contatto — prima di affrontare elementi estetici o a impatto minore.

Integra l’accessibilità nel flusso di sviluppo, non alla fine. Il lavoro di accessibilità più costoso è la correzione dopo il lancio. Integrare i controlli di accessibilità nel tuo design system, nella libreria di componenti, nel processo di code review e nella pipeline CI/CD permette di intercettare i problemi nel punto in cui è più economico risolverli. Stabilisci un responsabile chiaro per l’accessibilità all’interno del tuo team e fornisci formazione specifica per ruolo a designer, sviluppatori e redattori di contenuti.

Mantieni una dichiarazione di accessibilità. Pubblicare una dichiarazione di accessibilità chiara e onesta sul tuo sito — descrivendo quale standard miri a soddisfare, come gli utenti possono segnalare le barriere e come rispondi alle segnalazioni — dimostra buona fede ed è in realtà richiesto dalla legge in alcune giurisdizioni, incluso ai sensi della Direttiva UE sull’accessibilità del web. Crea anche un circuito di feedback che ti aiuta a individuare problemi sfuggiti ai test.

Usa i widget di overlay come miglioramenti, non come sostituti dell’accessibilità a livello di codice. I widget e gli SDK di overlay per l’accessibilità — incluso Accsible — possono essere strumenti preziosi per mettere in evidenza preferenze controllate dall’utente come dimensione del testo, modalità di contrasto e miglioramenti alla navigazione da tastiera. Ma i dati sono chiari: i widget implementati al posto del lavoro di accessibilità di base non impediscono le cause legali. La protezione legale deriva dal fatto che il tuo codice di base soddisfa i criteri WCAG, non da un widget installato sopra fondamenta inaccessibili. Usa gli overlay per integrare una reale attività di correzione, non per sostituirla.

La strada da percorrere: WCAG 3.0 all’orizzonte

Anche mentre le organizzazioni stanno ancora lavorando per soddisfare le WCAG 2.2, il W3C Accessibility Guidelines Working Group sta sviluppando le WCAG 3.0, una ristrutturazione più sostanziale delle linee guida per l’accessibilità del web. La prima bozza pubblica di lavoro è stata rilasciata all’inizio del 2021 e, alla fine del 2025, la bozza di lavoro continua a subire sviluppi significativi. Nessuna parte delle WCAG 3.0 è ancora una raccomandazione ufficiale e non è stata definita alcuna data di rilascio fissa.

Si prevede che le WCAG 3.0 si discostino in modo significativo dal modello di conformità A/AA/AAA, introducano un approccio basato sul punteggio e coprano una gamma più ampia di tipi di contenuti digitali, incluse le applicazioni mobili native e le tecnologie emergenti. Per ora, le organizzazioni dovrebbero concentrarsi sulle WCAG 2.2 livello AA — è lo standard attualmente applicabile e lo rimarrà per il prossimo futuro. Le organizzazioni che costruiscono ora solide fondamenta basate sulle WCAG 2.2 saranno molto meglio posizionate per adattarsi quando le WCAG 3.0 diventeranno eventualmente una raccomandazione.

Punti chiave

• Le WCAG 2.2 sono l’attuale standard globale per l’accessibilità del web, pubblicato dal W3C e approvato come ISO/IEC 40500:2025. I contenuti che soddisfano le WCAG 2.2 soddisfano automaticamente le 2.1 e le 2.0 — punta sempre all’ultima versione.
• Il livello AA è l’obiettivo che conta. Quasi tutte le leggi globali sull’accessibilità — ADA, Section 508, EAA, EN 301 549, AODA — fanno riferimento al livello AA delle WCAG come livello di conformità richiesto. Concentrati prima di tutto su quello.
• Le violazioni più comuni sono risolvibili. Basso contrasto di colore, testo alternativo mancante, etichette dei moduli assenti e link vuoti rappresentano la maggior parte degli errori di accessibilità sul web. Sono problemi risolvibili con uno sforzo relativamente contenuto e con un impatto significativo.
• I test automatici sono necessari ma non sufficienti. Gli strumenti possono rilevare circa il 30–40% dei problemi WCAG. Abbina la scansione automatica ai test da tastiera, ai test con screen reader e, idealmente, ai test con utenti con disabilità per ottenere un quadro completo.
• L’accessibilità è un processo continuo, non un progetto una tantum. I contenuti cambiano, i componenti di terze parti cambiano e gli standard evolvono. Integra l’accessibilità nei tuoi flussi di lavoro di design, sviluppo e gestione dei contenuti, in modo che sia mantenuta in modo continuo e non corretta in modo reattivo dopo un reclamo o una causa.