Skip to main content
Accessibility AccessLint 0.16

Page should contain a level-one heading.

About this AccessLint rule

Every web page should contain at least one level-one heading. This heading communicates the main topic of the page and gives users a reliable way to orient themselves within the content. Screen reader users, in particular, rely on heading structure to navigate pages efficiently. Most screen readers provide shortcuts that let users jump directly to headings by level, and a level-one heading is the expected starting point for the primary content of any page.

When a page lacks a level-one heading, screen reader users have no quick way to confirm what the page is about or to skip past navigation and other repeated elements to reach the main content. Keyboard-only users and people with cognitive disabilities also benefit from clear heading structure, since it provides a visible outline of the page's organization.

How this relates to WCAG

This rule maps to WCAG 2.1 Success Criterion 2.4.1 "Bypass Blocks" (Level A) and is informed by Success Criterion 1.3.1 "Info and Relationships" (Level A). A level-one heading gives users a mechanism to identify and jump to the main content area. It also ensures that the page's structure is programmatically determinable, not just visually implied through font size or weight.

WCAG technique H69 ("Providing heading elements at the beginning of each section of content") recommends using headings to describe the structure of the page. The level-one heading is the top of that hierarchy.

How to fix this

Add a single <h1> element that describes the primary content of the page. Place it at or near the beginning of the main content area. The heading text should match or closely reflect the page's <title> so that users who arrive at the page via search results or bookmarks see a consistent description.

If the design requires that the level-one heading not be an <h1> element, you can use an element with role="heading" and aria-level="1" instead. However, using the native <h1> element is almost always preferable because it requires no extra attributes and has universal browser and assistive technology support.

A few practical guidelines:

  • Each page should have at least one level-one heading. Most pages need only one.
  • The <h1> should describe the page's primary topic, not the site name (unless the page is the homepage and the site itself is the topic).
  • Do not skip heading levels. If the page has an <h1>, the next heading in the content should be <h2>, not <h3>.

Examples

Missing level-one heading

This page has no <h1>. Screen reader users scanning by heading level will find no level-one heading to identify the page's topic.

<html lang="en">
<head>
<title>Our menu - Example Restaurant</title>
</head>
<body>
<nav>
<a href="/">Home</a>
<a href="/menu">Menu</a>
</nav>
<main>
<h2>Appetizers</h2>
<p>Spring rolls, soup of the day...</p>
<h2>Entrees</h2>
<p>Grilled salmon, pasta primavera...</p>
</main>
</body>
</html>

Fixed with a native <h1> element

Adding an <h1> at the start of the main content gives the page a clear, navigable label.

<html lang="en">
<head>
<title>Our menu - Example Restaurant</title>
</head>
<body>
<nav>
<a href="/">Home</a>
<a href="/menu">Menu</a>
</nav>
<main>
<h1>Our menu</h1>
<h2>Appetizers</h2>
<p>Spring rolls, soup of the day...</p>
<h2>Entrees</h2>
<p>Grilled salmon, pasta primavera...</p>
</main>
</body>
</html>

Fixed with role="heading" and aria-level="1"

If a native <h1> element cannot be used, apply the heading role and level explicitly. This approach is less common but produces the same result for assistive technology.

<main>
<div role="heading" aria-level="1">Our menu</div>
<h2>Appetizers</h2>
<p>Spring rolls, soup of the day...</p>
</main>

Native HTML elements are always preferred over ARIA roles when they exist, so use <h1> unless there is a specific technical constraint preventing it.

Detect accessibility issues automatically

Rocket Validator scans your site with complementary accessibility engines, helping teams find issues across every page.

Help us improve our guides

Was this guide helpful?
๐ŸŒ Trusted by teams worldwide

Validate at scale.
Ship accessible websites, faster.

Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.

Scheduled Reports
API Access
Open Source Standards
$7 / 7 days

Pro Trial

Full Pro access. Cancel anytime.

Start Pro Trial โ†’

Join teams across 40+ countries