Accessibilità WCAG 2.2 e WordPress: conformità AA senza plugin, con codice

L'accessibilità è il tema più trascurato e più costoso del web. Trascurato perché non si vede — il sito funziona, i clienti arrivano, chi si accorge se uno screen reader non legge bene un form? Costoso perché quando ci si accorge, è una causa legale: l'European Accessibility Act entra in vigore nel 2025, e i siti di aziende con più di 10 dipendenti devono essere accessibili. Negli Stati Uniti, l'ADA ha già generato migliaia di cause. L'accessibilità non è un optional — è un requisito che si paga in cause legali se ignorato.

Il primo malinteso è che l'accessibilità si risolvi con un plugin. Non è così. Un plugin può aggiungere un menu di accessibilità (regolazione contrasto, dimensione font), ma non può rendere accessibile un tema che non lo è. Se i tuoi bottoni non hanno etichette ARIA, se i form non hanno label associate, se l'ordine di tabulazione salta, il plugin non li sistema. L'accessibilità si costruisce nel codice — non si aggiunge dopo.

Contrasto: la cosa più facile e più trascurata

Il contrasto del testo è il primo controllo di WCAG — e il più facile da fallire. WCAG 2.2 AA richiede un rapporto di contrasto di 4.5:1 per testo normale e 3:1 per testo grande. Il grigio chiaro su sfondo bianco che molti temi usano per il testo secondario fallisce quasi sempre. Un grigio #999 su bianco ha un contrasto di 2.8:1 — sotto la soglia. Il grigio #666 ha 5.7:1 — sopra. La differenza è invisibile ad occhio ma misurabile con un tool.

/* CSS — correggi il contrasto del testo secondario */

/* SBAGLIATO: contrasto 2.8:1 (fallisce WCAG AA) */
.text-muted {
    color: #999;
}

/* CORRETTO: contrasto 5.7:1 (passa WCAG AA) */
.text-muted {
    color: #666;
}

/* Ancora meglio: usa variabili CSS con token accessibili */
:root {
    --text-primary: #1a1a1a;    /* contrasto 16:1 su bianco */
    --text-secondary: #555;       /* contrasto 7.5:1 su bianco */
    --text-muted: #666;           /* contrasto 5.7:1 — limite AA */
    --text-on-primary: #fff;      /* su sfondo --primary */
    --text-link: #2563eb;         /* contrasto 5.2:1 su bianco */
}

/* Verifica: il link deve avere contrasto 4.5:1 come testo
   E 3:1 come link non visitato (sottolineato o con indicatore) */
a {
    color: var(--text-link);
    text-decoration: underline; /* mai rimuovere senza alternativa */
}

Navigazione da tastiera: il focus deve essere visibile

WCAG richiede che ogni elemento interattivo sia raggiungibile e usabile da tastiera. Il primo requisito è il focus visibile: quando tabuli, devi vedere dove sei. Molti temi rimuovono l'outline del focus per estetica — e questo è una violazione WCAG. La soluzione non è rimuovere l'outline ma stilizzarlo:

/* CSS — focus visibile e accessibile */

/* MAI rimuovere l'outline del focus */
/* *:focus { outline: none; } ← SBAGLIATO */

/* CORRETTO: outline visibile con buon contrasto */
*:focus {
    outline: 2px solid var(--primary);
    outline-offset: 2px;
    border-radius: 2px;
}

/* Per i link, un focus più prominente */
a:focus-visible {
    outline: 2px solid var(--primary);
    outline-offset: 2px;
    background: color-mix(in srgb, var(--primary) 10%, transparent);
}

/* Per i campi form, un focus che indica chiaramente il campo attivo */
input:focus-visible,
textarea:focus-visible,
select:focus-visible {
    border-color: var(--primary);
    box-shadow: 0 0 0 3px color-mix(in srgb, var(--primary) 25%, transparent);
}

ARIA: usalo quando serve, non quando puoi

ARIA (Accessible Rich Internet Applications) è uno strumento potente ma pericoloso. La regola di WCAG è: usa ARIA solo quando il HTML semantico non basta. Se un bottone è un <button>, non ha bisogno di role='button'. Se una navigazione è un <nav>, non ha bisogno di role='navigation'. ARIA non rende accessibile qualcosa che non lo è — rende accessibile qualcosa che il HTML non può esprimere (es. un menu a tendina custom, un accordion, un modal).

L'errore più comune è aggiungere aria-label dove non serve o dove è ridondante. Esempi di uso corretto e scorretto:

<?php
// SBAGLIATO: aria-label ridondante su un link con testo
<a href="/contatti" aria-label="Contattaci">Contattaci</a>
// Lo screen reader legge "Contattaci, Contattaci" — ridondante

// CORRETTO: il testo del link basta
<a href="/contatti">Contattaci</a>

// CORRETTO: aria-label quando il link ha solo un'icona
<a href="/contatti" aria-label="Contattaci">
    <svg aria-hidden="true"><use href="#icon-mail" /></svg>
</a>

// SBAGLIATO: role="button" su un link
<a href="#" role="button" onclick="toggle()">Apri</a>
// Usa un <button> vero se è un'azione, non una navigazione

// CORRETTO: button semantico
<button type="button" onclick="toggle()">Apri</button>

// SBAGLIATO: aria-hidden="true" su contenuto importante
<span aria-hidden="true">Prezzo: 29€</span>
// Lo screen reader non lo legge — il prezzo è invisibile

// CORRETTO: aria-hidden solo per contenuto decorativo
<span aria-hidden="true">★</span> <span>4.8/5</span>

Il test: non serve uno screen reader, basta la tastiera

Il test di accessibilità più rapido non richiede strumenti — richiede di mettere giù il mouse. Naviga il sito solo con la tastiera: Tab per avanzare, Shift+Tab per indietro, Enter per attivare. Se non riesci a raggiungere un elemento interattivo, non è accessibile. Se il focus non si vede, non è accessibile. Se l'ordine di tabulazione salta, non è accessibile. Questo test prende due minuti e rileva il 60% dei problemi di accessibilità.

# Test automatici con Lighthouse (integra i controlli WCAG)
# Lighthouse > Accessibility audit
# Oppure con axe-core (più completo):

# Installa axe-core come dipendenza dev
npm install --save-dev @axe-core/cli

# Testa una pagina
axe https://www.example.com/ --tags wcag2aa

# Output: lista delle violazioni WCAG 2.2 AA con selettore CSS
# e suggerimento di correzione

L'accessibilità è il tipo di lavoro che non si vede ma che si sente — quando un cliente con disabilità non può completare un acquisto, quando una causa arriva, quando Google penalizza il sito per mancata accessibilità mobile. Non è glamour, non è visibile, ma è il lavoro che separa un sito professionale da uno amatoriale. E su WordPress, dove il codice è tuo, non c'è scusa per non farlo bene.