La connessione internet di un visitatore si interrompe mentre carica il tuo modulo. Un'estensione di Chrome manda in tilt il tuo JavaScript. Un browser datato non supporta il JavaScript che stai usando. Il suo screen reader non riesce a muoversi nel tuo modulo perché le etichette sono nascoste con il CSS.
I moduli sono percorsi critici. Gli utenti devono poterli inviare. Il modulo non può semplicemente rompersi. Il progressive enhancement è il principio di creare moduli che funzionano ovunque e di aggiungere poi miglioramenti per i browser in grado di gestirli.
Questo articolo spiega come creare moduli che degradano in modo graduale, funzionano senza JavaScript e restano accessibili a tutti.
Che cos'è il progressive enhancement?
Progressive enhancement significa partire da un modulo di base che funziona nei browser più vecchi e senza JavaScript, e poi sovrapporre i miglioramenti per i browser moderni. Il livello 1 (HTML) offre un modulo di base con campi, etichette e un pulsante di invio che non richiede JavaScript e funziona ovunque. Il livello 2 (CSS) dà stile al modulo con colori, spaziature e layout, quindi il modulo funziona anche se il CSS non si carica, solo che ha un brutto aspetto. Il livello 3 (JavaScript) aggiunge convalida in tempo reale, animazioni fluide e invio con AJAX, quindi il modulo funziona anche se il JavaScript fallisce e si invia in modo tradizionale. Se un livello fallisce, l'utente ha comunque un modulo funzionante. Questa è resilienza.
La base: HTML che funziona
Parti da un HTML semantico con etichette, fieldset ed elementi legend usati correttamente. Un modulo di base si presenta così: <form action="/submit" method="POST"> <label for="email">Email</label> <input type="email" id="email" name="email" required> <label for="message">Message</label> <textarea id="message" name="message" required></textarea> <button type="submit">Send</button> </form>. Questo modulo funziona senza JavaScript, senza CSS, nei browser vecchi, con gli screen reader e con la navigazione da tastiera. Questa è la tua base. Non togliere mai elementi dal DOM per sostituirli con elementi generati da JavaScript, perché se il JavaScript fallisce il modulo si rompe. Mantieni l'HTML semantico.
Degradazione graduale con il CSS
Sovrapponi i miglioramenti CSS all'HTML. Dai al modulo un bello stile. Ma se il CSS fallisce, il modulo deve funzionare lo stesso.
Non nascondere le etichette con il CSS affidandoti ai segnaposto, perché a volte il CSS non si carica e gli screen reader hanno bisogno delle etichette nell'HTML. Non usare il CSS per nascondere gli indicatori dei campi obbligatori, perché se la tua "stellina" personalizzata non si carica gli utenti non capiscono quali campi sono obbligatori. Usa invece l'attributo HTML required. Evita di nascondere l'etichetta alla vista e mostrare un segnaposto al suo posto con label { display: none; } e input::placeholder { content: 'Email'; }. Tieni invece l'etichetta nell'HTML e dalle lo stile che vuoi con label { font-weight: bold; color: #333; }.
Miglioramenti JavaScript che degradano bene
Aggiungi miglioramenti JavaScript, ma solo se il modulo funziona già. Usa il rilevamento delle funzionalità per verificare se il browser supporta ciò che ti serve con if (window._blocked_) { // Use _blocked_ for AJAX submission } else { // Form submits traditionally }. Non dare per scontato che le funzionalità esistano. Parti dal presupposto che potrebbero mancare. Rileva prima.
Convalida in tempo reale con alternativa
Usa la convalida HTML come base con <input type="email" required>, così il browser convalida all'invio. Poi aggiungi una convalida JavaScript che gira in tempo reale con input.addEventListener('blur', () => { if (!isValid(input.value)) { input.classList.add('invalid'); showError(input, 'Invalid email'); } });. Mostra gli errori mentre l'utente scrive e, se il JavaScript fallisce, la convalida integrata nel browser funziona comunque. L'utente ha il vantaggio del riscontro in tempo reale e, se il JavaScript fallisce, riceve il riscontro del browser all'invio. In ogni caso, la convalida avviene.
Invio con AJAX e alternativa tradizionale
Crea un modulo tradizionale che invia i dati lato server, poi intercetta l'invio e usa AJAX con form.addEventListener('submit', async (e) => { e.preventDefault(); const response = await _blocked_('/submit', { method: 'POST', body: new FormData(form) }); if (response.ok) { showMessage('Success'); } });. Se il JavaScript fallisce, preventDefault non viene mai eseguito, il modulo si invia nel modo tradizionale e l'utente vede un ricaricamento della pagina invece di un'esperienza fluida. Ma il modulo funziona.
L'accessibilità come progressive enhancement
L'accessibilità non è una funzione in più. È la base. Crea moduli accessibili.
Le etichette devono essere collegate ai campi con gli attributi for e id. Non con data-attribute, non con aria-label che possono sfuggire. Etichette vere.
<label for="email">Email</label>
<input id="email">
Usa elementi HTML semantici (fieldset, legend, button, input). Non div con lo stile di un pulsante.
La navigazione da tastiera deve funzionare. Tab per scorrere tutti i campi. Maiusc+Tab per tornare indietro. Invio per inviare. Spazio per selezionare le caselle. Con l'HTML semantico funziona già di default. Non rovinarla con il JavaScript.
Quando le basi funzionano, aggiungi le etichette ARIA per gli screen reader. Aggiungi indicatori di focus per chi usa la tastiera. Ma sono miglioramenti sopra un HTML già accessibile.
Provare la resilienza
Prova il modulo con JavaScript disattivato. Disattiva JavaScript nel browser e prova a inviare. Se il modulo si rompe, non è resiliente.
Prova con reti lente. Limita la connessione a 2G. Se il modulo ci mette un'eternità a caricarsi, i visitatori con una connessione instabile se ne andranno.
Prova con browser datati. Usa un servizio di test su browser diversi per provare un browser molto vecchio (se ti serve ancora). Guarda quali funzionalità non sono supportate.
Prova con gli screen reader. Usa lo screen reader di Windows o quello del Mac. Ascolta come viene letto il modulo. Se per uno screen reader non ha senso, correggilo.
Prova usando solo la tastiera. Non usare il mouse. Riesci a muoverti nel modulo? Riesci a inviarlo?
Rilevamento delle funzionalità, non del browser
Non controllare browser specifici. Controlla le funzionalità, invece di usare il rilevamento del browser come if (navigator.userAgent.includes('Chrome')) { /* use _blocked_ */ }. Usa invece il rilevamento delle funzionalità come if (window._blocked_) { /* use _blocked_ */ }. Il rilevamento delle funzionalità è più affidabile, perché un aggiornamento del browser che aggiunge il supporto a _blocked_ funzionerà con il tuo codice, mentre il rilevamento del browser no.
Come WEMASY crea moduli resilienti
I moduli WEMASY sono costruiti sui principi del progressive enhancement: funzionano senza JavaScript, hanno etichette e HTML semantico al loro posto e hanno miglioramenti JavaScript facoltativi, così i browser più vecchi ricevono un modulo funzionante e quelli moderni interazioni fluide.
Scopri le funzioni di resilienza nel tuo piano WEMASY.