L’accessibilità web non è più un tema da addetti ai lavori progressisti: è un obbligo normativo con scadenze precise e conseguenze concrete per chi non si adegua. Dal 28 giugno 2025 la direttiva europea sull’accessibilità dei prodotti e dei servizi, il European Accessibility Act, ha esteso i requisiti di accessibilità digitale anche ai siti web di molte categorie di aziende private.
Per le agenzie che sviluppano siti WordPress, questo significa due cose: i siti consegnati devono rispettare standard di accessibilità precisi, e i clienti che non lo sapevano devono essere informati prima che il problema diventi una contestazione.
Cosa prevede la normativa nel 2026
Il riferimento tecnico per l’accessibilità web in Europa è il WCAG, Web Content Accessibility Guidelines, nella versione 2.1 o 2.2. La direttiva europea sull’accessibilità richiede la conformità al livello AA di questi standard per i soggetti rientranti nel proprio campo di applicazione.
Le categorie di soggetti privati obbligati includono le imprese che offrono servizi ai consumatori: banche, assicurazioni, ecommerce, operatori di trasporto, piattaforme di commercio elettronico, servizi di comunicazione elettronica. Le PMI con meno di dieci dipendenti e un fatturato annuo inferiore a due milioni di euro sono esentate, ma solo se non rientrano in categorie specifiche.
Per le PA italiane l’obbligo di accessibilità esiste da prima, con riferimento alla legge Stanca del 2004 e alle successive modifiche: tutti i siti delle pubbliche amministrazioni devono essere accessibili e pubblicare la dichiarazione di accessibilità.
La situazione normativa è in evoluzione e le specifiche cambiano in base alla categoria del cliente. Prima di dichiarare un sito conforme, è indispensabile verificare l’applicabilità specifica per ogni caso.
Cosa significa accessibilità nella pratica
WCAG 2.1 AA è organizzato intorno a quattro principi: il contenuto deve essere percepibile, utilizzabile, comprensibile e robusto. Ogni principio si traduce in criteri tecnici concreti che determinano se un sito è accessibile o no.
I requisiti più comuni che impattano lo sviluppo WordPress riguardano diverse aree. Per le immagini: ogni immagine informativa deve avere un attributo alt che descrive il contenuto. Le immagini decorative devono avere alt vuoto in modo che gli screen reader le ignorino. Per i form: ogni campo deve avere un’etichetta associata correttamente tramite attributo for o label implicita. I messaggi di errore devono essere chiari e associati al campo che li genera. Per i colori: il contrasto tra testo e sfondo deve rispettare rapporti minimi definiti da WCAG: 4,5 a 1 per il testo normale, 3 a 1 per i titoli grandi. Per la navigazione da tastiera: tutti gli elementi interattivi, link, pulsanti, form, devono essere accessibili e utilizzabili senza mouse. L’ordine di navigazione deve essere logico e coerente con la struttura visiva della pagina. Per i video: i video con audio devono avere sottotitoli. I video che trasmettono informazioni visive devono avere audiodescrizione.
I problemi di accessibilità più comuni su siti WordPress
I siti WordPress hanno pattern di accessibilità ricorrenti che emergono quasi sempre durante un audit. Conoscerli permette di intercettarli durante lo sviluppo invece che scoprirli a posteriori.
Il primo è il contrasto insufficiente. Molti temi e design usano testi grigi su sfondo bianco o testi colorati su sfondi colorati senza verificare il rapporto di contrasto. Strumenti come il Color Contrast Checker di WebAIM permettono di verificare in pochi secondi se una combinazione cromatica è conforme.
Il secondo è la mancanza di attributi alt sulle immagini. WordPress aggiunge il campo alt text nell’editor media, ma viene spesso lasciato vuoto. Un’agenzia che consegna un sito con decine di immagini senza alt text ha un problema di accessibilità immediato.
Il terzo è la navigazione da tastiera non funzionante. Molti slider, menu a tendina e componenti interattivi costruiti con JavaScript non sono accessibili da tastiera. Il test più semplice è navigare l’intero sito usando solo Tab, Shift+Tab e Invio: se ci sono elementi irraggiungibili o se il focus visivo scompare, c’è un problema.
Il quarto sono i form senza label associate correttamente. Placeholder text non è un sostituto della label: scompare quando l’utente inizia a digitare e non è letto correttamente dagli screen reader. Ogni campo deve avere una label esplicita.
Come integrare l’accessibilità nel processo di sviluppo
L’accessibilità è molto meno costosa se viene considerata durante lo sviluppo invece che corretta dopo la consegna. Integrare verifiche di accessibilità nelle fasi del progetto riduce il lavoro complessivo e produce siti che reggono nel tempo senza richiedere interventi correttivi.
In fase di design: verificare i rapporti di contrasto per tutte le combinazioni cromatiche usate, definire stati focus visibili per tutti gli elementi interattivi, assicurarsi che la struttura visiva della pagina corrisponda a una gerarchia semantica logica.
In fase di sviluppo: usare HTML semantico, ovvero header, nav, main, footer, section, article, con la funzione corretta invece di div generici per tutto. Assicurarsi che ogni immagine abbia alt text appropriato. Verificare che i form abbiano label associate correttamente. Testare la navigazione da tastiera su ogni componente interattivo.
In fase di testing: usare uno screen reader, NVDA su Windows o VoiceOver su Mac sono gratuiti, per navigare il sito come farebbe un utente non vedente. Usare strumenti automatici come Axe o WAVE per individuare i problemi più evidenti, sapendo che gli strumenti automatici individuano circa il 30-40% dei problemi di accessibilità totali.
L’accessibilità come argomento commerciale
Per molte agenzie l’accessibilità è stata a lungo un tema che si cercava di evitare perché percepito come costo aggiuntivo senza ritorno commerciale. Nel 2026 questo ragionamento non regge più su due fronti.
Il primo è normativo: i clienti nelle categorie obbligate dalla direttiva europea rischiano sanzioni se il loro sito non è conforme. Un’agenzia che li informa e li mette in regola prima che il problema emerga è un partner di valore. Una che non lo fa espone il cliente a un rischio che potrebbe ricadere anche sulla relazione con l’agenzia.
Il secondo è competitivo: un sito accessibile è un sito che funziona meglio per tutti gli utenti, non solo per quelli con disabilità. La navigazione da tastiera funzionante aiuta chi usa il sito su dispositivi touch. Il contrasto adeguato aiuta chi legge in condizioni di luce difficile. Gli attributi alt aiutano la SEO. L’accessibilità e la qualità tecnica sono la stessa cosa, descritte da angolazioni diverse.
Come Blurr gestisce l’accessibilità nei progetti delle agenzie partner
L’accessibilità non è un servizio aggiuntivo che Blurr offre su richiesta: è parte integrante del processo di sviluppo standard su ogni progetto. Durante la costruzione del sito vengono applicati sistematicamente i requisiti WCAG 2.1 AA più rilevanti: struttura HTML semantica corretta, attributi alt su tutte le immagini informative, label associate correttamente a ogni campo form, rapporti di contrasto verificati su tutte le combinazioni cromatiche del design, navigazione da tastiera funzionante su tutti i componenti interattivi principali.
Il risultato è che le agenzie che affidano lo sviluppo a Blurr ricevono siti già conformi ai requisiti di accessibilità base, senza dover gestire una fase di correzione separata dopo la consegna.
Blurr si occupa anche della messa in conformità di siti esistenti. Se un’agenzia gestisce siti di clienti che rientrano nelle categorie obbligate dalla direttiva europea e che non sono ancora conformi, Blurr esegue un audit tecnico che identifica le non conformità, produce un report con priorità di intervento e gestisce le correzioni in modo completo. Il processo include verifica con strumenti automatici, test manuale con screen reader, correzione del codice e verifica finale prima della riconsegna.
Questo servizio è particolarmente utile per siti sviluppati in precedenza da altri fornitori, dove i problemi di accessibilità si sono accumulati nel tempo senza che nessuno li abbia mai sistematicamente affrontati. La messa in conformità non richiede di rifare il sito da zero: nella maggior parte dei casi interviene sul codice esistente con modifiche mirate che risolvono le non conformità senza alterare il design o le funzionalità. Per approfondire come la qualità tecnica del sito impatta anche il posizionamento SEO, leggi SEO tecnica per WordPress. Per capire come gestiamo la compliance tecnica nei progetti, leggi GDPR e privacy per siti web nel 2026.
Se vuoi capire come integriamo l’accessibilità nel processo di sviluppo per le agenzie partner, su blurr.it/servizi/ trovi tutti i dettagli.
FAQ
Tutti i siti web devono essere accessibili nel 2026? Non tutti, ma molte categorie di siti privati sono obbligate dalla direttiva europea sull’accessibilità entrata in vigore il 28 giugno 2025. I siti della pubblica amministrazione italiana sono obbligati da normativa precedente. Le PMI con meno di dieci dipendenti e fatturato sotto i due milioni di euro sono generalmente esentate, salvo categorie specifiche. Prima di dichiarare un sito conforme o non obbligato, è necessario verificare l’applicabilità per la categoria specifica del cliente.
Cosa sono le WCAG e a quale livello bisogna essere conformi? Le WCAG, Web Content Accessibility Guidelines, sono le linee guida internazionali per l’accessibilità web prodotte dal W3C. Sono organizzate in tre livelli: A, AA e AAA. Il livello AA è quello richiesto dalla normativa europea ed è il riferimento standard per i siti web professionali. Il livello AAA è il più restrittivo e non è richiesto dalla normativa, ma alcune delle sue raccomandazioni migliorano significativamente l’esperienza utente.
Gli strumenti automatici sono sufficienti per verificare l’accessibilità di un sito? No. Gli strumenti automatici come Axe o WAVE individuano circa il 30-40% dei problemi di accessibilità totali: quelli che possono essere rilevati analizzando il codice senza interazione umana. Il restante 60-70% richiede test manuali, incluso l’uso di screen reader e la navigazione da tastiera. Un audit di accessibilità completo combina strumenti automatici e verifica manuale.
L’accessibilità impatta le performance del sito? In modo positivo. L’HTML semantico richiesto dall’accessibilità riduce il peso del markup rispetto all’uso indiscriminato di div. Le immagini con alt text migliorano la SEO. La struttura logica della pagina migliora la navigabilità per tutti gli utenti. L’accessibilità e la performance non sono obiettivi in conflitto: condividono molti degli stessi principi di qualità tecnica.