De ce <button> înseamnă mai puțină muncă

Toți dezvoltatorii ajung în același punct. Lucrezi la un design care trebuie implementat perfect. Totul arată impecabil în Figma. Primești aprobat, integrezi codul, și... vine feedback de la utilizatori reali.

Ceva nu funcționează. Cineva navighează cu tastatura și nu poate activa butonul. Altcineva folosește un screen reader și componentă nu e anunțată corect. Formularul nu se trimite când apeși Enter.

Cauza? Probabil un <div> deghizat în buton.

Când un div devine prea ambițios

Partea amuzantă e că totul începe inocent. Ai nevoie de un buton cu un look specific. Faci un <div>, îi pui o clasă, adaugi CSS. Arată perfect.

Dar apoi intervine realitatea. Trebuie să funcționeze efectiv. Așa că adaugi un event listener pentru click. Apoi hover state. Apoi un focus ring pentru navigarea cu tastatura. Apoi realizezi că Enter și Space nu merg, deci mai pui niște keydown handlers. Și disabled state, bineînțeles. Și role="button" cu tabindex="0" ca să nu fie complet ignorat de cititoarele de ecran.

Rezultatul? Un obiect care seamănă cu un buton și necesită 200+ linii de JavaScript ca să se apropie de ce-ți dădea browserul gratis de la început.

Asta e ceea ce numesc "dobânda" pentru decizii arhitecturale proaste. Fiecare linie de workaround e o rată pe creditul pe care l-ai luat când ai ales elementul greșit.

Contractul pe care îl ignori

Ceea ce mulți dezvoltatori nu realizează e că elementele native HTML vin cu un pachet complet de interacțiune. Când folosești un <button> adevărat, primești fără să faci nimic:

• Tastatura funcționează — Enter și Space merg exact cum se așteaptă utilizatorii
• Focus management — Elementul intră natural în ordinea de tab, poate fi focusat programmatic
• Starea disabled — Blochează toate interacțiunile, devine unfocusable, e anunțat corect
• Participare în formulare — Submit, validare, reset — totul out of the box
• Semantică pentru accesibilitate — Screen readerele știu că e buton fără ARIA extra
• Convenții de platformă — Utilizatorii știu cum se comportă butoanele pentru că butoanele se comportă consistent

Cu un <div> costumat în buton, primești... CSS-ul. Restul trebuie să-l implementezi tu. Și secretul neplăcut e că, oricât de atent ai fi, implementarea ta va fi mai slabă decât ce oferă browserele. Există echipe întregi de ingineri care optimizează aceste comportamente pentru diferite platforme, edge cases și tehnologii asistive. Tu ai doar tine.

Stilizarea nu e problema

Aici colaborarea dintre design și engineering își arată adevărata față. Mulți dezvoltatori înțeleg "HTML semantic" greșit — ca pe o aprobare a default-urilor urâte din browser.

Întrebarea nu e "pot să-l stilizez?" Poți, absolut. Poți să ștergi orice styling implicit cu appearance: none. Poți pune gradiente, umbre, animații, fonturi custom. Browserul nu-i pasă cum arată butonul tău.

Întrebarea e: "care comportamente native ar trebui să supraviețuiască stilizării?"

Ceea ce nu poți replica ușor cu un <div> e ce-ți oferă browserul automat. Deci alege-ți bătăliile: investește efortul de engineering în ce face produsul tău unic, nu în reinventarea roții.

Pentru web-ul real, nu pentru demo-uri

Utilizatorii tăi nu folosesc produsul în condiții ideale. Navighează cu tastatura între câmpuri. Folosesc control vocal. Măresc ecranul la 300% pentru că așa le e mai ușor. Au diferite browsere, diferite sisteme de operare, diferite tehnologii asistive.

Platforma web îți dă un avans enorm prin HTML semantic. Elementele native sunt accesibile din start, navigabile cu tastatura din start, funcționează cross-platform din start. Când lupți împotriva acestei infrastructuri, nu doar că-ți creezi mai multă muncă — creezi componente care vor eșua în moduri subtile pentru utilizatori reali.

Data viitoare când ești pe punctul de a pune mâna pe un <div> cu role="button", întreabă-te: construiesc ceva care chiar necesită o implementare custom, sau doar îmi e teamă de tag-ul <button>?

Pentru că soluția boring e de obicei cea corectă. Și "browserul îl gestionează corect" nu e o limitare — e o funcționalitate.

Web-ul semantic nu înseamnă să urmezi reguli. Înseamnă să folosești uneltele făcute pentru treaba respectivă — și să-ți folosești energia acolo unde contează cu adevărat.