Category: ARIA and Semantic Structure
Document Structure Roles
Also known as: Document Structural Roles, ARIA Document Structure Roles, Structural Roles
Simply put
Document structure roles are part of ARIA (Accessible Rich Internet Applications), a set of attributes that describe the meaning and organization of content on a web page to assistive technologies such as screen readers. They help convey the structural purpose of a section of content, such as identifying headings, lists, or the main region of a page. Many of these roles are best expressed through native HTML elements rather than ARIA, and some ARIA structural roles are no longer recommended for general use.
Formal definition
Document structure roles are a category of WAI-ARIA roles that provide a structural description for a section of content, conveying accessibility semantics for page structures such as headings, lists, and tables. Within the ARIA role taxonomy, the abstract 'structure' role serves as the superclass for these document structure roles. In practice, native HTML semantics are generally preferred over ARIA where equivalent elements exist, and per current MDN guidance, several document structure roles should no longer be used. This entry describes ARIA authoring semantics as documented by the W3C and MDN and is not legal advice; conformance to specifications such as WCAG or applicable requirements under Section 508 or the ADA should be evaluated separately and, where necessary, with qualified counsel.
Why it matters
Assistive technologies such as screen readers rely on structural semantics to convey how content on a page is organized. When a section is correctly identified as a heading, list, or the main region of a page, users navigating with these tools can understand the layout, jump between sections, and orient themselves within complex content. Document structure roles are the ARIA mechanism for expressing this structural meaning where it is not otherwise available, helping bridge the gap between visual presentation and programmatically determinable structure.
Who it's relevant to
Front-end and accessibility engineers
Engineers building or remediating web interfaces need to understand when structural semantics should be expressed through native HTML and when an ARIA structural role is appropriate. Because several document structure roles are, per current MDN guidance, no longer recommended for general use, engineers should consult up-to-date W3C and MDN references before applying them.
UX and content designers
Designers who organize page layouts and content hierarchies influence how structure is conveyed to assistive technology users. Understanding how headings, lists, and main regions map to structural semantics helps ensure that the intended organization of content is programmatically available, not just visually apparent.
Compliance officers and accessibility auditors
Those evaluating conformance should recognize that correct use of structural semantics contributes to an accessible experience but is only one part of a broader evaluation. Conformance to specifications such as WCAG, or applicable requirements under Section 508 or the ADA, should be assessed separately and, where necessary, with qualified counsel; this entry describes ARIA authoring semantics and is not legal advice.
Inside Document Structure Roles
Landmark Roles
ARIA roles such as banner, navigation, main, complementary, and contentinfo that identify major regions of a page, allowing assistive technology users to understand page organization and jump between sections. Many correspond to native HTML5 elements like header, nav, main, aside, and footer.
Heading Structure
A logical hierarchy of headings (h1 through h6) that conveys the outline and relationships of content. Screen reader users commonly navigate by headings, so a meaningful, nested order matters more than visual styling alone.
Document Roles
Roles that describe the nature of content regions, such as document and application, which signal to assistive technology how to handle interaction and reading modes within a region.
Native Semantic Elements
HTML elements that carry implicit structural roles (for example, lists, tables, and sectioning elements). Using native semantics is generally preferred over adding ARIA roles because supported native elements convey structure without extra attributes.
ARIA Roles, States, and Properties
Attributes from the WAI-ARIA specification used to supplement or override structural semantics where native HTML is insufficient. They communicate role, current state, and relationships to the accessibility tree consumed by assistive technology.
Accessibility Tree
The programmatic representation of page structure, roles, names, and states that browsers expose to assistive technologies. Document structure roles help populate this tree so that structure is perceivable programmatically, not just visually.
Common questions
Answers to the questions practitioners most commonly ask about Document Structure Roles.
Does using document structure roles guarantee that my content is accessible?
No. Applying document structure roles supports assistive technology navigation and can help satisfy relevant WCAG success criteria, but it does not by itself guarantee an accessible experience. Roles must be applied correctly and in a way that reflects the actual content structure. Automated tools detect only a portion of issues, so manual testing and testing with assistive technology are generally needed to confirm that the structure conveys meaning as intended.
Are document structure roles legally required by the ADA?
The ADA is a US civil rights law and does not itself contain detailed technical specifications for document structure. Courts and settlements have often referenced WCAG as a benchmark, and using structural roles can help meet commonly cited WCAG criteria, but requirements depend on the applicable authority and evolve through regulation and case law. This is general information, not legal advice; consult qualified legal counsel regarding specific obligations.
When should I rely on native HTML elements instead of ARIA document structure roles?
Native semantic elements are generally preferred where they exist, because they carry built-in structure and behavior recognized by browsers and assistive technology. ARIA roles are commonly used to supplement structure where native semantics are unavailable or insufficient, or in non-HTML formats. Where a native element and an explicit role would express the same meaning, using the native element first is often the more reliable approach.
How can I verify that document structure roles are working as intended?
Verification generally combines multiple methods: reviewing the rendered structure with automated checks, manually inspecting the markup, and testing navigation with assistive technologies such as screen readers. Because automated testing catches only some issues, confirming that headings, landmarks, and other structural elements are announced and navigable in practice is an important step.
Which WCAG considerations most commonly relate to document structure roles?
Structure roles are often discussed in relation to success criteria concerned with programmatically conveying information, relationships, and meaningful sequence, which support users who navigate by structure. Applicability depends on the specific criteria, the WCAG version in use, and the conformance level being targeted, so review the current WCAG documentation for the exact requirements relevant to your context.
How do document structure roles apply outside of HTML web pages?
Structural roles are commonly relevant in non-HTML formats such as tagged documents, where they help assistive technology recognize headings, lists, tables, and other regions. The specific mechanisms and how conformance is evaluated differ by format and applicable standard, so implementation should follow the guidance appropriate to the document type and the authority that governs it.
Common misconceptions
Adding ARIA roles always makes content more accessible.
ARIA supplements structure only where native HTML falls short. Incorrect or redundant ARIA can override native semantics and create a worse experience. The commonly cited guidance is to prefer native HTML elements and use ARIA only when necessary.
Headings are just for visual styling, so any element styled to look like a heading is sufficient.
Assistive technology relies on programmatic heading semantics to build a navigable outline. Text that merely looks like a heading but lacks the correct element or role is not exposed as a heading, so users who navigate by headings may miss it.
Correct document structure roles guarantee WCAG conformance and legal compliance.
Proper structure supports criteria related to information and relationships and navigation, but conformance depends on many factors. Automated tools detect only a portion of structural issues, and manual and assistive technology testing are required. Meeting these criteria does not by itself guarantee an accessible experience or immunity from legal claims.
Best practices
Use native HTML sectioning and semantic elements (main, nav, header, footer, aside, lists, tables) before reaching for ARIA roles, adding ARIA only where native semantics are insufficient.
Establish a logical heading hierarchy that reflects content relationships, avoiding skipped levels and using headings for structure rather than solely for visual appearance.
Provide clearly identified landmark regions so assistive technology users can orient themselves and navigate directly to major sections of the page.
Avoid redundant or conflicting ARIA that duplicates or overrides implicit native roles, and validate that roles, states, and properties are exposed correctly in the accessibility tree.
Test structure with assistive technologies such as screen readers and through manual review, since automated checks catch only a subset of structural issues.
Verify keyboard navigation and reading order align with the intended document structure so that programmatic and visual sequences remain consistent.