Semantic HTML

Definition

Semantic HTML means choosing elements for their defined purpose. A real button communicates and provides button behavior; a styled generic container does not automatically gain that contract.

Practical test

Remove the stylesheet and inspect the document order, headings, lists, links, controls, and landmarks. The content and available actions should still make sense.

Native contracts

Semantic elements communicate roles and relationships that browsers already understand. A heading contributes to document navigation. A list exposes a group and item count. A labeled form control connects its purpose to its value. An anchor with href behaves like a link without recreating link behavior in JavaScript.

These contracts support keyboard input, assistive technology, reader modes, search systems, translation, and future CSS changes. They also reduce custom code: the browser can supply behavior that would otherwise need to be designed, implemented, and maintained.

Semantics are contextual

An element is semantic only when its defined meaning fits the content. Wrapping every block in section does not improve a document. A nav is for important navigation groups, not every cluster of links. An article should make sense as a self-contained composition.

The same visual design can require different markup in different contexts. A card may be an article, a list item, or a generic container depending on what it represents and how it relates to surrounding content.

Relationship to accessibility and SEO

Good semantics make structure and controls easier for assistive technology to interpret, but semantic HTML alone does not establish accessibility. The page still needs useful text, correct names, visible focus, sufficient contrast, responsive reflow, error recovery, and real user testing.

Likewise, meaningful markup helps retrieval systems understand content, but an element name is not a ranking trick. Original, accurate, complete information and crawlable internal links remain necessary.

Common failures

• Choosing headings by font size instead of hierarchy.
• Using clickable generic containers instead of anchors or buttons.
• Applying application menu roles to ordinary site navigation.
• Adding ARIA that conflicts with a native element’s role or state.
• Using semantic-sounding wrappers without headings or a real document purpose.

Review checklist

Read the HTML in source order, navigate it with only a keyboard, and inspect the accessibility tree. Confirm that headings outline the content, landmarks are few and distinguishable, links have destinations, buttons control actions, and forms preserve label relationships. Then test with CSS and JavaScript disabled to see which meaning survives presentation and enhancement failures.