Il Div Che Voleva Essere un Button

Chi scrive codice lo sa bene. Stai costruendo una libreria di componenti e il design richiede un bottone. Non un bottone qualunque—un bottone speciale. Servono stilizzazioni particolari, un effetto hover unico, magari un gradiente che cambia alla pressione.

Allora prendi un <div>, aggiungi del CSS, e fine della storia.

In Figma è perfetto. Nel tuo demo funziona. Poi un utente reale prova a navigare con Tab, invia un form con la tastiera, o usa un screen reader—e tutto salta fuori.

Il problema non è il CSS. Il problema è che hai chiesto a un <div> di fare un lavoro per cui non è stato pensato.

Perché Accade Questo

La storia è sempre la stessa. Ti serve un bottone con un certo aspetto. Crei un <div>, aggiungi class="btn", e continui a stylare finché non matcha il design. Perfetto. Ma ora serve che faccia anche il lavoro di un bottone.

Allora aggiungi un click handler. Poi uno stato hover. Poi un focus ring per chi usa la tastiera. Ti rendi conto che Space e Enter non funzionano, quindi aggiungi listener per keydown. Il bottone deve essere disabilitato a volte, quindi aggiungi una classe .disabled che speriamo blocchi tutte le interazioni giuste. Da qualche parte in mezzo, aggiungi role="button" e tabindex="0" per non far ignorare completamente la tua creazione dagli strumenti di accessibilità.

Congratulazioni. Hai costruito un oggetto a forma di bottone che richiede circa 200 righe di JavaScript per avvicinarsi a quello che il browser ti avrebbe dato gratis.

Questo è il "costo" delle decisioni architetturali sbagliate. Ogni riga di workaround è interesse sul prestito della scelta iniziale di usare l'elemento sbagliato.

Il Contratto Invisibile

C'è una cosa che molti sviluppatori non considerano: gli elementi HTML nativi arrivano con un intero pacchetto di funzionalità per l'interazione.

Quando usi un vero <button>, ottieni:

• Gestione automatica della tastiera — Enter e Space funzionano esattamente come gli utenti si aspettano
• Gestione corretta del focus — Entra naturalmente nel tab order, può ricevere focus programmaticamente
• Comportamento del disabled — Blocca tutte le interazioni, non è più focusabile, viene annunciato come disabilitato
• Partecipazione ai form — Invia i form, rispetta la validazione, partecipa a form.reset()
• Semantica per l'accessibilità — Gli screen reader lo annunciano come bottone senza bisogno di ARIA aggiuntivo
• Convenzioni della piattaforma — Gli utenti sanno già come si comportano i bottoni perché i bottoni si comportano allo stesso modo ovunque

Con un <div> travestito da bottone, ottieni... il CSS. Tutto il resto lo implementi tu. E qui sta il segreto: per quanto tu sia accurato, la tua implementazione sarà peggiore di quello che i browser forniscono. I browser hanno team di ingegneri che ottimizzano questi comportamenti su piattaforme diverse, casi limite, e tecnologie assistive. Il tuo bottone custom ha solo te.

La Vera Domanda Non È "Posso Stilizzarlo?"

È qui che la collaborazione tra design e engineering brilla o crea debito tecnico. Spesso gli sviluppatori interpretano "HTML semantico" come "accettare le brutte default del browser". Non è questo il punto.

La domanda non è "posso farlo sembrare personalizzato?" Assolutamente sì. La domanda è: "quali comportamenti nativi dovrebbero sopravvivere allo styling?"

Un <button> può avere qualsiasi trattamento visivo. Puoi rimuovere tutto lo stile default con appearance: none. Puoi aggiungere gradienti, ombre, animazioni, font custom—quello che il design richiede. Il contratto di interazione del browser non si interessa di come appare il tuo bottone.

Quello che non puoi fare facilmente con un <div> è replicare quello che il browser ti dà automaticamente. Quindi scegli le battaglie: spendi il tuo esfuerzo di engineering su quello che rende unico il tuo prodotto, non sul reinventare bottoni.

Costruire per il Web Reale

I tuoi utenti non usano il tuo prodotto nel vuoto. Navigano tra i campi con le mani sulla tastiera. Usano il controllo vocale. Ingrandiscono lo schermo al 300% perché così gli è più comodo. Hanno browser diversi, sistemi operativi diversi, tecnologie assistive diverse.

La piattaforma web ti dà un vantaggio enorme con l'HTML semantico. Gli elementi nativi sono accessibili di default, navigabili con tastiera di default, cross-platform di default. Quando combatti contro questa infrastruttura, non stai solo creando più lavoro per te stesso—stai creando componenti che falliranno in modi sottili per utenti reali.

La prossima volta che stai per prendere un <div> con role="button", chiediti: sto costruendo qualcosa che ha davvero bisogno di un'implementazione custom, o sto solo evitando il tag <button>? Perché la soluzione noiosa è di solito quella giusta. E "il browser lo gestisce correttamente" è una feature, non una limitazione.

Il web semantico non riguarda seguire regole. Riguarda usare gli strumenti costruiti per il lavoro—e spendere energia dove fa davvero la differenza.