Introduzione
Quando si parla di compatibilità cross-browser e progressive enhancement, l’obiettivo non è far funzionare un sito solo nel browser “perfetto”, ma garantire un’esperienza solida anche quando alcune funzionalità moderne non sono disponibili. Un sotto-argomento molto pratico, spesso sottovalutato, è l’uso degli elementi <details> e <summary> per creare sezioni espandibili accessibili e progressive.
Questi elementi sono utilissimi per FAQ, note tecniche, filtri, spiegazioni opzionali e blocchi di contenuto secondario. Il vantaggio è che, nei browser moderni, funzionano nativamente senza JavaScript. Nei browser meno recenti, però, il comportamento può cambiare oppure mancare del tutto. Per questo è un ottimo caso di studio: ci permette di vedere come progettare un componente che parte bene da solo e resta usabile anche in scenari meno favorevoli.
In questo tutorial vedremo come costruire una sezione FAQ con dettagli espandibili, come renderla robusta dal punto di vista semantico e come impostare un approccio progressivo che non rompa l’esperienza se il supporto del browser è parziale.
Codice completo
<section aria-labelledby="faq-titolo">
<h2 id="faq-titolo">Domande frequenti</h2>
<details class="faq-item" open>
<summary>Il sito funziona senza JavaScript?</summary>
<p>
Sì. Le parti essenziali del contenuto sono sempre visibili e leggibili.
JavaScript può migliorare l’esperienza, ma non è necessario per accedere
alle informazioni principali.
</p>
</details>
<details class="faq-item">
<summary>Cosa succede nei browser meno recenti?</summary>
<p>
Se il browser supporta <details>, l’utente potrà espandere e comprimere
le risposte. Se il supporto è incompleto, il contenuto resta comunque presente
nel DOM e quindi accessibile.
</p>
</details>
<details class="faq-item">
<summary>Posso usare questo pattern per contenuti lunghi?</summary>
<p>
Sì, soprattutto quando vuoi nascondere informazioni secondarie senza
eliminarle dalla pagina. È utile per note tecniche, istruzioni e spiegazioni
opzionali.
</p>
</details>
</section>Spiegazione
Il componente si basa su una logica semplice: il contenuto importante deve essere disponibile sempre, mentre il browser decide come gestire l’interazione. Questo è esattamente lo spirito del progressive enhancement: prima il contenuto, poi il comportamento, infine gli eventuali miglioramenti visivi o interattivi.
Perché <details> è interessante per la compatibilità
<details> è un elemento nativo che crea un contenitore richiudibile. Al suo interno, <summary> rappresenta il titolo cliccabile. Nei browser moderni, l’apertura e la chiusura avvengono senza script. Questo è vantaggioso perché riduce dipendenze, bug e problemi di manutenzione.
Dal punto di vista della compatibilità, l’aspetto più importante è che il contenuto interno non viene perso: anche se il comportamento interattivo non è identico ovunque, il testo rimane nel markup e quindi è leggibile dai motori di ricerca, dagli screen reader e dagli utenti che navigano in condizioni limitate.
Perché questo approccio è progressivo
Un design progressivo non assume che tutte le funzionalità siano disponibili. Nel nostro esempio:
- la pagina contiene già le risposte complete;
- il browser moderno aggiunge l’interazione nativa;
- eventuali miglioramenti estetici possono essere aggiunti dopo, senza cambiare la struttura base;
- se il supporto è parziale, il contenuto resta comunque consultabile.
Dettagli importanti nel codice
Nel frammento sopra abbiamo usato open sul primo elemento <details>. Questa scelta è utile quando vuoi mostrare subito un’informazione chiave o dare un punto di partenza visibile all’utente. È anche una buona strategia per evitare una pagina troppo “vuota” al primo impatto.
Abbiamo inoltre inserito la sezione dentro un <section> con un’intestazione collegata tramite aria-labelledby. Questo migliora la struttura semantica del documento e aiuta la navigazione assistita, senza introdurre complessità inutili.
Compatibilità reale: cosa aspettarsi
Nella pratica, i browser moderni supportano bene <details> e <summary>. Tuttavia, quando progetti per ambienti eterogenei, devi pensare a questi casi:
- browser vecchi che non gestiscono correttamente l’espansione;
- stili predefiniti diversi tra motori di rendering;
- comportamenti non uniformi nella gestione del focus o dell’indicatore visivo;
- dispositivi e modalità di lettura che privilegiano il contenuto testuale rispetto all’interazione.
Per questo il markup deve essere scritto in modo che il contenuto sia utile anche senza “effetti speciali”.
Best practice
- Metti sempre il contenuto importante nel DOM: non nasconderlo solo via JavaScript o CSS se è essenziale.
- Usa <summary> descrittivi: il testo deve far capire subito cosa si aprirà. Evita etichette vaghe come “Apri qui”.
- Non dipendere solo dal comportamento nativo: se il contenuto è critico, assicurati che resti comprensibile anche quando il componente non è interattivo.
- Testa in più browser: verifica sia il rendering sia l’usabilità con tastiera e lettori di schermo.
- Evita nesting troppo complesso: annidare troppi livelli di dettagli può confondere gli utenti e rendere più difficile la navigazione.
- Usa l’attributo open con criterio: utile per evidenziare la prima risposta o una sezione introduttiva, ma non abusarne.
- Non trasformare <details> in un sostituto generico di tutto: è perfetto per contenuti secondari e opzionali, meno adatto a flussi critici come form o checkout.
Riepilogo
Il pattern con <details> e <summary> è un ottimo esempio di compatibilità cross-browser applicata al progressive enhancement. Ti permette di creare contenuti espandibili senza dipendere da JavaScript, mantenendo il contenuto accessibile e leggibile anche in scenari meno moderni.
Il principio chiave è semplice: prima il contenuto, poi l’interazione. Se il browser supporta il componente, l’utente ottiene un’esperienza migliore. Se non lo supporta perfettamente, la pagina continua comunque a funzionare in modo sensato.
Questo approccio è particolarmente utile per FAQ, note tecniche, sezioni di aiuto e contenuti opzionali. È una scelta concreta, semplice da mantenere e molto efficace per costruire interfacce resilienti.
Approfondisci con risorse ufficiali
- MDN Web Docs - <details>: documentazione completa sull’elemento e sul suo comportamento.
- MDN Web Docs - <summary>: dettagli su uso, accessibilità e supporto browser.
- WHATWG HTML Living Standard: specifica ufficiale del linguaggio HTML e degli elementi interattivi.
- Web.dev: articoli pratici su progressive enhancement, accessibilità e robustezza delle interfacce.
- Can I use: utile per verificare rapidamente il supporto cross-browser di <details> e di altri elementi HTML.