Accessibilità e prestazioni vengono spesso trattate come discipline separate, con specialisti, strumenti e checklist diversi. L’accessibilità si occupa di rendere un sito utilizzabile da persone con disabilità visive, motorie, uditive o cognitive; le prestazioni di renderlo veloce e reattivo. Eppure, a guardarle da vicino, le due discipline hanno lo stesso obiettivo: far funzionare il sito per tutti, e in particolare per chi lo usa in condizioni diverse da quelle in cui è stato progettato.
Uno smartphone economico, una rete lenta, un lettore di schermo, un ingranditore, un braccio ingessato, il sole che rende illeggibile lo schermo: sono tutte situazioni in cui un sito pesante e instabile diventa difficile da usare, e in cui un sito ben costruito continua a funzionare. In questo articolo vediamo dove accessibilità e prestazioni si incontrano, dove una buona scelta serve entrambe, e dove un’ottimizzazione per le prestazioni fatta male può creare barriere.
Gli stessi utenti, spesso
Un primo punto di contatto riguarda le persone. Chi usa tecnologie assistive non sempre dispone del dispositivo più recente, e i lettori di schermo aggiungono essi stessi un carico di lavoro: devono ricostruire la struttura della pagina, seguirne le modifiche e annunciarle. Una pagina con migliaia di elementi e molto JavaScript, già lenta su uno smartphone di fascia media, lo diventa ancora di più quando il dispositivo deve anche alimentare un lettore di schermo. Molte persone anziane, che beneficiano di un’interfaccia accessibile, usano dispositivi meno recenti e connessioni meno veloci.
C’è poi la disabilità situazionale, che riguarda chiunque: usare il telefono con una mano sola sul tram, leggere in pieno sole, navigare con una connessione instabile in treno. In queste condizioni, pagine lente, contenuti che si spostano e pulsanti che non rispondono sono ostacoli per tutti. Progettare per i casi limite, in entrambe le discipline, migliora l’esperienza della maggioranza.
HTML semantico: meno codice, più accessibilità
Il punto di incontro più importante è l’HTML semantico. Un pulsante realizzato con l’elemento button è raggiungibile con la tastiera, attivabile con Invio e Spazio, annunciato correttamente dai lettori di schermo, e non richiede una sola riga di JavaScript per nessuna di queste funzioni. Lo stesso pulsante realizzato con un div richiede attributi ARIA per il ruolo, un indice di tabulazione, gestori di eventi per tastiera e mouse, e spesso una libreria per gestire il focus: più codice da scaricare ed eseguire, e più occasioni di errore.
Lo stesso vale per molti componenti comuni. Un pannello espandibile può essere realizzato con details e summary, accessibili e funzionanti senza JavaScript; una finestra modale con l’elemento dialog, che gestisce il focus e la chiusura con il tasto Esc; un menu a tendina di selezione con select. Le librerie di componenti che ricostruiscono tutto con elementi generici e JavaScript sono spesso sia più pesanti sia meno accessibili delle alternative native. Scegliere gli elementi del browser, quando esistono, è la scelta che serve entrambe le discipline.
<!-- Domande frequenti: accessibili e funzionanti senza JavaScript -->
<details>
<summary>Quanto tempo richiede la spedizione?</summary>
<p>Gli ordini partono entro 24 ore lavorative…</p>
</details>Il layout stabile
Il CLS misura gli spostamenti inattesi del contenuto, ed è forse la metrica più direttamente legata all’accessibilità. Per chi ha un tremore, usa un sistema di puntamento alternativo o si muove più lentamente, il tempo tra la decisione di toccare un elemento e il tocco effettivo è più lungo, e uno spostamento in quell’intervallo porta a un tocco sull’elemento sbagliato. Per chi usa un ingranditore e vede solo una piccola porzione della pagina, uno spostamento significa perdere il punto in cui stava leggendo. Per chi ha difficoltà cognitive o di attenzione, un contenuto che si muove è una fonte di confusione.
Le linee guida sull’accessibilità chiedono che l’interfaccia sia prevedibile e che i cambiamenti di contesto non avvengano senza che l’utente li abbia richiesti. Un CLS basso non basta a garantirlo, perché la metrica valuta l’insieme degli spostamenti e non il singolo spostamento nel momento sbagliato, ma tutte le tecniche per ridurlo, come dimensioni esplicite per immagini e video, spazio riservato per banner e pubblicità, contenuti inseriti sotto e non sopra ciò che l’utente sta guardando, servono direttamente anche l’accessibilità.
Reattività e tecnologie assistive
L’INP misura il tempo di risposta alle interazioni. Per chi usa la tastiera o un lettore di schermo, un’interfaccia che risponde lentamente è ancora più problematica: senza un riscontro visivo immediato, o con un riscontro che arriva dopo mezzo secondo, è difficile capire se un comando è stato ricevuto, e la tentazione di ripeterlo produce doppi invii e azioni indesiderate. I lunghi task JavaScript che rallentano l’INP rallentano anche l’aggiornamento delle informazioni che il browser fornisce alle tecnologie assistive, che possono annunciare i cambiamenti in ritardo o in ordine confuso.
Le soluzioni sono le stesse viste parlando del main thread: meno JavaScript, lavoro diviso in parti più piccole, riscontro immediato prima delle elaborazioni. A queste si aggiunge un aspetto specifico dell’accessibilità: il riscontro non deve essere solo visivo. Un’area con aria-live che annuncia «Prodotto aggiunto al carrello» dà a chi usa un lettore di schermo la stessa conferma immediata che un’icona animata dà a chi vede lo schermo.
Il movimento ridotto
Molti sistemi operativi permettono all’utente di chiedere animazioni ridotte, un’impostazione importante per chi soffre di disturbi vestibolari, per cui animazioni ampie, parallasse e zoom possono provocare nausea e vertigini. Il sito può leggerla con la media query prefers-reduced-motion e ridurre o eliminare le animazioni. È una scelta di accessibilità, ma ha anche un effetto sulle prestazioni: meno animazioni significa meno lavoro per il browser, meno script per gestirle e, spesso, contenuti visibili prima.
@media ( prefers-reduced-motion: reduce ) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}Lo stesso vale per i contenuti che si muovono da soli: caroselli che scorrono automaticamente e video di sfondo che partono all’apertura della pagina. Le linee guida chiedono che possano essere messi in pausa; dal punto di vista delle prestazioni sono tra gli elementi più costosi, come abbiamo visto nell’articolo su video e Core Web Vitals. Rinunciare all’avvio automatico, o almeno rispettare la preferenza di movimento ridotto mostrando solo un’immagine statica, serve entrambe le discipline.
Testo come testo
Un testo inserito come immagine, come un titolo in un banner, una tabella di prezzi esportata come grafica, un’infografica con i dati principali, è un ostacolo per chi usa un lettore di schermo, non si adatta all’ingrandimento del testo, non si traduce automaticamente e pesa molto più del testo equivalente. Il testo vero, con i caratteri del sito, è accessibile, leggero, nitido su qualsiasi schermo e indicizzabile. Quando un’immagine con testo è inevitabile, il testo alternativo deve riportarne il contenuto.
I font meritano un’attenzione particolare. Un font che arriva in ritardo, con la regola font-display: block, lascia il testo invisibile per diverse centinaia di millisecondi: una perdita di tempo per tutti e un problema per chi ha bisogno di più tempo per leggere. Con font-display: swap il testo compare subito con un carattere di riserva, e l’uso delle proprietà di regolazione delle metriche dei font limita lo spostamento al momento della sostituzione, come visto nell’articolo sul subsetting dei font. E lo zoom non va mai disabilitato con user-scalable=no: era una pratica diffusa per eliminare un ritardo al tocco dei vecchi browser mobili, un problema che i browser moderni hanno risolto da anni.
Quando l’ottimizzazione crea barriere
Non tutte le ottimizzazioni sono neutre per l’accessibilità. Alcune tecniche diffuse, applicate senza attenzione, possono renderla peggiore.
- Il ritardo del JavaScript all’interazione. Molti plugin caricano gli script solo al primo movimento del mouse, tocco o scorrimento. Se non considerano anche la pressione di un tasto, chi naviga solo con la tastiera può trovarsi con menu, moduli e pulsanti che non funzionano, come abbiamo visto parlando del delay del JavaScript. Va verificato navigando il sito solo con la tastiera.
- Le facciate. Un’anteprima di un video o di una chat che sostituisce il componente reale deve essere un vero pulsante, con un’etichetta chiara, raggiungibile con la tastiera. E quando il componente reale viene caricato, il focus deve spostarsi su di esso, non perdersi.
- La rimozione del CSS inutilizzato. Può eliminare gli stili del focus, quelli per il testo destinato ai soli lettori di schermo o quelli di stati attivati da tastiera, che l’analisi automatica non vede.
- Il caricamento differito dei contenuti. Contenuti che compaiono solo con lo scorrimento possono essere invisibili a chi naviga con un lettore di schermo, che non scorre la pagina come un utente con il mouse. Il lazy loading nativo delle immagini non ha questo problema; le soluzioni che inseriscono testo solo durante lo scorrimento sì.
- I banner dei cookie. Un banner caricato tardi e compatto per ragioni di prestazioni deve comunque ricevere il focus quando compare ed essere utilizzabile con la tastiera, come spiegato nell’articolo sui consent banner.
Le Single Page Application e il focus
Un caso particolare riguarda le applicazioni che cambiano pagina senza ricaricarla. In una navigazione tradizionale, il browser annuncia il titolo della nuova pagina e riporta il focus all’inizio del documento. In una Single Page Application, se il codice non lo fa esplicitamente, un utente con lettore di schermo può non accorgersi che il contenuto è cambiato e trovarsi con il focus su un elemento non più visibile. È un altro argomento a favore delle pagine tradizionali con strumenti moderni, come il prerender e le transizioni tra documenti, che conservano il comportamento accessibile del browser.
Il quadro normativo
Per molte organizzazioni l’accessibilità non è più solo una buona pratica. In Italia gli obblighi di accessibilità esistono da anni per la pubblica amministrazione, e con il recepimento dell’European Accessibility Act si estendono dal 28 giugno 2025 a molti servizi privati rivolti ai consumatori, tra cui il commercio elettronico, con alcune esclusioni per le microimprese. Il riferimento tecnico sono le linee guida WCAG. Le prestazioni non sono un requisito esplicito delle norme, ma molte delle soluzioni che le migliorano, come l’HTML semantico, il layout stabile e il rispetto delle preferenze dell’utente, contribuiscono anche alla conformità.
Verificare entrambe
Lighthouse include una sezione dedicata all’accessibilità accanto a quella sulle prestazioni, e vale la pena guardarle insieme a ogni verifica. I controlli automatici, però, coprono solo una parte dei problemi di accessibilità, come il contrasto dei colori, i testi alternativi mancanti e le etichette dei moduli. Il resto richiede prove manuali, e le più semplici sono alla portata di chiunque: navigare il sito solo con la tastiera, attivare la preferenza di movimento ridotto, ingrandire il testo al 200%, provare un lettore di schermo sulle pagine principali, usare il sito con uno smartphone economico su una connessione lenta. Sono le stesse condizioni in cui emergono i problemi di prestazioni.
In sintesi
Accessibilità e prestazioni servono le stesse persone e rispondono alla stessa domanda: il sito funziona anche per chi non si trova nelle condizioni ideali? L’HTML semantico riduce il JavaScript e rende i componenti accessibili; il layout stabile evita errori a chi si muove più lentamente o usa un ingranditore; la reattività aiuta chi usa tastiera e lettori di schermo; il movimento ridotto e il testo come testo alleggeriscono le pagine e le rendono più fruibili.
Allo stesso tempo, alcune ottimizzazioni per le prestazioni, se applicate senza attenzione, creano barriere: script ritardati che ignorano la tastiera, facciate senza etichette, stili del focus rimossi. La regola è verificare ogni intervento con entrambe le lenti. Un sito veloce ma inaccessibile, o accessibile ma lento, esclude qualcuno; un sito costruito pensando a entrambe le cose è semplicemente un sito migliore, per tutti.
