Semantic HTML Components

Semantic HTML components use meaningful HTML elements that convey structure and purpose to assistive technologies, browsers, and search engines. Building design system components with semantic HTML creates an accessible foundation that requires less ARIA augmentation.

What Are Semantic HTML Components

Semantic HTML refers to using HTML elements according to their intended purpose and meaning rather than solely for their visual presentation. A button element for actions, a link for navigation, a heading for titles, a list for grouped items. These element choices communicate meaning beyond visual styling.

Assistive technologies interpret semantic HTML to provide users with information about content structure and interactive behavior. A screen reader announces a button as “button,” indicating it can be activated. A link announces as “link,” indicating it leads somewhere. This semantic information helps users understand and navigate interfaces.

Design systems that build components from semantic HTML inherit these accessibility benefits. A Button component wrapping a native button element gains keyboard accessibility, proper announcements, and expected interaction patterns without additional code.

How Semantic HTML Components Work

Semantic HTML works by matching element types to content purposes. Common semantic choices include:

• button for clickable actions that do not navigate
• a (anchor) for links that navigate to new locations
• h1-h6 for heading hierarchy
• p for paragraphs
• ul, ol, li for lists
• table, th, td for tabular data
• form, label, input for form interactions
• nav, main, aside, header, footer for page structure

Non-semantic elements like div and span provide no meaning to assistive technologies. They serve as styling containers but should not replace semantic elements. A clickable div lacks the accessibility features of a native button.

Component implementation in design systems should use semantic elements as the foundation. A Card component might use an article element. A Navigation component uses nav. A DataTable uses proper table markup. The component abstraction does not change the underlying semantic structure.

When semantic HTML alone cannot express the needed information, ARIA attributes supplement. But ARIA should augment semantic HTML, not replace it. The first rule of ARIA states: do not use ARIA if a native HTML element or attribute provides the needed semantics.

Key Considerations

• Use button elements for actions, not clickable divs or spans
• Use anchor elements for navigation links
• Apply proper heading hierarchy without skipping levels
• Use list elements for grouped items, not styled paragraphs
• Use table elements for tabular data, not divs with grid layout
• Ensure form inputs have associated label elements
• Reserve div and span for styling containers without semantic meaning

Common Questions

When should custom elements use ARIA instead of semantic HTML?

ARIA becomes necessary when no native element provides the needed semantics or when creating custom widgets not representable with native controls. A custom combobox, tabs interface, or tree view requires ARIA to communicate structure and state that HTML alone cannot express.

However, even custom widgets benefit from semantic foundations. A custom dropdown might use a button to trigger it and a list for options, with ARIA attributes added for widget-specific behavior. The semantic base provides keyboard accessibility and basic announcements that ARIA then enhances.

How do semantic components handle styling requirements?

Visual design requirements do not justify abandoning semantic HTML. CSS can style any element to match design specifications. A button can look like a link. A list can display without bullets. Semantic meaning and visual presentation are independent concerns.

Design systems should style semantic elements to match visual requirements while preserving their semantic meaning. The Button component renders a styled button element. The List component renders a styled ul. Implementation uses CSS to achieve visual goals without sacrificing semantics.

What are common semantic HTML mistakes in components?

Common mistakes include using divs with click handlers instead of buttons, using spans with onclick instead of links, building tables from divs with CSS grid, creating fake headings with styled paragraphs, and nesting interactive elements improperly.

These patterns create accessibility barriers. Click handlers on divs lack keyboard support. Fake tables lack screen reader navigation. Styled paragraphs do not appear in heading navigation. Design systems should enforce semantic HTML through component APIs that make the correct choice easy.

Summary

Semantic HTML components use meaningful elements that convey structure and purpose to assistive technologies. By building design system components on semantic foundations, teams inherit accessibility benefits while creating components that properly communicate their nature and behavior to all users.