Den dag jeg slettede alle mine divs og opdagede HTML semantik

Den dag jeg slettede alle mine divs og opdagede HTML semantik

Forestil dig, du åbner din første rigtige webside i editoren, og alt du ser er <div> oven på <div>. Den virker, den ligner noget, men du har ingen idé om, hvad noget egentlig er.

Jeg sad der en aften med kaffe og en meget interesseret kat på tastaturet, slettede halvdelen af mine divs og begyndte at erstatte dem med semantiske tags. Det var også den aften, jeg fandt ud af, hvad HTML semantik faktisk gør for dig.

Hvad semantik betyder (og hvad det ikke betyder)

Semantisk HTML handler om, at dit markup beskriver betydningen af indholdet, ikke bare hvordan det ser ud.

Altså: du vælger tags ud fra rollen, ikke layoutet.

Når du bruger <header>, siger du: “det her er en topsektion for noget”. Når du bruger <article>, siger du: “det her kan stå for sig selv som et indlæg”. En <div> siger bare: “en tilfældig kasse, god vind”.

Hvad semantik ikke er:

  • Det handler ikke om CSS. Du kan style alt, også semantiske tags, med CSS.
  • Det er ikke kun for SEO. Søgemaskiner elsker det, ja, men skærmlæsere og fremtid-dig elsker det endnu mere.
  • Det er ikke raketvidenskab. Det er mest sunde spørgsmål som: “hvad er det her for et stykke indhold?”

Den hurtige tommelfingerregel: Hvad er indholdets rolle?

Jeg bruger ofte den her lille mental-model, når jeg sidder midt i html semantik-kaos:

  • Styrer det navigation eller struktur for hele siden? Tænk <header>, <nav>, <main>, <footer>.
  • Er det en selvstændig enhed, der giver mening alene? Tænk <article> (blogindlæg, nyhed, forum-post, produktkort).
  • Samler det indhold, der hører logisk sammen? Tænk <section> (afsnit i en side, temaer, kapitler).
  • Er det bare et layout- eller styling-“hack”? Tænk <div> (grid, flex-containere, wrappers).

Hvis du kan sætte ord på rollen, findes der ofte et semantisk tag, der passer. Hvis du ikke kan, ender du tit fair nok med en <div>.

Et simpelt side-layout med semantiske tags

Lad os tage et typisk layout: en simpel blogforside.

<body>
  <header>
    <h1>Min blog</h1>
    <nav>
      <ul>
        <li><a href="#">Forside</a></li>
        <li><a href="#">Om</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <section aria-labelledby="latest-posts-heading">
      <h2 id="latest-posts-heading">Seneste indlæg</h2>

      <article>
        <header>
          <h3>Den dag jeg lærte flexbox</h3>
          <p>Skrevet af Ida</p>
        </header>
        <p>Jeg troede, jeg forstod layout...</p>
      </article>

      <article>
        <header>
          <h3>Sådan bruger du &lt;main&gt;-tagget rigtigt</h3>
        </header>
        <p>Spoiler: kun én per side.</p>
      </article>
    </section>
  </main>

  <footer>
    <p>© 2026 Min blog</p>
  </footer>
</body>

Det her er et lille html struktur eksempel, men du kan allerede se mønsteret:

  • <header> og <footer> bruges både på sideniveau og inde i <article>.
  • <main> omslutter hovedindholdet, der er unikt for den side.
  • <section> grupperer en logisk blok: “Seneste indlæg”.
  • Hvert <article> kunne i teorien vises alene på en /post-side.

section vs article vs div – det lille beslutningsskema

“Section vs article” er en af de klassiske google-søgninger. Jeg har været der. Flere gange.

Beslutningsskema i tekstform

Stil dig selv de her spørgsmål:

  1. Kan det her stykke indhold deles eller linkes til som noget selvstændigt?
    Hvis ja: <article> er et godt bud.
  2. Er det mere et afsnit/tema på en side, som kun giver mening i konteksten?
    Hvis ja: <section>.
  3. Er det bare en container for layout eller styling uden egen betydning?
    Hvis ja: <div>.

Eksempler

1. Blogindlægsliste

<section aria-labelledby="blog-heading">
  <h2 id="blog-heading">Blogindlæg</h2>

  <article>
    <h3>HTML semantik for begyndere</h3>
    <p>En intro til semantiske tags...</p>
  </article>

  <article>
    <h3>CSS grid på 15 minutter</h3>
    <p>Sådan bygger du layouts...</p>
  </article>
</section>

Her er <section> “Blogindlæg”-blokken, og hvert <article> er et potentielt selvstændigt indlæg.

2. Feature-område på en landing page

<section aria-labelledby="features-heading">
  <h2 id="features-heading">Hvorfor vælge vores app?</h2>

  <div class="features-grid">
    <article>
      <h3>Hurtig opsætning</h3>
      <p>Kom i gang på 5 minutter.</p>
    </article>

    <article>
      <h3>Fungerer på alle enheder</h3>
      <p>Mobil, tablet og desktop.</p>
    </article>
  </div>
</section>

Her bruger jeg en <div> til grid-layoutet. Den har ingen semantisk betydning, den hjælper bare CSS.

3. Hvornår en div er helt fin

<div class="card">
  <h3>Breaking news</h3>
  <p>Serveren er nede.</p>
</div>

Hvis kortet kun er en visuel boks og ikke en logisk “artikel”, er <div> ok. Men hvis den senere bliver til et selvstændigt nyhedsindlæg, ville jeg overveje <article>.

header, nav, main, footer – de klassiske patterns

<header>

<header> er introduktionen til enten siden eller en sektion.

  • Må gerne bruges flere gange per side.
  • Kan ligge inde i <article> og <section>.
  • Kan indeholde logo, titel, metadata, navigationsmenu.

<nav>

<nav> er reserveret til navigation: primær menu, side-menu, footer-menu.

  • Brug det til links, der hjælper dig rundt i sitet eller et større område.
  • Brug <ul> indeni til at strukturere links.

<main>

<main> er der, hvor hovedindholdet bor.

  • Kun ét <main> per side.
  • Må ikke ligge inde i <header>, <footer>, <article> osv.
  • Indeholder det, der er unikt for den aktuelle side.

<footer>

<footer> er afslutningen for enten hele siden eller et område.

  • Må også bruges flere steder (på sideniveau og inde i artikler).
  • Typisk copyright, kontaktinfo, relaterede links.

Hvis du vil nørde videre i samme boldgade, har jeg skrevet om basis-HTML i andre artikler på Coding Class, fx om at bygge strukturen op, før man går CSS-amok.

Overskrifter: H1 – H6 uden kaos

God semantisk html handler også om dine overskrifter.

En rimelig enkel måde at tænke det på:

  • Én <h1> per side, der beskriver sidens hovedemne.
  • <h2> til hovedafsnit.
  • <h3> til underafsnit inde i et h2-afsnit.

Et eksempel fra en fiktiv dokumentationsside:

<main>
  <h1>Kom i gang med API'et</h1>

  <section>
    <h2>Installation</h2>
    <p>Sådan installerer du pakken...</p>
  </section>

  <section>
    <h2>Autentificering</h2>
    <h3>API nøgler</h3>
    <p>Sådan opretter du nøgler...</p>

    <h3>OAuth</h3>
    <p>Hvis du vil bruge OAuth...</p>
  </section>
</main>

En skærmlæser-bruger kan hoppe mellem overskrifterne og få et klart overblik. Det samme kan du selv, når du kommer tilbage til projektet om tre måneder.

Tilgængelighed: landmark-roller og skærmlæsere

Semantiske tags fungerer som “landmarks” for skærmlæsere. Det er lidt som at give siden et sæt usynlige overskrifter og områder.

Skærmlæsere kan f.eks. hoppe direkte til:

  • Main (<main>): hovedindholdet.
  • Banner (<header> øverst): toppen af siden.
  • Navigation (<nav>): menuer.
  • Contentinfo (<footer>): info i bunden.

Det betyder, at en bruger med skærmlæser ikke skal “lytte” sig igennem alt muligt pynt, før de når indholdet.

Når du fx kombinerer gode tags med attributter som aria-label og aria-labelledby, får du ret hurtigt mere tilgængelig HTML uden at skulle bygge alt om. Hvis du er nysgerrig på det, kan du også læse videre om tilgængelighed og HTML på projekter som Coding Class, hvor temaet dukker op i flere artikler.

Mini-tjekliste: 10 ting jeg hurtigt kigger efter

Når jeg lige laver en hurtig sanity-check af min HTML, kører jeg den her i hovedet:

  1. Har siden præcis én <main>?
  2. Giver <header> og <footer> mening de steder, de bruges?
  3. Har jeg kun brugt <nav> til reel navigation?
  4. Har hver større blok indhold en meningsfuld overskrift (<h2> eller <h3>)?
  5. Kunne mine <article>-elementer stå alene og stadig give mening?
  6. Bruger jeg <section> til logiske afsnit, ikke bare styling?
  7. Bruger jeg <div> primært til layout og ikke som universelt standard-tag?
  8. Springer jeg ikke rundt i overskriftsniveauer (fx direkte fra <h1> til <h4>)?
  9. Har billeder, ikoner og lignende korrekt alt-tekst?
  10. Validerer min HTML uden alvorlige fejl, f.eks. i W3C validatoren?

Det lyder meget, men efter et par projekter sidder det ret meget på rygraden. Lidt ligesom første gang du forstod, hvordan et display: flex faktisk påvirker alt andet – og så kunne du ikke lade være med at bruge det.

Næste skridt: byg noget og gør det semantisk fra start

Hvis du vil øve dig i html semantik, så byg noget småt og overskueligt: en lille blogforside, en produktside for et fiktivt spil, eller en simpel dokumentationsside til et lille projekt. Tænk over rollen for hver blok, før du tyr til <div>.

Mit vigtigste råd: begynd at spørge “hvad er det her indhold for noget?” hver gang du skriver et nyt tag, og vælg det mest præcise semantiske element, du kan slippe afsted med.

er til indhold der kan stå alene og eventuelt genbruges (blogindlæg, produktkort, forumpost).
grupperer tematisk indhold i en side og bør som regel have en overskrift for at give mening. Brug
når der kun er tale om layout eller når intet semantisk element passer.
Foretræk altid native semantik før ARIA; moderne elementer som
Nej, de supplerer hinanden: semantiske tags beskriver rolle, mens klasser er til styling og JS-targeting. Du kan godt style tags direkte, men klasser er ofte mere robuste hvis du genbruger komponenter eller ændrer layout.
Brug automatiske værktøjer som Lighthouse eller axe for hurtig feedback, og tjek browserens accessibility tree i devtools. Foretag også manuelle checks med en skærmlæser (NVDA/VoiceOver), gennemse overskriftsrækkefølgen og test keyboard-navigation for at sikre god struktur.

Ida Balslev er den type ven, der pludselig dukker op i din messenger med et link til en lille web-app, hun lige har bygget for sjov – og bagefter gerne viser dig, hvordan du selv kan lave den. Hendes passion for kodning startede med en hjemmebygget hjemmeside til en hestestald og er langsomt vokset gennem aftener med tutorials, fejlmeldinger og små, hjemmelavede projekter.

På Codingclass.dk deler Ida den viden, hun selv manglede i starten: konkrete eksempler, tydelige forklaringer og ærlige historier om, hvad der typisk går galt første, anden og tredje gang. Hun elsker at tage et abstrakt begreb som fx "API" eller "asynkron JavaScript" og koge det ned til noget, du kan se, klikke på og lege med i browseren. For hende handler kodning ikke om at være perfekt, men om at turde prøve, bryde ting og bygge dem op igen.

Ida skriver især om webudvikling med HTML, CSS og JavaScript, små Python-scripts og grundlæggende koncepter som debugging, versionsstyring og struktur i din kode. Hun tænker altid i næste skridt: når du først forstår idéen, viser hun dig, hvordan du kan udvide det med en ekstra funktion, lidt pænere styling eller en smartere måde at tænke din kode på.

Gennem sine artikler på Codingclass.dk vil Ida gerne give dig følelsen af, at du ikke sidder alene med koden – men at der faktisk er en, der har kæmpet med de samme fejlmeddelelser og nu gerne vil vise dig en vej igennem dem, i et tempo hvor alle kan være med.

Send kommentar

You May Have Missed