Inbyggt kontra anpassat: när du bör välja ett riktigt element

För varje kontroll står ni inför ett val: använd ett nativt HTML-element eller bygg ett eget. Nativt vinner nästan alltid.

En nativ button kan ta fokus och aktiveras med mus, tangentbord och pekskärm, och meddelas korrekt. Ni skriver en tagg och plattformen sköter resten.

Om ni stylar en span så att den ser ut som en knapp har den fortfarande ingen roll, inget fokus och inget tangentbordsstöd. Den lurar bara ögat.

För att ett anpassat kontroll­element ska fungera måste du lägga till en roll, tabindex och tangentbordshanterare för Enter och Space. Det är mycket kod för att efterlikna ett enda element.

Även noggrant byggda anpassade kontroller missar specialfall: fokusramar, inaktiverade tillstånd och pekinmatning. Det inbyggda elementet hanterar redan allt detta.

Detta gäller hela plattformen. Ett äkta select, en kryssruta eller details ger dig beteende och tillgänglighet som en div-kopia aldrig helt kan matcha.

Inbyggda formulärkontroller skickas med form, validerar sig själva och kopplas automatiskt ihop med en label. Att bygga om detta för hand är sällan värt det.

Välj anpassat endast när det inte finns något inbyggt element för mönstret, till exempel ett flikgränssnitt eller ett träd. Följ då noggrant ett beprövat authoring pattern.

Orolig för att en riktig knapp ser enkel ut? Du kan styla inbyggda element kraftigt med CSS. Behåll semantiken och ändra utseendet precis som du vill.

När du väljer det riktiga elementet får du mindre JavaScript, färre buggar och en kontroll som automatiskt klarar uppdateringar av webbläsare och hjälpmedelsteknik.

Gör detta till din standard: inbyggt först, anpassat endast som sista utväg. Webbplattformen är en stor tillgänglighetsgåva, så låt den göra jobbet.

Välj inbyggt först: en riktig knapp eller input ger dig fokus, tangenter och semantik utan extra arbete. Välj anpassat endast när inget element finns, och styla inbyggda element fritt. 🎉