Accessibilità e performance: perché conviene progettarle insieme

Accessibilità e performance vengono spesso assegnate a due momenti diversi del progetto.

Prima si costruisce il sito. Poi si prova a velocizzarlo. Infine, magari, si controlla se si usa da tastiera. È un ordine comodo perché distribuisce i problemi nel tempo. Non è un ordine molto efficace.

Le due cose condividono molte delle stesse decisioni: quanto JavaScript caricare, come costruire il markup, quali immagini servono davvero, come funzionano i componenti interattivi, cosa succede con una connessione lenta o senza mouse, e quanto un contenuto resta disponibile quando uno script non parte.

Il contenuto dovrebbe esistere prima dell’effetto

Un accordion, un popup, una tab o un carousel non dovrebbero dipendere da una coreografia JavaScript per rendere leggibile l’informazione principale. Se il contenuto esiste già nel markup e lo script aggiunge solo l’interazione, il sito ha un punto di partenza più solido: meno dipendenze inutili, fallback più chiari e comportamento più prevedibile.

È uno dei principi di Lumen ARIA Blocks, il plugin Gutenberg che ho pubblicato su WordPress.org. I blocchi mantengono il contenuto server-rendered e aggiungono l’interazione in modo progressivo; gli asset vengono caricati solo quando il relativo blocco è presente. Tastiera, focus, stati ARIA e preferenza per il movimento ridotto non sono dettagli da aggiungere dopo: cambiano il modo in cui il componente viene progettato.

Questo non certifica automaticamente un intero sito. Significa però che alcuni contratti tecnici sono stati messi nel posto giusto, dentro il componente e nel processo di release.

Velocità utile, non solo punteggio

Ridurre byte e richieste è importante, ma non basta a rendere un’esperienza buona. Una pagina può ottenere un buon punteggio e lasciare una persona senza etichette nei form, senza focus visibile o senza indicazioni quando un errore blocca un’azione.

Allo stesso modo, una correzione accessibile che aggiunge librerie, animazioni o controlli ridondanti senza criterio può rendere il sito più lento e più difficile da mantenere.

Per questo conviene lavorare su decisioni comuni:

• HTML semantico prima di ruoli ARIA superflui;
• immagini dimensionate e compresse senza eliminare alternative testuali utili;
• componenti interattivi con una gestione del focus reale;
• JavaScript caricato solo quando serve;
• animazioni che rispettano `prefers-reduced-motion`;
• form con label, messaggi di errore e stati comprensibili;
• test su dispositivi e connessioni meno indulgenti della workstation di chi sviluppa.

La manutenzione è parte della qualità

Un sito non resta accessibile e veloce perché lo è stato il giorno del lancio. Core, plugin, browser, contenuti e immagini cambiano. Anche una modifica apparentemente piccola può introdurre un contrasto insufficiente, una regressione nel layout, un redirect errato o un asset che blocca il caricamento.

Nel lavoro su e-commerce e sistemi WordPress, come IvoryLab Guitar Shop, qualità significa anche aggiornamenti controllati, verifiche di checkout e pagamenti, LCP/Core Web Vitals, accessibilità, analytics e compatibilità. Non è la parte più fotografabile di un progetto, ma è quella che evita di dover spiegare perché una vendita o un contatto si sono persi in silenzio.

Per questo accessibilità e performance entrano sia nei progetti di SEO on-site sia nella manutenzione WordPress. Non come checklist separata, ma come requisito di un sistema che deve continuare a funzionare per persone reali.