WooCommerce Accessibility: Guida WCAG 2.2 Completa 2026

Juan Camilo Auriti

Perché l’accessibilità è critica per WooCommerce

Nel 2026, l’accessibilità web non è più opzionale. Con l’European Accessibility Act in vigore e le nuove linee guida WCAG 2.2, gli e-commerce devono garantire accesso universale ai propri servizi. WooCommerce, che alimenta oltre il 36% degli shop online globali, presenta sfide specifiche: checkout complessi, filtri AJAX, moduli dinamici e interazioni JavaScript che possono facilmente escludere utenti con disabilità.

Per le agenzie web, l’accessibilità di WooCommerce significa:

Riduzione del rischio legale per i clienti (cause per discriminazione digitale in aumento del 240% dal 2023)
Aumento del 15-20% del tasso di conversione (dati Baymard Institute 2025)
Miglioramento SEO organico (Google Core Web Vitals integra metriche di accessibilità dal 2025)
Differenziazione competitiva nel mercato delle agenzie

Questo articolo fornisce una guida operativa per implementare l’accessibilità WCAG 2.2 livello AA su shop WooCommerce, con focus su codice, strumenti e workflow replicabili.

WCAG 2.2: novità rispetto alla versione 2.1

Le Web Content Accessibility Guidelines 2.2, pubblicate nell’ottobre 2023, introducono 9 nuovi criteri di successo rilevanti per WooCommerce:

Criteri critici per e-commerce

2.4.11 Focus Not Obscured (Minimum) – Livello AA: gli elementi focalizzati non devono essere nascosti da header sticky o overlay. Critico per checkout WooCommerce con menu fissi
2.4.12 Focus Not Obscured (Enhanced) – Livello AAA: focus completamente visibile
2.5.7 Dragging Movements – Livello AA: alternative a drag-and-drop (utile per gallery prodotto e slider)
2.5.8 Target Size (Minimum) – Livello AA: target minimi 24×24px (bottoni add-to-cart, quantity selectors)
3.2.6 Consistent Help – Livello A: meccanismi di aiuto in posizione coerente (chat, contatti)
3.3.7 Redundant Entry – Livello A: evitare reinserimento dati già forniti (billing/shipping address)
3.3.8 Accessible Authentication (Minimum) – Livello AA: login senza puzzle cognitivi
3.3.9 Accessible Authentication (Enhanced) – Livello AAA: nessun test cognitivo richiesto

Per WooCommerce, i criteri 2.5.8 (dimensioni target), 3.3.7 (ridondanza dati) e 2.4.11 (focus visibile) hanno l’impatto maggiore su UX e conversioni.

Audit accessibilità: strumenti e workflow

Prima di intervenire, serve una baseline. Il workflow consigliato combina test automatici, semi-automatici e manuali:

Stack strumenti per audit WooCommerce

Axe DevTools Pro (browser extension): identifica il 57% dei problemi WCAG. Essenziale per test rapidi su pagine prodotto e checkout
WAVE by WebAIM: visualizzazione inline di errori, utile per identificare problemi strutturali
Pa11y CI: integrazione in pipeline CI/CD per test regressione accessibilità
Screen reader reali: NVDA (Windows), VoiceOver (macOS/iOS), TalkBack (Android). Il 78% degli utenti screen reader usa NVDA o JAWS
Lighthouse CI: metriche accessibilità in Google Lighthouse, integrabile in GitHub Actions

Checklist audit WooCommerce

Testare specificamente queste aree:

Navigazione tastiera completa (Tab, Shift+Tab, Enter, Esc) su tutto il funnel
Annunci ARIA per aggiornamenti carrello e filtri prodotti
Contrasto colori su pulsanti CTA (minimo 4.5:1 per testo normale, 3:1 per large text)
Form labels corretti su tutti i campi checkout (billing, shipping, payment)
Gestione focus su modali (cart drawer, quick view, notices)
Alternative testuali per immagini prodotto e icone
Tabelle varianti accessibili (size, color pickers)

Un audit completo su shop medio (50-100 prodotti, 3 payment gateway) richiede 6-8 ore per tecnico senior.

Navigazione tastiera e gestione focus

La navigazione da tastiera è fondamentale: utenti con disabilità motorie, power users e utenti screen reader la utilizzano esclusivamente. WooCommerce out-of-the-box presenta diverse lacune.

Skip links e landmark ARIA

Implementare skip links per bypassare header e navigazione:

<a href="#main-content" class="skip-link screen-reader-text">
  Vai al contenuto principale
</a>
<a href="#sidebar" class="skip-link screen-reader-text">
  Vai ai filtri prodotti
</a>

CSS necessario:

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 100000;
  transition: top 0.2s ease;
}

.skip-link:focus {
  top: 0;
}

Aggiungere landmark ARIA alle sezioni principali:

<nav role="navigation" aria-label="Menu principale">...</nav>
<main role="main" id="main-content">...</main>
<aside role="complementary" aria-label="Filtri prodotti">...</aside>

Focus trap in modali e drawer

I drawer del carrello e le quick view devono intrappolare il focus. Soluzione con vanilla JS:

function trapFocus(element) {
  const focusableElements = element.querySelectorAll(
    'a[href], button:not([disabled]), input:not([disabled]), select:not([disabled]), textarea:not([disabled]), [tabindex]:not([tabindex="-1"])'
  );
  const firstElement = focusableElements[0];
  const lastElement = focusableElements[focusableElements.length - 1];

  element.addEventListener('keydown', function(e) {
    if (e.key !== 'Tab') return;
    
    if (e.shiftKey) {
      if (document.activeElement === firstElement) {
        lastElement.focus();
        e.preventDefault();
      }
    } else {
      if (document.activeElement === lastElement) {
        firstElement.focus();
        e.preventDefault();
      }
    }
  });
  
  firstElement.focus();
}

Applicare al drawer cart:

document.addEventListener('DOMContentLoaded', function() {
  jQuery(document.body).on('wc_fragments_refreshed', function() {
    const cartDrawer = document.querySelector('.cart-drawer');
    if (cartDrawer && cartDrawer.classList.contains('active')) {
      trapFocus(cartDrawer);
    }
  });
});

Focus visibile e WCAG 2.2

Il criterio 2.4.11 richiede che il focus sia sempre visibile, anche con header sticky. CSS moderno:

:focus-visible {
  outline: 3px solid #0066cc;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Garantire che elementi focati non siano oscurati da sticky header */
:target {
  scroll-margin-top: calc(var(--header-height) + 20px);
}

/* Per sticky header */
.site-header {
  position: sticky;
  top: 0;
  z-index: 999;
}

Checkout accessibile: il punto critico

Il checkout WooCommerce è dove si concentrano la maggior parte dei problemi di accessibilità. Un checkout inaccessibile può abbattere le conversioni del 30-40% per utenti con disabilità.

Form labels e istruzioni

Ogni campo deve avere un <label> associato correttamente:

add_filter('woocommerce_form_field_args', 'accessible_form_fields', 10, 3);

function accessible_form_fields($args, $key, $value) {
  // Rimuovere placeholder come sostituto di label
  if (isset($args['placeholder']) && $args['placeholder'] === $args['label']) {
    unset($args['placeholder']);
  }
  
  // Aggiungere required in modo accessibile
  if ($args['required']) {
    $args['label'] .= ' *';
    $args['custom_attributes']['aria-required'] = 'true';
  }
  
  // Aggiungere istruzioni per campi complessi
  if ($key === 'billing_phone') {
    $args['custom_attributes']['aria-describedby'] = 'phone-description';
    $args['description'] = 'Formato: +39 123 4567890';
  }
  
  return $args;
}

Validazione errori accessibile

Gli errori devono essere annunciati agli screen reader:

add_action('woocommerce_after_checkout_validation', 'announce_checkout_errors', 10, 2);

function announce_checkout_errors($data, $errors) {
  if ($errors->get_error_count() > 0) {
    // Aggiungere ARIA live region per errori
    add_action('woocommerce_before_checkout_form', function() use ($errors) {
      echo '';
      echo 'Attenzione: Ci sono ' . $errors->get_error_count() . ' errori nel modulo:';
      echo '';
      foreach ($errors->get_error_messages() as $message) {
        echo '' . esc_html($message) . '';
      }
      echo '';
    });
  }
}

Evitare input ridondanti (WCAG 2.2 – 3.3.7)

Copiare automaticamente billing address a shipping:

add_action('woocommerce_checkout_update_order_review', 'copy_billing_to_shipping');

function copy_billing_to_shipping($post_data) {
  parse_str($post_data, $data);
  
  if (isset($data['ship_to_different_address']) && $data['ship_to_different_address'] == '0') {
    // Già gestito da WooCommerce, ma aggiungere annuncio accessibile
    add_action('woocommerce_checkout_after_customer_details', function() {
      echo '';
      echo 'Indirizzo di spedizione copiato da indirizzo di fatturazione';
      echo '';
    });
  }
}

Payment gateway accessibili

Verificare che i gateway supportino navigazione tastiera:

Stripe: gli elementi Stripe sono accessibili out-of-the-box dal 2024
PayPal: i Smart Buttons richiedono configurazione ARIA custom
Bonifico/Contrassegno: verificare leggibilità istruzioni (contrasto, font size)

Per PayPal Smart Buttons:

add_filter('woocommerce_paypal_args', 'accessible_paypal_buttons');

function accessible_paypal_buttons($args) {
  $args['experience'] = array(
    'input_fields' => array(
      'no_shipping' => 1
    ),
    'presentation' => array(
      'brand_name' => get_bloginfo('name'),
      'locale_code' => 'IT'
    )
  );
  return $args;
}

Prodotti e filtri accessibili

Griglia prodotti e immagini

Ogni prodotto nella griglia deve avere alt text significativo:

add_filter('wp_get_attachment_image_attributes', 'woocommerce_product_image_alt', 10, 3);

function woocommerce_product_image_alt($attr, $attachment, $size) {
  if (is_shop() || is_product_category() || is_product_tag()) {
    global $product;
    if ($product) {
      $attr['alt'] = $product->get_name();
      // Aggiungere info prezzo per context
      $attr['aria-label'] = sprintf(
        '%s - Prezzo: %s',
        $product->get_name(),
        $product->get_price_html()
      );
    }
  }
  return $attr;
}

Filtri AJAX accessibili

I filtri prodotto devono annunciare aggiornamenti:

jQuery(document).ready(function($) {
  // Creare live region per annunci
  if ($('.woocommerce-products-header').length) {
    $('.woocommerce-products-header').after(
      ''
    );
  }
  
  // Intercettare aggiornamenti filtri
  $(document.body).on('updated_wc_div', function() {
    const productCount = $('.products .product').length;
    const announcer = $('#filter-announcer');
    
    announcer.text(
      productCount + ' prodotti trovati. Usa Tab per navigare i risultati.'
    );
    
    // Reset focus su primo prodotto
    $('.products .product:first a').focus();
  });
});

Varianti prodotto accessibili

Le varianti (colore, taglia) devono essere utilizzabili da tastiera e screen reader:

add_filter('woocommerce_dropdown_variation_attribute_options_html', 'accessible_variations', 10, 2);

function accessible_variations($html, $args) {
  // Usare select nativi invece di custom UI
  $html = str_replace(
    '';
  $html .= 'Usa frecce su/giù per navigare le opzioni, Enter per selezionare';
  $html .= '';
  
  return $html;
}

Plugin e temi accessibili

Plugin consigliati

WP Accessibility (gratuito): skip links, focus outlines, rimozione title attributes
Accessible Poetry (freemium): test automatici WCAG integrati in admin
UserWay Widget (SaaS): widget di accessibilità con overlay (controverso, usare con cautela)
One Click Accessibility (gratuito): font resizing, contrasto, focus keyboard

Attenzione: i widget overlay (UserWay, AccessiBe) sono criticati dalla comunità accessibility. Preferire sempre correzioni native nel codice.

Temi WooCommerce accessibili

Temi con certificazione WCAG 2.1 AA o superiore:

Storefront (WooCommerce ufficiale): base solida, richiede customizzazioni per 2.2
Astra Pro: moduli accessibili out-of-the-box, testato con screen reader
Kadence: focus management ottimo, header accessibili
GeneratePress Premium: markup semantico eccellente

Verificare sempre con audit prima di consegnare al cliente.

Testing con screen reader

Il test finale deve includere screen reader reali. Workflow consigliato:

Setup ambiente test

Installare NVDA (Windows) – gratuito e più usato
Configurare velocità lettura a 50% per debugging
Disabilitare CSS per verificare ordine DOM logico
Testare con solo tastiera prima di attivare screen reader

Checklist test screen reader WooCommerce

Home → Shop: navigazione categorie annunciata correttamente
Filtri prodotti: attributi e prezzi filtrabili da tastiera
Pagina prodotto: immagini, prezzo, varianti, add-to-cart annunciati
Carrello: quantità modificabile, rimozione prodotti accessibile
Checkout: compilazione completa solo tastiera
Conferma ordine: recap ordine leggibile

Registrare sessioni con OBS per documentare problemi e progressi.

Performance e accessibilità

Accessibilità e performance sono collegate. ARIA live regions e DOM complessi possono impattare le performance:

Best practices

Limitare ARIA live regions a 2-3 per pagina
Usare aria-live="polite" invece di assertive" quando possibile
Lazy load immagini prodotto ma garantire alt text caricato
Differire caricamento widget accessibilità (UserWay, etc.) con defer
Minimizzare DOM depth (max 15 livelli per sezione)

Monitorare Lighthouse Accessibility Score: target 90+ per shop conformi WCAG 2.2 AA.

Documentazione e handoff cliente

Consegnare al cliente documentazione accessibilità:

Deliverable consigliati

VPAT (Voluntary Product Accessibility Template): documento standard che dichiara conformità WCAG
Guida editor: come mantenere accessibilità inserendo nuovi prodotti (alt text, titoli, descrizioni)
Report audit: baseline + post-implementazione con score comparison
Checklist manutenzione: test mensili da eseguire (plugin updates, theme updates, test sample checkout)

Template VPAT disponibile su ITI VPAT.

FAQ

Quanto costa rendere un WooCommerce accessibile WCAG 2.2 AA?

Per uno shop medio (50-200 prodotti), preventivare 40-60 ore sviluppo: 8-12 ore audit iniziale, 20-30 ore implementazione correzioni, 8-12 ore test e validazione, 4-6 ore documentazione. A tariffa media agenzia €60-80/h, investimento €2.400-4.800. Shop complessi con custom checkout o multi-vendor richiedono 80-120 ore. Il ROI si recupera tipicamente in 6-9 mesi via aumento conversioni e riduzione bounce rate.

I plugin overlay di accessibilità (AccessiBe, UserWay) sono sufficienti?

No. Questi widget sono criticati da WebAIM e dalla comunità accessibility perché offrono fix superficiali senza correggere problemi strutturali nel codice. Possono anzi peggiorare l’esperienza per utenti screen reader. Nel 2025, cause legali hanno coinvolto siti che usavano solo overlay senza fix nativi. Vanno usati esclusivamente come complemento temporaneo mentre si implementano correzioni reali nel codice. Per conformità legale serve sempre intervento sul codebase.

Come testare l’accessibilità in fase di staging prima del deploy?

Integrare Pa11y CI o Axe-core in pipeline CI/CD. Esempio GitHub Actions workflow: installare Pa11y, crawlare shop staging (home, shop, prodotto sample, cart, checkout), generare report JSON, bloccare merge se score < 90. Aggiungere test manuali settimanali con NVDA su checkout completo. Per WooCommerce serve testare anche con carrello popolato e utente loggato (stati applicazione diversi). Automatizzare screenshot focus states con Playwright per regression visuale.

Quali sono gli errori accessibilità più comuni in WooCommerce out-of-the-box?

Top 5 errori: (1) immagini prodotto senza alt text significativo, (2) form checkout con placeholder al posto di label, (3) bottoni quantity +/- non accessibili da tastiera, (4) filtri AJAX senza annunci screen reader, (5) modali carrello senza focus trap. Altri frequenti: contrasto insufficiente su bottoni sale/badge, skip links mancanti, heading structure non gerarchica (h1 → h4 senza h2/h3), link “Leggi tutto” non descrittivi. La maggior parte risolvibili con 10-15 ore sviluppo mirato.

La conformità WCAG 2.2 è obbligatoria per legge in Italia?

Dal 28 giugno 2025 l’European Accessibility Act (EAA) è in vigore in Italia. Obbliga e-commerce con fatturato >2M€ o >10 dipendenti a conformità WCAG 2.1 AA (2.2 consigliato). Sanzioni fino a €100k per non conformità. Settore pubblico e fornitori PA già obbligati da Legge Stanca (2004) e CAD aggiornato. Per B2C privati sotto soglie EAA non c’è obbligo formale ma esposizione a cause civili per discriminazione (Art. 2 Cost.). Agenzie devono informare clienti su rischi legali e reputazionali della non conformità.