Semantic html means choosing elements for what content is, such as a heading, navigation list or footer, instead of how it looks. The browser, assistive technology and other developers can then understand the page from its markup alone.
It is one of the foundations of front-end web development, and it costs nothing extra: a well-chosen element replaces a generic one without adding weight to the page.
What semantic markup means
The MDN Web Docs glossary starts from the idea of meaning: In programming, Semantics refers to the meaning of a piece of code. In HTML, that means each element should say what role its content plays, not what it should look like by default.
The glossary makes the point with a heading. A span can be styled to look exactly like a top-level heading, yet it has no semantic value. The page looks right, but nothing in the markup tells a browser or a screen reader that the text is a heading. The remedy is spelled out too: It is therefore a good idea to use the right HTML element for the right job.
The split of responsibilities is clear. According to MDN, Presentation (how it should look), is the sole responsibility of CSS. HTML describes the content; CSS decides its appearance. Keeping the two apart makes it possible to restyle a site without rewriting its structure.
Why it matters for people and for maintenance
The first beneficiaries are users of assistive technology. MDN lists among the benefits that Screen readers can use it as a signpost to help visually impaired users navigate a page. A sighted visitor scans colour, size and position to find the navigation or the main story. Someone using a screen reader cannot rely on those cues, so the elements have to carry the structure.
The MDN structuring guide describes how this works in practice: assistive technologies like screen readers can recognize those elements and offer shortcuts to the main navigation or the main content. The second beneficiary is the next developer to open the file. The glossary notes that Finding blocks of meaningful code is significantly easier than searching through endless div s with or without semantic or namespaced classes.
Semantic structure also supports other parts of a build. Clear headings and landmarks give assistive technology something to work with, and tidy markup is easier to keep visually stable, a concern raised when measuring core web vitals. Structure and performance are separate topics, but clean markup helps both.
Page structure: header, nav, main, aside and footer
A typical page has the same handful of regions, and HTML provides a dedicated element for each. The MDN structuring guide maps them like this: header: <header> . navigation bar: <nav> . main content: <main> , with various content subsections represented by <article> , <section> , and <div> elements. sidebar: <aside> ; often placed inside <main> . footer: <footer>.
The main element deserves particular care. MDN defines it as the dominant content of the <body> of a document, and sets a firm limit: A document mustn’t have more than one <main> element that doesn’t have the hidden attribute specified. It also doubles as a target for skip links, because Adding an id attribute to the <main> element lets it be a target of a skip navigation link.
Article and section are easy to confuse. In the MDN example page, an article contains the main piece of content and section elements divide it into subsections, each introduced by its own heading. A generic div is still the right choice when a wrapper is needed purely for styling and has no meaning of its own.
Landmarks: how elements become navigation points
Many of these elements double as landmarks. The W3C’s Web Accessibility Initiative explains the purpose: Screen readers exploit landmark roles to provide keyboard navigation to important sections of a page. A user can jump from region to region instead of listening to the whole page in order.
The table shows how common elements map to landmark roles, with the conditions that apply to header, footer and section.
| HTML element | Landmark role | Condition |
|---|---|---|
| header | banner | When it is in the context of a body element |
| nav | navigation | None |
| main | main | None |
| aside | complementary | None |
| footer | contentinfo | When it is in the context of a body element |
| section | region | Only when it has an accessible name |
Mappings follow the landmark regions guidance from the W3C WAI.
Two practical rules follow. When one landmark type appears more than once, the guidance says to provide each instance of that landmark with a unique label, for example separating a site menu from a footer menu. And labels should not repeat the role: Do not use the landmark role as part of the label, since a navigation labelled “Site Navigation” would be announced as “Site Navigation Navigation”.
Headings and interactive elements
Headings carry the outline of a page. MDN notes that Heading information can be used by user agents to construct a table of contents for a document automatically. The same page gives three rules worth following: Do not use heading elements to resize text. Instead, use the CSS font-size property, Do not skip heading levels: always start from <h1> , followed by <h2> and so on, and Prefer using only one <h1> per page and nest headings without skipping levels. Applied together, these rules give every page a clean outline that tools and readers can follow.
Interactive controls follow the same principle. A clickable div can be made to look like a button, but the real element comes with behaviour built in. MDN describes it as an interactive element activated by a user with a mouse, keyboard, finger, voice command, or other assistive technology. Using the proper element means keyboard and assistive-technology support arrives without extra scripting. Form controls work the same way, and the choice of the right field type is covered in html input types.
A short checklist for semantic markup
A quick review of a template usually catches the common gaps. Is there one main element? Do header, nav and footer wrap the regions they describe? Do headings descend in order without gaps? Are buttons real buttons and links real links? Is any text-sized heading actually a styled paragraph? Does a repeated landmark have a distinguishing label?
Teams can turn the same questions into a shared template review, so that every new page starts from a structure that has already been checked. Answering these questions does not require special tools. Reading the markup with CSS switched off, or listing the headings and landmarks a screen reader would announce, shows quickly whether the structure reads sensibly without the visual design.
Frequently asked questions
Is a div ever the right element?
Yes. MDN’s structure guide lists div among the elements for content subsections, and it remains the neutral container when no other element describes the content. The problem arises when a div is used where a more specific element exists.
Can CSS make a div behave like a heading?
CSS can change how it looks, but not what it means. MDN notes that a styled span has no semantic value, so assistive technology will not treat it as a heading.
How many main elements can a page have?
MDN states that a document mustn’t have more than one main element that doesn’t have the hidden attribute specified, so a single visible main region per page is the rule.
Do semantic elements need ARIA roles as well?
Usually not. MDN advises preferring the native main element over declaring role=”main” unless there are legacy browser support concerns, and the WAI table shows the landmark roles that native elements already imply.
