Semantic HTML

Semantic HTML means choosing elements according to their intended meaning and structural role, rather than their appearance alone. Meaningful markup helps browsers, assistive technologies, search engines, and developers understand page structure.

Semantic elements describe what content represents. For example, use `nav` for navigation, `main` for the primary page content, `article` for a self-contained piece of content, and `button` for an interactive button.

Semantic HTML improves accessibility because assistive technologies can use native element semantics to expose structure and available interactions. A native `button`, for example, already has keyboard and accessibility behavior that a generic `div` does not provide by default.

Semantic markup also gives browsers and developer tools useful structural information without requiring custom attributes or JavaScript. CSS should generally control presentation, while HTML communicates content meaning and document structure.

Semantic HTML is not a guarantee of accessibility. Poor heading order, missing labels, inaccessible custom widgets, inappropriate ARIA, and keyboard traps can still create problems even when semantic elements are present. Prefer native HTML semantics first, then add ARIA when the native platform does not provide the required semantics.

Key points

• Choose HTML elements by meaning, not visual appearance.
• Prefer native interactive elements such as `button` and `a` over clickable generic containers.
• Use headings and landmarks to communicate document structure.
• Semantic HTML can improve accessibility without additional JavaScript.
• Use CSS for presentation and HTML for structure and meaning.
• ARIA supplements native semantics; it should not unnecessarily replace them.

Interview questions

What is Semantic HTML, and why is it important?

Semantic HTML uses elements according to what their content or control represents. Elements such as `header`, `nav`, `main`, `article`, and `button` communicate structure and purpose more clearly than generic containers. Assistive technologies can use these native semantics to help users navigate and interact with a page. It also makes the markup easier for developers and tools to understand.

When would you use `section`, `article`, and `div`?

Use `article` for content that forms a self-contained, independently meaningful unit, such as a post or news item. Use `section` for a thematic grouping of content, typically with a heading that identifies the section. Use `div` when no more specific semantic element accurately describes the grouping. The choice should be based on meaning rather than how the element is styled.

Why should you prefer a native `button` over a clickable `div`?

A native `button` already communicates that the element is an interactive control and provides built-in keyboard and browser behavior. A clickable `div` only becomes interactive through scripting and requires developers to recreate important interaction and accessibility behavior. Using the native control therefore reduces implementation complexity and the chance of accessibility defects. A link should similarly be used when the action navigates to another resource.

How does Semantic HTML relate to accessibility?

Semantic HTML gives browsers and assistive technologies information about the roles and relationships of page content. Landmarks, headings, lists, and native controls can make navigation and interaction more understandable. This reduces the amount of custom accessibility behavior developers need to implement. However, semantic markup does not eliminate the need for accessible names, sensible structure, keyboard support, and testing.

What is the relationship between Semantic HTML and ARIA?

Native HTML should generally be the starting point because its semantics and interaction behavior are built into the platform. ARIA can communicate additional roles, states, and properties when the native HTML vocabulary does not adequately represent a custom interface. Adding ARIA does not automatically supply the keyboard behavior or interaction logic that a custom widget requires. A common engineering principle is to use the simplest native element that correctly expresses the required behavior, adding ARIA only when necessary.