Når en div prøver at være en knap

De fleste udviklere har været der. Du bygger en komponentbibliotek, og designet kræver en knap. Ikke bare en hvilken som helst knap — en speciel knap. Den skal have custom styling, en unik hover-effekt, måske en gradient der skifter når man trykker. Så du tager en <div>, smider noget CSS på, og kalder det færdigt.

I Figma ser det perfekt ud. Det virker i din demo. Men så prøver en rigtig bruger at navigere med Tab, sender en formular med tastaturet, eller bruger en skærmlæser — og så falder det hele fra hinanden.

Problemet er ikke din CSS. Problemet er at du bad en <div> om at udføre et arbejde den aldrig var designet til.

Den div der ville være en knap

Her er hvad der typisk sker: du har brug for en knap der ser ud på en bestemt måde. Du opretter en <div>, tilføjer class="btn", og styler den til den matcher designet. Det ser godt ud. Men nu har du brug for at den opfører sig som en knap.

Så tilføjer du en click handler. Så en hover state. Så en focus ring for tastatur-brugere. Så opdager du at Space og Enter ikke virker, så du tilføjer keydown listeners. Knappen skal nogle gange være deaktiveret, så du tilføjer en .disabled klasse der forhåbentlig blokerer alle de rigtige interaktioner. Et sted i det hele tilføjer du role="button" og tabindex="0" for at sikre at tilgængelighedsværktøjer ikke fuldstændig ignorerer din skabelse.

Tillykke. Du har bygget et knap-formet objekt der kræver omkring 200 linjer JavaScript for at efterligne det som browseren ville have givet dig gratis.

Det er det vi mener når vi snakker om at "betale renter" på dårlige arkitektoniske beslutninger. Hver linje workaround-kode er renter på det oprindelige valg om at bruge det forkerte element.

Den usynlige kontrakt

Det der er with native HTML elements: de kommer med en hel interaktionskontrakt som de fleste udviklere aldrig tænker over før den mangler.

Når du bruger en rigtig <button>, får du:

• Automatisk tastatur-håndtering — Enter og Space virker præcis som brugere forventer
• Korrekt focus-håndtering — Den indgår naturligt i tab-rækkefølgen, kan fokuseres programmatisk
• Deaktiveret state — Blokerer al interaktion, kan ikke fokuseres, bliver announceret som deaktiveret
• Form-deltagelse — Sender formularer, respekterer validering, deltager i form.reset()
• Tilgængeligheds-semantik — Skærmlæsere fortæller det er en knap uden ekstra ARIA
• Platform-konventioner — Brugere ved allerede hvordan knapper opfører sig fordi knapper opfører sig konsistent overalt

Med en <div> forklædt som en knap, får du... CSS'en. Alt andet er op til dig at implementere. Og her er den hemmelighed: uanset hvor grundig du er, vil din implementering være dårligere end det browsere leverer. Browsere har teams af ingeniører der optimerer disse adfærdsmønstre på tværs af platforme, edge cases og assistive technologies. Din custom knap har kun dig.

Det rigtige spørgsmål er ikke "kan jeg style det?"

Dette er hvor design-engineering samarbejde enten skinner eller skaber technical debt. Udviklere tolker ofte "semantisk HTML" som "at acceptere browserens grimme defaults." Det er slet ikke det vi snakker om.

Spørgsmålet er ikke "kan jeg få det til at se custom ud?" Det kan det absolut. Spørgsmålet er: "hvilke native adfærdsmønstre bør overleve stylingen?"

En <button> kan have enhver visuel behandling du ønsker. Du kan fjerne al default styling med appearance: none. Du kan tilføje gradients, shadows, animationer, custom fonts — hvad som helst designet kræver. Browserens interaktionskontrakt er ligeglad med hvordan din knap ser ud.

Det du ikke let kan gøre med en <div> er at replikere det browseren giver dig automatisk. Så vælg dine kampe: brug din engineering-indsats på det der gør dit produkt unikt, ikke på at genopfinde knapper.

Byg til det rigtige web

Dine brugere bruger ikke dit produkt i et vakuum. De navigerer mellem felter mens hænderne er på tastaturet. De bruger stemmekontrol til at navigere. De forstørrer skærmen til 300% fordi det virker for dem. De har forskellige browsere, forskellige styresystemer, forskellige assistive technologies.

Web-platformen giver dig et kæmpe forspring med semantisk HTML. Native elements er tilgængelige per default, tastatur-navigerbare per default, cross-platform per default. Når du kæmper mod den infrastruktur, skaber du ikke bare mere arbejde for dig selv — du skaber komponenter der vil fejle på subtile måder for rigtige brugere.

Næste gang du er ved at gribe fat i en <div> med role="button", så spørg dig selv: bygger jeg noget der rent faktisk har brug for en custom implementering, eller er jeg bare bange for <button>-tagget? Fordi den kedelige løsning er som regel den rigtige. Og "browseren håndterer det korrekt" er en feature, ikke en begrænsning.

Det semantiske web handler ikke om at følge regler. Det handler om at bruge de værktøjer der er bygget til opgaven — og bruge din energi der hvor det faktisk gør en forskel.