Semantic structure

Semantic structure is the organization of a web page with HTML elements that describe what each piece of content is, not merely how it looks: headings that form an outline, landmarks that mark regions, lists, tables, buttons and links that carry their real roles. In web accessibility, it is the foundation on which screen readers, voice control software and other assistive technologies build their understanding of a page.

Browsers convert the DOM into an accessibility tree, a parallel representation that exposes each element’s role, name, state and relationships to platform accessibility APIs. Semantic markup fills that tree with accurate information automatically. Generic markup, such as a page built from nested div and span elements, leaves it nearly empty, and no amount of visual polish can compensate.

How semantic structure reaches assistive technology

Each native HTML element has an implicit ARIA role. A button element is exposed as a button, an h2 as a heading of level 2, a nav as a navigation landmark and a ul as a list with a known number of items. Assistive technology reads these roles from the accessibility tree and offers users matching commands, such as jumping to the next heading or listing all links.

Native elements also bring built-in behavior. A real button is focusable, responds to Enter and Space and announces its pressed or disabled state. A div styled to look like a button provides none of this until a developer adds a role, a tabindex and keyboard handlers by hand, which is why the first rule of ARIA is to prefer a native element whenever one exists.

The table shows which properties of the accessibility tree semantic markup supplies.

The building blocks of a semantic page

A well-structured page combines three layers of semantics: landmarks that divide the page into regions, a heading hierarchy that outlines the content and element-level semantics for lists, tables, forms and controls. Screen reader users commonly navigate by headings first, so the heading outline is often the single most important layer.

The following table maps the main HTML landmark elements to the regions they define.

Headings should descend logically: one `h1` describing the page, then h2 for major sections and h3 for subsections, without skipping levels for visual size. Font size belongs in CSS; the heading level must reflect the position in the outline.

Semantic structure and WCAG requirements

The Web Content Accessibility Guidelines address semantic structure most directly in success criterion 1.3.1 Info and Relationships at Level A, which requires that structure conveyed visually also be available programmatically. Several other criteria depend on it, so a structural failure usually causes multiple WCAG failures at once.

Semantic structure complements neighboring techniques in web accessibility. A skip link relies on a correctly placed main region, focus management needs real focusable controls, and accessible forms depend on labels programmatically tied to their fields.

Building and testing semantic structure

The most efficient approach is to write semantic HTML first and add ARIA only to fill genuine gaps, such as tabs, disclosure widgets or live regions, for which no native element exists. Component libraries should encode these decisions once, so every team inherits correct roles instead of rebuilding them.

• Read the outline: list all headings with a browser extension or DevTools and check that they form a logical table of contents.
• Inspect the accessibility tree in browser DevTools to confirm roles, names and states for custom components.
• Navigate with a screen reader such as NVDA, JAWS or VoiceOver using heading, landmark and form-control shortcuts.
• Run automated checkers to catch missing labels, empty headings and invalid ARIA, remembering they detect only a minority of real issues.
• Disable CSS briefly to verify that the raw document order still makes sense.

Common semantic structure mistakes

Most structural defects come from choosing elements for their default appearance rather than their meaning, or from frameworks that render generic containers by default. The table lists frequent problems and their corrections.

A frequent misconception holds that ARIA makes elements accessible on its own. ARIA changes only what is announced; it adds no keyboard support or behavior, so incorrect ARIA is often worse than no ARIA at all.

Put simply

Imagine a book with no chapter titles and no table of contents. The whole text runs on as one long stream. A sighted reader might guess where sections begin. Someone listening to it read aloud would soon be lost.

Semantic structure is the table of contents and the labels of a web page, written into the code. It tells a screen reader what each part is. This is a heading, this is a menu, this is a button. People who cannot see the screen can then jump straight to the part they need.

In practice

A city government redesigns its services portal and receives complaints from blind residents who cannot find the form to renew a parking permit. An audit shows that the page has no `main` landmark, uses bold paragraphs instead of headings and builds its tab menu from clickable div elements.

The developers wrap the content in main, convert visual titles into a proper `h1` to `h3` hierarchy, replace the tab menu with buttons that follow the ARIA tabs pattern and label the two navigation regions as main menu and breadcrumbs. They then test the page with NVDA and VoiceOver.

A screen reader user can now press the heading shortcut, hear the list of services and reach the permit form in a few keystrokes instead of tabbing through more than sixty links. The fix also resolves several WCAG Level A failures noted in the city’s accessibility report.