Category: ARIA and Semantic Structure

Landmark Roles

Also known as: ARIA Landmarks, Landmark Regions

Simply put

Landmark roles are labels applied to major sections of a web page, such as the main content, header, or navigation, so that these regions can be identified and understood by assistive technologies. They help people who use screen readers understand how a page is organized and move quickly between its parts. In practice, they act like signposts that describe the structure of a page.

Formal definition

Landmark roles are a category of WAI-ARIA roles used to programmatically identify and classify the organizational sections of a web page, enabling assistive technology users to perceive page structure and navigate between regions. Per the WAI-ARIA specification, the generic landmark role is an abstract superclass that is not implemented directly; instead, specific landmark roles (for example, role="main" for the main landmark or role="banner" for the page header) are applied to sections. Landmarks can be provided via explicit ARIA role attributes or, where supported, through corresponding native HTML sectioning elements, and may be labeled to distinguish multiple instances of the same landmark type. When only a single main landmark exists on a page, an accessible label is optional.

Why it matters

Landmark roles give assistive technology users a reliable way to understand and move through the structure of a web page. A sighted user can visually scan a page to locate the header, primary navigation, main content, and footer, but a screen reader user often experiences a page linearly. Landmark roles restore a sense of structure by acting as signposts, allowing users to jump directly to the main content or navigation rather than reading or tabbing through every element in sequence.

When landmarks are missing, mislabeled, or overused, this navigational advantage breaks down. Multiple unlabeled landmarks of the same type can leave a user unsure which region they have reached, and content placed outside any landmark can be harder to locate. Because landmark roles convey the organization and structure of a page, applying them thoughtfully supports faster orientation and more efficient navigation for people who rely on assistive technologies.

Landmark roles are one component of accessible page structure rather than a complete solution. Correctly applied landmarks do not by themselves guarantee an accessible experience, and their effectiveness depends on how well they reflect the actual organization of the page. Manual and assistive technology testing are generally needed to confirm that landmarks are meaningful, appropriately labeled, and helpful in practice.

Who it's relevant to

Front-End Developers

Developers implement landmark roles either through native HTML sectioning elements or explicit ARIA role attributes. They are responsible for ensuring each major region is correctly classified, that labels are provided where multiple landmarks of the same type exist, and that the generic abstract landmark role is not used directly.

UX and Interface Designers

Designers shape the overall page structure that landmarks describe. By planning clear, consistent regions such as header, navigation, main content, and footer, they make it easier to map meaningful landmarks onto the interface and reduce ambiguity for users navigating by region.

Accessibility Engineers and QA Testers

Those testing for accessibility verify that landmarks are present, correctly labeled, and meaningful in practice. Because automated tools detect only a portion of issues, manual review and testing with screen readers are generally required to confirm that landmark navigation actually helps users orient and move through the page.

Screen Reader and Assistive Technology Users

People who navigate pages non-visually rely on landmarks as signposts to understand page organization and move quickly between regions. Well-implemented landmarks can substantially improve orientation and navigation efficiency for these users.

Content and CMS Teams

Teams building templates and page layouts within content management systems influence whether landmarks are applied consistently across a site. Ensuring templates emit appropriate sectioning and labeling helps maintain reliable structure as content is created and updated.

Inside Landmark Roles

ARIA Landmark Roles

Values assigned via the WAI-ARIA role attribute (such as banner, navigation, main, complementary, contentinfo, search, form, and region) that identify distinct sections of a web page so assistive technologies can convey page structure to users.

Native HTML Sectioning Elements

HTML5 elements including header, nav, main, aside, and footer that expose implicit landmark roles without requiring an explicit ARIA role attribute, generally the preferred approach where a native element exists.

banner Role

Identifies site-oriented introductory content, commonly a page header; typically mapped to the header element when it is not nested within a sectioning element.

navigation Role

Identifies a collection of navigational links; corresponds to the nav element and helps screen reader users locate and skip between menus.

main Role

Identifies the primary content of the page, of which there is generally intended to be one per page; corresponds to the main element.

complementary Role

Identifies supporting content that is meaningful on its own but related to the main content, such as a sidebar; corresponds to the aside element.

contentinfo Role

Identifies information about the parent document, such as footers with copyright or related links; commonly mapped to the footer element when not nested within a sectioning element.

Accessible Names for Landmarks

Labels applied via aria-label or aria-labelledby to distinguish multiple landmarks of the same type, such as separate navigation regions, so users can tell them apart.

Common questions

Answers to the questions practitioners most commonly ask about Landmark Roles.

Do landmark roles guarantee that a page is accessible?

No. Landmark roles help assistive technology users navigate a page by identifying regions such as banner, navigation, main, and contentinfo, but they do not by themselves make a page accessible. Landmarks address one aspect of navigation and structure; a page can include correct landmarks while still failing other requirements related to keyboard operability, color contrast, form labeling, focus management, and meaningful content. Conformance with WCAG generally requires attention across many success criteria, and manual testing with assistive technology is needed to confirm a usable experience. Landmarks are a helpful component of an accessible structure, not a complete solution.

Are ARIA landmark roles always necessary if I use HTML5 elements like <header>, <nav>, and <main>?

Generally, no. Many native HTML5 elements carry implicit landmark roles when used in their standard context, for example, <nav> commonly maps to the navigation role, <main> to the main role, and <aside> to the complementary role. When you use the appropriate native element, adding a redundant explicit ARIA role is usually unnecessary and can, in some cases, create confusion. Explicit ARIA landmark roles are more relevant when a native element is unavailable, when older browser or assistive technology support is a concern, or when a generic element such as a <div> is used and needs an assigned role. Because element-to-role mapping and support can vary, testing with assistive technology is advisable.

How should I handle a page that has more than one navigation or complementary region?

When a page contains multiple instances of the same landmark type, it is commonly recommended to give each one a distinguishing accessible name so users can tell them apart. This is often done with the aria-label or aria-labelledby attribute, for example, distinguishing a primary navigation from a footer navigation. Providing distinct labels helps assistive technology users understand the purpose of each region when they navigate by landmark. Verify the labels are announced as expected by testing with screen readers.

Which content should be placed inside the main landmark?

The main landmark (or the native <main> element) is generally intended to contain the primary, unique content of the page, the central content that distinguishes that page from others. Repeated content such as site-wide headers, primary navigation, and footers typically belongs in banner, navigation, and contentinfo regions rather than in main. A page commonly has a single main landmark. Placing the primary content in main can also support features like skip navigation, allowing users to move directly to the core content.

How can I verify that landmark roles are implemented correctly?

Automated tools can detect some landmark issues, such as missing or duplicated regions, but automated testing detects only a portion of potential problems. A thorough review generally combines automated checks with manual testing using screen readers and keyboard navigation to confirm that landmarks are announced, named clearly, and organized in a way that aids navigation. Reviewing the accessibility tree in browser developer tools can also help confirm which roles are being exposed. Testing across more than one assistive technology and browser combination is often advisable because support can vary.

Should every part of a page be contained within a landmark region?

It is commonly considered good practice for the significant content areas of a page to fall within appropriate landmark regions so that assistive technology users can navigate the page structure efficiently. Content that sits outside any landmark can be harder to locate through landmark navigation. Where practical, organizing the primary structural areas, such as banner, navigation, main, and contentinfo, into landmarks supports predictable navigation. This is a practical usability recommendation rather than a claim about any specific legal requirement; consult current WCAG techniques and qualified guidance for details relevant to your context.

Common misconceptions

Landmark roles are a WCAG success criterion by that name, so simply adding them guarantees conformance.

Landmark roles are one technique that can support requirements related to structure and navigability, but adding roles does not by itself guarantee conformance or an accessible experience. Their effectiveness depends on correct, meaningful use, and full evaluation generally requires manual and assistive technology testing since automated tools detect only a portion of issues.

You should add explicit ARIA landmark roles to every element to be safe.

Using native HTML sectioning elements is generally preferred where one exists, and redundant or excessive roles can create confusion. ARIA roles are most useful where no native element conveys the intended semantics, following the principle of using ARIA only when needed.

Any number of identical landmarks is fine as long as the roles are present.

Multiple landmarks of the same type (for example several navigation regions) should generally be distinguished with accessible names so users can differentiate them; otherwise the landmarks may be harder to navigate rather than more helpful.

Best practices

Prefer native HTML sectioning elements (header, nav, main, aside, footer) over explicit ARIA roles where a native element conveys the intended semantics.

Provide a single main landmark for the primary content and ensure the most important page regions are represented by landmarks.

Use aria-label or aria-labelledby to give unique, meaningful names to multiple landmarks of the same type so users can distinguish them.

Avoid redundant or excessive roles, and apply ARIA only when a native element does not exist for the intended purpose.

Verify landmark structure through manual review and testing with assistive technologies such as screen readers, since automated checks detect only a portion of issues.

Confirm that landmarks reflect the actual visual and logical organization of the page so the exposed structure is accurate and helpful to users.