Skip to main content
Accessibility.com, LLC
Category: Document Accessibility

Structure Elements

Also known as: HTML structural elements, structural elements
Simply put

In the context of web content, structure elements are the parts of HTML used to organize and group content on a page, such as headings, lists, and sections. They give a document a clear framework so that both people and assistive technologies can understand how content is arranged and how its parts relate to one another. Using these elements properly, rather than relying only on visual styling, helps make content easier to navigate.

Formal definition

Structure elements refer to the HTML elements used to define, group, and organize the structure of a document's content, ranging from long-established elements to additions introduced in HTML5. Proper use of these elements conveys programmatically determinable structure and relationships, which is a foundation for accessibility because assistive technologies rely on this markup to present content order, grouping, and navigation. The evidence provided describes structural elements in general HTML and non-web contexts (for example, structural engineering and narrative writing) but does not enumerate specific elements or map them to particular WCAG success criteria; practitioners should consult current W3C/WAI documentation for authoritative element-level and conformance guidance.

Why it matters

Structure elements provide the underlying framework that lets both people and assistive technologies understand how content on a page is organized. When headings, lists, and grouping elements are used correctly, screen reader users can move through a page by its structure, jumping between sections or headings rather than reading every word in sequence. When structure is conveyed only through visual styling, such as larger or bolded text that merely looks like a heading, that organization is not programmatically available, and users relying on assistive technology may lose the ability to navigate efficiently or understand how parts of the content relate.

Because structure is foundational, weaknesses in markup can ripple into many downstream accessibility problems. Content that appears well organized visually can still be disorienting to a user who cannot perceive the visual cues, and reliance on styling alone tends to break the relationships that assistive technologies depend on. Proper structural markup is generally treated as a baseline practice rather than an optional enhancement.

The term "structural elements" also appears in unrelated fields, such as structural engineering, where it refers to load-bearing components of a building, and in narrative writing, where structure refers to how a story is organized. This entry addresses the web content sense of the term. For authoritative, element-level guidance and how structure maps to specific requirements, practitioners should consult current W3C and Web Accessibility Initiative documentation.

Who it's relevant to

Web Developers and Front-End Engineers
Developers are responsible for choosing and applying HTML structure elements correctly so that a page's organization is conveyed programmatically and not through visual styling alone. Understanding the available elements and their proper use is a core part of building content that assistive technologies can navigate.
Content Authors and Editors
Those who create and format page content influence structure whenever they apply headings, lists, and section groupings. Using genuine structural markup rather than styled text that merely looks organized helps keep content navigable and its relationships clear for all users.
Accessibility Specialists and QA Testers
Specialists evaluate whether a page's structure is exposed correctly to assistive technologies. Because automated checks detect only a portion of issues, manual review and testing with assistive technology are generally needed to confirm that structural markup produces a usable experience.
UX and Interaction Designers
Designers shape how content is grouped and prioritized visually. Coordinating those decisions with an underlying structural markup plan helps ensure that the organization users perceive visually is also available to those who navigate by structure.

Inside Structure Elements

Headings
Elements such as HTML h1 through h6 that establish a document's hierarchy and allow assistive technology users to understand and navigate the organization of content.
Landmarks and Regions
Structural elements (for example, header, nav, main, aside, footer, or their ARIA landmark equivalents) that group related content and enable users to move directly to major sections of a page.
Lists
Ordered, unordered, and description list elements that convey grouping and sequence relationships programmatically rather than relying on visual appearance alone.
Tables
Data table markup, including header cells and associations, that communicates the relationship between data and its column and row headers to assistive technology.
Paragraphs and Text Grouping
Block-level elements that separate and group prose so that reading order and content boundaries are exposed programmatically.
Programmatic Relationships
The underlying markup, roles, states, and properties that expose structure to assistive technology, aligning with WCAG success criteria such as 1.3.1 Info and Relationships (Level A).

Common questions

Answers to the questions practitioners most commonly ask about Structure Elements.

Do visual formatting choices like bold text or larger fonts create structure elements?
No. Applying bold text, increasing font size, or adding visual spacing changes the appearance of content but does not create programmatically determinable structure. Assistive technologies such as screen readers rely on the underlying markup, so text that merely looks like a heading is not conveyed as a heading unless it is marked up with the appropriate element. Structure must be defined semantically in the code, not simulated through styling alone.
If a page uses proper structure elements, does that mean it is fully accessible and legally compliant?
Not necessarily. Correctly implemented structure elements support conformance with certain WCAG success criteria and generally improve the experience for assistive technology users, but they address only part of accessibility. Other factors such as color contrast, keyboard operability, meaningful text alternatives, and overall usability also matter. Meeting individual criteria does not guarantee an accessible experience for all users, and it does not by itself ensure legal compliance. Automated checks detect only a portion of issues, so manual and assistive technology testing remain necessary. This is general information and not legal advice.
Which HTML elements are commonly used to convey document structure?
Commonly used structural elements include heading elements (h1 through h6) to establish a content hierarchy, list elements (ul, ol, and li) for grouped items, table markup (with th and appropriate scope or header associations) for tabular data, and landmark or sectioning elements such as header, nav, main, and footer to identify regions of a page. Using the element that matches the content's meaning allows the structure to be programmatically determined by assistive technologies.
How should headings be organized on a page?
Headings should reflect the logical organization of the content, generally following a consistent hierarchy without skipping levels in a way that obscures relationships. Many practitioners use a single top-level heading to describe the page or main content, with subordinate headings nested beneath it to indicate sections and subsections. The goal is a clear, meaningful outline that lets users, including those navigating by heading with a screen reader, understand and move through the content efficiently.
When should ARIA be used instead of native structure elements?
Native HTML elements are generally preferred because they carry built-in semantics and behavior that browsers and assistive technologies support consistently. ARIA roles and attributes may be appropriate when native markup cannot express a needed relationship or region, or when supplementing custom components. ARIA should be applied carefully, as incorrect or redundant use can introduce confusion. A common guideline is to use native elements first and reserve ARIA for cases where semantics cannot otherwise be conveyed.
How can I verify that structure elements are implemented correctly?
Verification typically combines multiple methods. Automated tools can flag some issues, such as missing headings or improperly marked tables, but they detect only a portion of problems. Manual review of the markup and testing with assistive technologies, such as navigating by headings, lists, and landmarks using a screen reader, helps confirm that the structure is both present and meaningful in practice. Combining automated, manual, and assistive technology testing provides a more complete picture than any single approach.

Common misconceptions

Visually styling text to look like a heading or list is sufficient for accessibility.
Visual styling alone does not expose structure to assistive technology. Screen readers rely on programmatic markup (for example, actual heading or list elements), so structure conveyed only through font size, color, or spacing is generally not perceivable to users who do not see the visual layout.
Passing automated checks for structure means the page is fully accessible.
Automated tools detect only a portion of structural issues, such as missing markup, but cannot reliably judge whether a heading hierarchy is logical or whether landmarks are meaningful. Manual review and assistive technology testing are generally required to confirm that structure supports a usable experience.
Any use of headings satisfies WCAG structure requirements regardless of order.
Marking text as a heading is a starting point, but a disorganized or skipped hierarchy can still hinder navigation. Success criteria such as 1.3.1 Info and Relationships (Level A) address programmatic relationships, while a logical heading order supports usability and is commonly recommended as good practice.

Best practices

Use native semantic elements (such as headings, lists, and tables) rather than styling generic containers to imitate structure, so relationships are exposed programmatically.
Maintain a logical heading hierarchy that reflects the content's organization, and avoid skipping levels where a clear outline can be preserved.
Apply landmark elements or ARIA landmark roles to major page regions so assistive technology users can navigate directly to key sections.
Mark up data tables with proper header cells and associations so that column and row relationships are conveyed to assistive technology.
Test structure with manual review and assistive technologies such as screen readers, since automated checks catch only some issues.
Verify that content aligns with applicable WCAG success criteria, commonly targeting Level AA, and consult qualified legal counsel for questions about legal obligations, which vary by jurisdiction and evolve through regulation and case law.