Accessibilità WordPress
Rendi il tuo sito WordPress davvero accessibile. EAA e WCAG, senza overlay
WordPress è flessibile, ma non è accessibile per impostazione predefinita: page builder, plugin e temi introducono barriere silenziose. Noi le troviamo e forniamo la soluzione nel tuo codice template, nessun widget che rallenta il tuo sito.
Ecco come Seviranta interviene alla radice sul tuo sito WordPress
Dove si nascondono le barriere
Temi, estensioni e moduli introducono barriere silenziose. Noi le troviamo tutte.
La correzione alla fonte, non sopra
Interventi concreti nel tuo tema e plugin, senza uno strato overlay che si limita a nascondere gli errori.
Nessun widget, nessun rallentamento
Eseguiamo il crawl dall'esterno da server nell'UE, con 0% di impatto sulla velocità di caricamento e sui Core Web Vitals.
Pronto per l'EAA
Verifichiamo il tuo sito rispetto a WCAG, allo stesso livello a cui verificano le autorità di vigilanza.
Scansione headless su axe-core, lo stesso motore che sta dentro Google Lighthouse, dai nostri server nell'UE. 0% di impatto sulla tua velocità di caricamento.
La verità: WordPress non è accessibile per impostazione predefinita
Un tema a blocchi WordPress curato come Twenty Twenty-Four parte meglio di molti siti, ma raramente raggiunge da solo le WCAG 2.2 AA. Non appena inizi a costruire con Elementor, Divi o Gutenberg, lasci che i plugin inseriscano markup o aggiungi immagini senza testo alternativo, compaiono barriere che i tuoi visitatori, e l'European Accessibility Act, non accettano.
Cosa c'è davvero in gioco
- Un checkout non accessibile è una violazione diretta dell'EAA.
- Un widget di accessibilità non vale come soluzione strutturale.
- Le autorità di controllo testano l'HTML generato, incluse le tue app.
- 'Usiamo WordPress' non è una difesa legale: la responsabilità è del negozio online che è online, non della piattaforma.
Quanto può costare aspettare
fino a € 1.000.000
Massimo UE · Spagna/Lussemburgo
$ 4.000
USA · California (Unruh), per visita
Non vieni multato dall'oggi al domani, prima arriva un ordine di adeguamento con scadenza. Ma chi in quel momento può mostrare un dossier datato se la cava con la spesa minore.
Guarda cosa vale per il tuo mercato →Il rischio nascosto delle estensioni WordPress di terze parti
Widget di recensioni, filtri, bundler e app di ricerca iniettano HTML dinamico nel tuo frontend, e ogni aggiornamento di un'app può aggiungere una nuova barriera. In un audit quel codice conta a pieno titolo, anche se non l'hai scritto tu. Per questo Seviranta monitora in continuo il risultato finale così come lo vede un'autorità di vigilanza: il tuo tema WordPress più tutte le app e i contenuti dinamici.
Cosa va spesso storto su WordPress
- I page builder creano una div soup illeggibileElementor e Divi annidano sezioni, colonne e wrapper decine di livelli in profondità. Quella div soup non ha alcuna semantica, così uno screen reader perde la struttura logica della tua pagina e legge solo frammenti di testo sparsi.
- Markup dei plugin senza un nome accessibileSlider, pop-up e moduli dei plugin spesso inseriscono pulsanti e campi senza label o aria-label. Chi usa uno screen reader sente allora solo 'pulsante' e non ha idea di cosa faccia l'azione.
- Ordine dei titoli interrotto dal builderI page builder scelgono spesso i titoli in base alla dimensione invece che al significato, così salti da un h2 direttamente a un h4. Chi usa uno screen reader naviga tramite i titoli e perde il filo della tua pagina.
- Immagini della media library senza testo alternativoLe immagini della libreria multimediale finiscono spesso nel tuo tema senza testo alternativo, o con il nome del file come alt, illeggibili per gli screen reader e invisibili per Google.
Ecco com'è una vera soluzione
Prendi un pulsante con icona dal tuo blocco Elementor o Gutenberg. Senza un nome accessibile, chi usa uno screen reader sente solo 'pulsante'. La soluzione è un solo attributo, nessuna ricostruzione:
<button class="elementor-button">
<i class="icon-cart" aria-hidden="true"></i>
</button><button class="elementor-button"
aria-label="<?php esc_attr_e( 'Bekijk winkelwagen', 'theme' ); ?>">
<i class="icon-cart" aria-hidden="true"></i>
</button>Dove lo sistemi dentro WordPress
WordPress promette le WCAG 2.2 AA per l'admin e per i temi inclusi, dove possibile. Per i temi di terze parti, i plugin e i tuoi contenuti non promette nulla. È esattamente lì che sta il lavoro.
- 1Tema: leggere accessibility-ready per quello che èIl tag significa una revisione manuale su 18 requisiti di base: skip link come primo elemento focalizzabile, focus visibile di almeno 2 px, contrasto 4,5:1 e 3:1 per gli elementi di interfaccia, landmark, etichette dei moduli, nessun contenuto lampeggiante. WordPress stessa aggiunge che il tag non significa che il tema soddisfi le WCAG AA, e che le WCAG riguardano i contenuti e non possono essere applicate a un tema.
- 2Testo alternativo: nel blocco e nella libreriaIl blocco Image ha un campo 'Alternative text' e una casella 'Mark as decorative'; l'alt della libreria media è il valore predefinito, l'alt del blocco prevale. Descrivi ciò che l'immagine aggiunge. Attenzione alla lightbox: lì la didascalia è nascosta (issue aperta) e con un alt vuoto la finestra di ingrandimento non ha nome.
- 3Titoli e contrasto nell'editorUsa la scheda Outline in Document Overview per controllare l'ordine dei titoli; il titolo della pagina di solito è l'h1, a seconda del tema. L'editor avvisa in caso di contrasto basso ('This color combination may be hard for people to read'), ma solo nell'editor, solo per i blocchi con impostazioni colore e non per i colori trasparenti. Imposta la tua palette in theme.json o in Global Styles e vale ovunque.
- 4Lingua, navigazione e templateL'attributo lang viene da Impostazioni → Generali → Lingua del sito. Il blocco Navigation ha una issue aperta con una trappola di focus nel menu overlay quando un sottomenu è espanso; testa il tuo menu solo con Tab ed Esc. Template e parti di template si sovrascrivono in un child theme per nome file, oppure nel Site Editor su un tema a blocchi.
- 5Page builder e pluginElementor dice che devi solo fornire contenuti accessibili, ma lo skip link lo ottieni solo con il tema Hello, su Canvas o Full Width imposti tu l'ID CSS 'content', e ARIA passa dagli attributi personalizzati. Divi 4 rimanda a prodotti del marketplace per focus da tastiera e ARIA; Divi 5 aggiunge semantica e ARIA tramite Custom Attributes. Tutto ciò che un builder o un plugin renderizza sta nella stessa pagina e conta nell'audit.
Il WordPress Accessibility Team sconsiglia i widget overlay: nessuno strumento automatico raggiunge da solo la conformità. Elementor vende un widget del genere come 'Ally' e il marketplace di Divi un 'Accessibility Sidebar'. Uno strato sopra il tuo sito non ripara i blocchi che ci stanno sotto.
Cosa ottieni
Per ogni errore: cosa, perché e come
Per ogni rilevamento vedi cosa c'è di sbagliato, chi colpisce, quale regola WCAG riguarda e una soluzione concreta e pensata per WordPress, con un esempio di codice dove possibile.
Rilevamento specifico per piattaforma
Intercetti gli errori che nascono proprio su WordPress, non solo quelli che rileva un controllo WCAG generico.
Un dossier che regge
Una panoramica datata delle tue scansioni e dei tuoi rilevamenti che puoi mostrare durante un audit o un'ispezione.
Con uno strumento di reportistica paghi la licenza e i tuoi sviluppatori per risolvere gli errori. Con Seviranta la soluzione è inclusa, nessun doppio conto.
Proteggi la tua conversione e la tua posizione legale
Un'app che incolla un'icona di accessibilità sopra il tuo sito WordPress è un rischio per la tua attività. I fatti, in breve:
Widget di accessibilità per WordPress
- Caricano script esterni aggiuntivi che danneggiano la tua velocità di caricamento (LCP) e quindi la tua conversione.
- Mascherano l'errore invece di risolverlo, il codice di fondo resta sbagliato.
- Non ti proteggono dai reclami. La FTC ha multato il fornitore di overlay accessiBe per $1 milione nel 2025 per dichiarazioni di conformità ingannevoli.
L'approccio Seviranta
- 0% di impatto sulla tua velocità di caricamento, scansioniamo dall'esterno dai nostri server UE.
- Sistemiamo il vero codice sorgente dei tuoi template WordPress.
- Costruiamo automaticamente il tuo dossier EAA conservabile, pronto da mostrare a un'autorità di vigilanza.
Domande e risposte
- Il mio tema è accessibility-ready. Ho finito?
- No. Il tag dice che il tema soddisfa i requisiti di base del team di revisione; WordPress stessa dice che non è una dichiarazione WCAG AA. I tuoi contenuti, i tuoi plugin e il tuo builder si aggiungono sopra, ed è lì che sta la maggior parte dei rilievi.
- Vendo o pubblico anche per la Germania o la Francia. Cosa vale lì per il mio sito WordPress?
- Germania: il BFSG si applica ai negozi online B2C dal 28 giugno 2025, con un'esenzione per le microimprese (meno di dieci persone e al massimo 2 milioni di euro di fatturato o di totale di bilancio); la vigilanza spetta alla Marktüberwachungsstelle der Länder (MLBF). Francia: dal 28 giugno 2025 l'e-commerce rientra nel recepimento dell'EAA nel Code de la consommation, con la stessa esenzione per le microimprese, sotto la vigilanza della DGCCRF; il metro di misura è il RGAA (WCAG 2.1 AA). In entrambi i paesi conta la pagina pubblicata, non il fatto che usi WordPress.
- Posso applicare la correzione da solo nel Site Editor o serve il mio developer?
- Colori, titoli, testi alternativi, struttura del menu e molte parti di template puoi modificarli tu stesso nell'editor o nel Site Editor. Il markup di plugin o di un builder richiede spesso un developer: un override di template in un child theme, un filtro o un'impostazione del plugin. Il nostro report dice per ogni rilievo dove sta, così sai chi può occuparsene.
- Un widget di accessibilità per WordPress basta per l'EAA?
- No. Un widget mette uno strato sopra il tuo sito, ma non ripara il codice di fondo e non vale come conformità strutturale.
- Il mio checkout WordPress rientra nell'EAA?
- Sì. Il checkout e la navigazione fanno esplicitamente parte dell'obbligo previsto dalle WCAG 2.1 AA.
- Seviranta scansiona anche le mie app WordPress?
- Sì. Testiamo l'HTML finale generato, tema più app, così come fa un'autorità di controllo.
- Questo rallenta il mio sito WordPress?
- No. Scansioniamo dall'esterno dai nostri server UE; nessuno script finisce sul tuo sito. 0% di impatto sulla tua velocità di caricamento e sui Core Web Vitals.
Lo facciamo anche noi
Applichiamo a noi stessi esattamente lo stesso metro: il nostro sito segna 0 errori in axe-core, lo stesso motore che sta dentro Google Lighthouse e con cui analizziamo anche il tuo shop WordPress. Ciò che una macchina accerta con certezza lo risolviamo in automatico, il resto lo valuta una persona. Ecco con quanta precisione lo ricevi da noi: guarda un vero report di esempio.
Cosa richiede l'EAA al tuo negozio WordPress
Dal giugno 2025 il tuo negozio online deve soddisfare le WCAG 2.1 AA, un negozio WordPress non fa eccezione. In Italia questo recepisce l'EAA insieme alla Legge Stanca (D.lgs 82/2022). La scansione gratuita ti mostra in 60 secondi a che punto sei, con la riga esatta che non è conforme.
Vendi in più di un paese?
WCAG è lo standard mondiale. Quasi ogni mercato ci si basa:
Adegua il tuo negozio WordPress al WCAG una sola volta e copri l'asticella tecnica in tutti questi mercati. Ciò che cambia da un mercato all'altro è l'autorità che vigila e le sanzioni.
Scopri cosa vale per ogni mercato di destinazione →Gestisci più siti WordPress per i clienti?
Evita che i negozi online che consegni diventino un rischio legale sotto l'EAA per i tuoi committenti. Usa Seviranta come il tuo timbro di qualità automatizzato a ogni consegna e deploy, una scansione, e ogni sito è dimostrabilmente in regola.
Scopri il nostro programma partner →Altre piattaforme
Continua a leggere
Scansiona gratis il tuo negozio WordPress
Incolla l'URL del tuo WordPress nella scansione gratuita e scopri in meno di un minuto quali righe non sono conformi, con il punto esatto nel tuo tema o page builder.