Accessibilità WordPress per la PA: Requisiti WCAG 2.2, Audit e Implementazione [2026]

La PA Italiana Ha un Problema di Accessibilità. Grosso.

L’AgID ha pubblicato le linee guida sull’accessibilità nel 2020. Siamo nel 2026 e la maggior parte dei siti WordPress della Pubblica Amministrazione non le rispetta. Non per cattiva volontà. Per ignoranza tecnica.

In 15 anni di lavoro con ASL, comuni e enti regionali, abbiamo toccato con mano la situazione. Siti istituzionali costruiti con page builder che generano HTML illeggibile dagli screen reader. Form di contatto senza label. PDF non taggati. Contrasti di colore che farebbero piangere un designer (e un ipovedente).

Questa guida non è teoria. È il processo che applichiamo sui siti PA gestiti con AgencyPilot: dall’audit iniziale all’implementazione, con codice reale e checklist pronte all’uso. Se gestisci siti WordPress per enti pubblici, questo è il tuo punto di partenza.

TL;DR — Cosa Serve per Rendere un Sito WordPress PA Accessibile

Conformità WCAG 2.2 livello AA obbligatoria per legge (Direttiva UE 2016/2102, recepita con D.Lgs. 106/2018). Serve: struttura HTML semantica, contrasti colore >= 4.5:1, navigazione da tastiera completa, alt text su tutte le immagini informative, form con label associate, documenti PDF accessibili. L’audit si fa con axe DevTools + test manuale con screen reader. Il costo di adeguamento di un sito WordPress medio: 3-5 giorni di lavoro per uno sviluppatore esperto. Il costo di non farlo: sanzioni AgID fino a 100.000€ e procedimenti amministrativi.

Il Quadro Normativo: Cosa Dice la Legge nel 2026

Mettiamo ordine. Le norme si sovrappongono e generano confusione. Ecco la catena completa:

Il punto chiave: dal giugno 2025, l’European Accessibility Act ha esteso l’obbligo di accessibilità anche alle aziende private che offrono servizi digitali. Non è più solo un problema della PA. Ma la PA resta il settore dove l’enforcement è più attivo, con AgID che pubblica i risultati del monitoraggio annualmente.

I siti WordPress della PA devono raggiungere almeno il livello AA delle WCAG 2.2. E devono pubblicare una dichiarazione di accessibilità aggiornata ogni anno (entro il 30 settembre). Se gestisci siti per enti pubblici con un sistema di gestione multi-sito, questo va tracciato per ogni singolo sito.

WCAG 2.2: I 9 Nuovi Criteri che Devi Conoscere

WCAG 2.2 ha aggiunto 9 criteri di successo rispetto alla versione 2.1. Non tutti sono livello AA (alcuni sono AAA), ma quelli AA sono obbligatori. Ecco quelli che impattano WordPress:

Focus Not Obscured (Minimum) — 2.4.11, Livello AA

Quando un elemento riceve il focus da tastiera, non deve essere completamente nascosto da altro contenuto. Sembra ovvio. Non lo è. Header sticky, modali, cookie banner: tutti possono oscurare l’elemento con focus.

/* Fix per header sticky che oscura il focus */
:focus {
  scroll-margin-top: 80px; /* altezza dell'header sticky */
}

/* Assicura che il focus sia sempre visibile sopra lo sticky header */
.site-header {
  position: sticky;
  top: 0;
  z-index: 100;
}

/* L'elemento focusato deve avere z-index superiore */
*:focus {
  position: relative;
  z-index: 101;
}

Focus Appearance — 2.4.13, Livello AAA (ma consigliato)

L’indicatore di focus deve avere un’area minima di 2px di contorno e un contrasto di almeno 3:1. Non è AA, quindi non è obbligatorio per legge. Ma implementarlo costa 5 minuti e migliora l’usabilità per tutti.

/* Focus ring accessibile e visibile */
:focus-visible {
  outline: 3px solid #1a56db;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Rimuovi l'outline solo per click mouse, mantienilo per tastiera */
:focus:not(:focus-visible) {
  outline: none;
}

Dragging Movements — 2.5.7, Livello AA

Qualsiasi funzionalità che usa il drag-and-drop deve avere un’alternativa single-pointer (click o tap). In WordPress, questo impatta i page builder con elementi trascinabili. Gutenberg è conforme dalla versione 6.4, ma plugin di terze parti spesso non lo sono.

Target Size (Minimum) — 2.5.8, Livello AA

I target cliccabili devono essere almeno 24×24 CSS pixel, o avere sufficiente spaziatura. Questo è il criterio che boccia più siti WordPress. Link nel footer ammassati, pulsanti social minuscoli, menu con voci ravvicinate.

/* Target size minimo 24x24px */
a, button, input[type="submit"], 
input[type="checkbox"], input[type="radio"],
.menu-item a {
  min-height: 24px;
  min-width: 24px;
  padding: 4px 8px;
}

/* Spaziatura adeguata tra link nel footer */
.footer-links a {
  display: inline-block;
  padding: 6px 12px;
  margin: 2px 0;
}

Audit di Accessibilità: Come Lo Facciamo in Pratica

L’audit è il primo passo. Senza sapere cosa non funziona, non puoi aggiustarlo. Ma attenzione: nessun tool automatico copre il 100% dei criteri WCAG. I tool automatici coprono circa il 30-40% dei problemi (studio Deque Systems 2024). Il resto richiede test manuale.

Fase 1: Scansione Automatica con axe DevTools

axe DevTools è lo standard de facto per l’audit automatico. È gratuito, open source, e integrato in Chrome DevTools. Ecco come lo usiamo:

1. Apri il sito in Chrome
2. DevTools → tab “axe DevTools” (o installa l’estensione)
3. Clicca “Scan All of My Page”
4. Classifica i risultati per impatto: Critical > Serious > Moderate > Minor

Per scansioni automatiche su larga scala (tutti i siti di un cliente PA), usiamo axe-core via CLI:

# Installa axe-core CLI
npm install -g @axe-core/cli

# Scansiona una singola pagina
axe https://comune.example.it --save risultati.json

# Scansiona più pagine da una lista
while IFS= read -r url; do
  axe "$url" --save "audit_$(echo $url | md5sum | cut -d' ' -f1).json"
done < pagine_da_testare.txt

# Esempio output: 12 violations found (3 critical, 5 serious, 4 moderate)

I problemi più frequenti che troviamo sui siti WordPress PA:

Questi numeri vengono dai nostri audit interni su 35 siti PA che abbiamo preso in gestione negli ultimi 3 anni. Il 92% con immagini senza alt sembra alto? Non lo è. È la norma.

Fase 2: Test Manuale con Screen Reader

La parte che nessuno vuole fare. Ma è la più importante.

Installa NVDA (gratuito, Windows) o usa VoiceOver (integrato in macOS). Poi naviga il sito senza mouse. Solo tastiera + screen reader. Le cose che scopri in 10 minuti di navigazione reale valgono più di 100 scansioni automatiche.

Cosa testare manualmente:

• Navigazione da tastiera: Tab per muoverti tra gli elementi. Enter per attivare link e pulsanti. Esc per chiudere modali. Ogni elemento interattivo deve essere raggiungibile e utilizzabile
• Ordine di lettura: lo screen reader legge il contenuto nell'ordine del DOM, non nell'ordine visivo. Se il layout CSS riordina gli elementi, l'ordine di lettura potrebbe non avere senso
• Form: ogni campo deve annunciare la sua etichetta. I messaggi di errore devono essere collegati al campo tramite aria-describedby
• Contenuto dinamico: se un'azione aggiorna parte della pagina (AJAX), lo screen reader deve esserne informato tramite aria-live regions

Fase 3: Test con Utenti Reali (Opzionale ma Raccomandato)

Per siti PA ad alto traffico (portali regionali, ASL, grandi comuni), raccomandiamo test con utenti reali con disabilità. Non è economico, ma è l'unico modo per validare davvero l'accessibilità. Organizzazioni come Fondazione ASPHI offrono servizi di testing con utenti in Italia.

Implementazione WordPress: Codice Reale per Problemi Reali

Passiamo al codice. Questi sono fix che applichiamo regolarmente sui siti PA gestiti.

Alt Text Automatico: Sistema di Audit e Reminder

Il problema numero uno. Risolverlo richiede un approccio sistematico, non un fix una tantum.

<?php
/**
 * Blocca la pubblicazione di post con immagini senza alt text.
 * Aggiunge un avviso nell'editor invece di bloccare silenziosamente.
 */
add_action('admin_notices', function() {
    global $post;
    if (!$post || $post->post_status !== 'publish') return;
    
    // Cerca immagini nel contenuto senza alt
    preg_match_all('/<img[^>]+>/i', $post->post_content, $matches);
    $missing_alt = [];
    
    foreach ($matches[0] as $img) {
        if (!preg_match('/alt=["\'][^"\']+["\']/i', $img)) {
            $missing_alt[] = $img;
        }
    }
    
    // Controlla anche l'immagine in evidenza
    $thumb_id = get_post_thumbnail_id($post->ID);
    if ($thumb_id) {
        $alt = get_post_meta($thumb_id, '_wp_attachment_image_alt', true);
        if (empty($alt)) {
            $missing_alt[] = 'Immagine in evidenza';
        }
    }
    
    if (!empty($missing_alt)) {
        echo '<div class="notice notice-warning">';
        echo '<p><strong>⚠️ Accessibilità:</strong> ';
        echo count($missing_alt) . ' immagini senza testo alternativo.';
        echo ' Aggiungere alt text è obbligatorio per i siti PA (WCAG 1.1.1).</p>';
        echo '</div>';
    }
});

Questo non blocca la pubblicazione (sarebbe troppo aggressivo per gli editor PA che spesso non sono tecnici), ma mostra un avviso chiaro. In AgencyPilot tracciamo il numero di immagini senza alt per sito e lo includiamo nei report mensili.

Skip Link e Navigazione da Tastiera

Ogni sito PA deve avere uno skip link come primo elemento focusabile. Permette agli utenti da tastiera di saltare il menu di navigazione e andare direttamente al contenuto.

<!-- Skip link: primo elemento nel body -->
<a href="#main-content" class="skip-link">
  Vai al contenuto principale
</a>

<!-- Il contenuto principale ha l'id corrispondente -->
<main id="main-content" role="main" tabindex="-1">
  <!-- contenuto -->
</main>

/* Skip link: invisibile di default, visibile su focus */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #1a56db;
  color: #ffffff;
  padding: 8px 16px;
  z-index: 10000;
  font-size: 16px;
  text-decoration: none;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
  outline: 3px solid #f59e0b;
  outline-offset: 2px;
}

Lo skip link è il test più rapido per capire se un sito WordPress è stato costruito con l'accessibilità in mente. Se non c'è, probabilmente manca tutto il resto.

Form Accessibili: Il Fix che Richiede 5 Minuti

Contact Form 7 è il plugin più usato sui siti PA. Di default genera HTML abbastanza accessibile, ma la configurazione tipica che troviamo non lo è. Il problema: i form builder permettono di creare campi senza label associate.

<!-- SBAGLIATO: nessun collegamento label-input -->
<p>Nome<br/>
<input type="text" name="nome"></p>

<!-- CORRETTO: label con for che punta all'id dell'input -->
<p>
  <label for="campo-nome">Nome <abbr title="obbligatorio">*</abbr></label>
  <input type="text" name="nome" id="campo-nome" 
         required aria-required="true">
</p>

<!-- CORRETTO: messaggio di errore collegato -->
<p>
  <label for="campo-email">Email <abbr title="obbligatorio">*</abbr></label>
  <input type="email" name="email" id="campo-email" 
         required aria-required="true"
         aria-describedby="email-errore">
  <span id="email-errore" class="errore" role="alert"></span>
</p>

L'attributo aria-describedby collega il campo al suo messaggio di errore. Quando l'utente con screen reader entra nel campo, sente anche il messaggio di errore (se presente). Senza questo collegamento, l'utente compila il form, invia, riceve errori che non riesce a trovare. Frustrante per chiunque. Impossibile per chi usa uno screen reader.

Contrasto Colore: Il Fix più Veloce con il ROI più Alto

Il rapporto di contrasto minimo WCAG è 4.5:1 per il testo normale e 3:1 per il testo grande (>= 18pt o >= 14pt bold). Molti temi WordPress usano grigi chiari su sfondo bianco che non raggiungono il 4.5:1.

/* PRIMA: contrasto insufficiente */
.text-muted {
  color: #999999; /* rapporto 2.85:1 su bianco — BOCCIATO */
}

/* DOPO: contrasto sufficiente */
.text-muted {
  color: #595959; /* rapporto 7.0:1 su bianco — OK AA e AAA */
}

/* Colori comuni per siti PA con contrasto AA garantito */
:root {
  --colore-primario: #1a56db;    /* 5.2:1 su bianco */
  --colore-testo: #1f2937;       /* 14.7:1 su bianco */
  --colore-testo-secondario: #4b5563; /* 7.0:1 su bianco */
  --colore-link: #1a56db;        /* 5.2:1 su bianco */
  --colore-link-hover: #1e40af;  /* 7.1:1 su bianco */
  --colore-errore: #b91c1c;      /* 5.9:1 su bianco */
  --colore-successo: #15803d;    /* 4.6:1 su bianco */
}

Usa WebAIM Contrast Checker per verificare ogni combinazione. 30 secondi per controllo. Non ci sono scuse.

Documenti PDF Accessibili: Il Punto Cieco della PA

Il 90% dei documenti pubblicati sui siti PA sono PDF. E il 90% di quei PDF non è accessibile. I PDF generati da Word senza tagging, scansioni di documenti cartacei senza OCR, delibere pubblicate come immagini. Una catastrofe per l'accessibilità.

Le regole minime per PDF accessibili:

• PDF taggati: la struttura del documento (heading, paragrafi, tabelle, liste) deve essere esplicita nei tag PDF
• Ordine di lettura definito: lo screen reader deve poter leggere il contenuto nell'ordine corretto
• Testo selezionabile: niente scansioni senza OCR. Se non puoi selezionare il testo, non è accessibile
• Alt text per immagini: anche dentro i PDF
• Lingua del documento: specificata nei metadati

Per i PDF generati dal sito WordPress (fatture, certificati, report), usiamo la libreria TCPDF o mPDF con le opzioni di tagging attive:

// Esempio con mPDF: generare PDF accessibile
$mpdf = new \Mpdf\Mpdf([
    'mode' => 'utf-8',
    'format' => 'A4',
]);

// Imposta tag di accessibilità
$mpdf->SetTitle('Delibera n. 123/2026');
$mpdf->SetAuthor('Comune di Esempio');
$mpdf->SetSubject('Delibera consiglio comunale');
$mpdf->SetKeywords('delibera, consiglio, comune');

// Lingua del documento
$mpdf->SetDefaultBodyCSS('lang', 'it');

// Il contenuto HTML viene convertito con struttura taggata
$mpdf->WriteHTML($contenuto_html);
$mpdf->Output('delibera_123_2026.pdf', 'F');

Per i documenti caricati manualmente (il caso più comune nella PA), la soluzione è formare gli operatori. Un'ora di formazione su come esportare PDF accessibili da Word salva mesi di correzioni successive. Nella nostra piattaforma di gestione includiamo guide video per gli operatori PA proprio su questo punto.

Dichiarazione di Accessibilità: Template e Automazione

Ogni sito PA deve pubblicare una dichiarazione di accessibilità. AgID ha un modulo online per generarla, ma il contenuto va preparato con i risultati dell'audit.

La dichiarazione deve includere:

1. Stato di conformità: conforme, parzialmente conforme, o non conforme
2. Contenuti non accessibili: lista specifica di cosa non è conforme e perché
3. Meccanismo di feedback: come gli utenti possono segnalare problemi di accessibilità
4. Data dell'ultimo audit
5. Link al Difensore Civico Digitale per i reclami

<?php
/**
 * Shortcode per la dichiarazione di accessibilità.
 * Mantiene la data dell'ultimo audit aggiornata automaticamente
 * e genera un form di feedback conforme.
 */
add_shortcode('dichiarazione_accessibilita', function($atts) {
    $atts = shortcode_atts([
        'stato' => 'parzialmente conforme',
        'data_audit' => '2026-03-15',
        'email_feedback' => 'accessibilita@ente.gov.it',
    ], $atts);
    
    ob_start();
    ?>
    <section aria-labelledby="acc-title">
      <h2 id="acc-title">Dichiarazione di Accessibilità</h2>
      <p>Questo sito è <strong><?= esc_html($atts['stato']) ?></strong> 
         alle WCAG 2.2 livello AA.</p>
      <p>Ultimo audit: <time datetime="<?= esc_attr($atts['data_audit']) ?>">
         <?= date_i18n('j F Y', strtotime($atts['data_audit'])) ?></time></p>
      
      <h3>Segnala un problema di accessibilità</h3>
      <p>Se riscontri barriere di accessibilità su questo sito, contattaci: 
         <a href="mailto:<?= esc_attr($atts['email_feedback']) ?>">
         <?= esc_html($atts['email_feedback']) ?></a></p>
      
      <h3>Difensore Civico Digitale</h3>
      <p>Se la risposta non è soddisfacente, puoi rivolgerti al 
         <a href="https://www.difensivocivicodigitale.it/" 
            target="_blank" rel="noopener">Difensore Civico Digitale</a>.</p>
    </section>
    <?php
    return ob_get_clean();
});

Checklist Operativa: 25 Controlli per Siti WordPress PA

Questa è la checklist che usiamo su ogni sito PA gestito. Copre i criteri WCAG 2.2 livello AA più rilevanti per WordPress.

Struttura e Semantica

Immagini e Media

Navigazione e Interazione

Colori e Presentazione

Form e Input

Documenti

Monitoraggio Continuo: Non Basta un Audit una Tantum

L'accessibilità non è un progetto con una data di fine. È un processo continuo. Ogni nuovo contenuto pubblicato, ogni aggiornamento tema, ogni nuovo plugin può introdurre regressioni.

In AgencyPilot abbiamo integrato un check di accessibilità automatico che gira settimanalmente su tutte le pagine principali di ogni sito PA gestito. Usa axe-core via headless Chrome e genera un report con il trend nel tempo.

// Script Node.js per audit automatico con axe-core e Puppeteer
const puppeteer = require('puppeteer');
const { AxePuppeteer } = require('@axe-core/puppeteer');

async function auditPage(url) {
  const browser = await puppeteer.launch({ headless: 'new' });
  const page = await browser.newPage();
  await page.goto(url, { waitUntil: 'networkidle2' });
  
  const results = await new AxePuppeteer(page)
    .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])
    .analyze();
  
  await browser.close();
  
  return {
    url,
    timestamp: new Date().toISOString(),
    violations: results.violations.length,
    critical: results.violations.filter(v => v.impact === 'critical').length,
    serious: results.violations.filter(v => v.impact === 'serious').length,
    details: results.violations.map(v => ({
      id: v.id,
      impact: v.impact,
      description: v.description,
      nodes: v.nodes.length,
    })),
  };
}

Il trend è la metrica chiave. Se le violazioni aumentano da una settimana all'altra, qualcosa è andato storto. Se diminuiscono, il lavoro sta funzionando. Senza monitoraggio continuo, l'accessibilità degrada nel tempo. Sempre.

Questo si integra con il sistema di monitoraggio WordPress che già usiamo per uptime e performance. Un unico cruscotto per tutto.

I Temi WordPress Più Accessibili per la PA

Non tutti i temi WordPress nascono uguali per l'accessibilità. Alcuni sono costruiti con l'accessibilità come priorità. Altri la ignorano completamente.

I temi che raccomandiamo per siti PA:

• Developer Italia Design WordPress Theme: il tema ufficiale basato sul Design System Italia di AgID. Costruito appositamente per i siti PA italiani. Non è il più flessibile, ma è il più conforme out-of-the-box
• GeneratePress: minimale, leggero (sotto 30KB), e con un'ottima base di accessibilità. Skip link, ARIA landmark, focus ring inclusi di default. Perfetto come base per temi custom PA
• Flavor flavored theme di Developer Italia: basato su Bootstrap Italia 2.x, con componenti accessibili preconfigurati

Cosa evitare: qualsiasi page builder che genera div nidificati senza semantica. Elementor, Divi, WPBakery producono HTML che è un incubo per gli screen reader (anche se negli ultimi anni hanno fatto progressi). Per la PA, meglio Gutenberg nativo con blocchi custom accessibili.

Costi e Tempi di Adeguamento: Numeri Reali

Quanto costa rendere accessibile un sito WordPress PA esistente? Dipende dallo stato di partenza, ma ecco i numeri medi dalla nostra esperienza:

Il terzo scenario (sito legacy con page builder) è il più comune nella PA. E spesso il rifacimento completo costa meno dell'adeguamento, perché patchare un sito costruito senza accessibilità è come ristrutturare una casa senza fondamenta.

Il costo di non fare nulla? Sanzioni AgID, azioni legali, e soprattutto: cittadini con disabilità che non possono accedere ai servizi pubblici. Questo dovrebbe essere il motivo principale, non le sanzioni. Ma i numeri aiutano a convincere chi gestisce il budget.

FAQ — Domande Frequenti sull'Accessibilità WordPress per la PA

Quali sono le sanzioni per un sito PA non accessibile?

AgID può comminare sanzioni amministrative fino a 100.000€ e ordinare l'adeguamento con tempi definiti. Il D.Lgs. 106/2018 prevede anche la responsabilità del dirigente responsabile. Nella pratica, le sanzioni sono ancora rare, ma il monitoraggio AgID sta diventando più stringente anno dopo anno.

Un plugin di accessibilità può rendere il mio sito conforme?

No. I plugin "overlay" (come AccessiBe, UserWay) aggiungono widget per modificare font e contrasto, ma non risolvono i problemi strutturali di accessibilità. Lo screen reader non legge meglio un form senza label solo perché c'è un widget che ingrandisce il testo. WCAG richiede accessibilità nativa nel codice HTML. I plugin overlay sono un cerotto cosmetico, non una soluzione.

Gutenberg è accessibile?

Gutenberg ha fatto enormi passi avanti sull'accessibilità dall'editor (lato backend) e genera HTML semantico per i blocchi nativi (paragrafi, heading, liste, tabelle, immagini con alt). I problemi emergono con blocchi custom di terze parti che non seguono le linee guida di accessibilità di WordPress. Regola: usa blocchi nativi dove possibile, testa con screen reader quelli custom.

Come gestisco l'accessibilità dei contenuti caricati dagli operatori PA?

Formazione + strumenti. Formare gli operatori su: alt text per immagini, heading gerarchici, link descrittivi (mai "clicca qui"), PDF accessibili da Word. E aggiungere controlli automatici nel CMS (come lo snippet PHP sopra) che avvisano quando manca qualcosa. L'80% dei problemi di accessibilità nei siti PA è causato dai contenuti, non dal codice.

Con quale frequenza devo rifare l'audit di accessibilità?

Audit completo (automatico + manuale + screen reader): almeno annuale, e dopo ogni redesign significativo. Scansione automatica (axe-core): settimanale. Aggiornamento dichiarazione di accessibilità: annuale entro il 30 settembre. Se usi automazione nella gestione WordPress, la scansione settimanale non costa nulla.