WebAIM - Web Accessibility In Mind

E-mail List Archives

for

Number of posts in this thread: 12 (In chronological order)

From: Sumit Patel
Date: Aug 19, 2025 7:55AM
Subject: Query on Heading Hierarchy – Best Practices for Accessibility
No previous message | Next message →

Hi all,

I hope you're doing well.

I have a query regarding the heading hierarchy used within applications,
specifically in terms of accessibility and best practices.

Let’s take the example of an application called **"ABC"**, and a page
within it named **"Screen 1"**. This is a common pattern I’m seeing in many
applications:

* At the top of the page, on the left side, we have the **logo**.
* To the right of the logo, we display the **application name ("ABC")**.
* Then, in the main content section, the first visible heading is the
**page title ("Screen 1")**.

Now, regarding heading markup, I usually mark:

* `"Screen 1"` as **heading level 1 (`<h1>`)**
* `"ABC"` as **heading level 2 (`<h2>`)**

Even though the application name appears visually before the page title, I
feel `"Screen 1"` semantically deserves the `<h1>` as it represents the
main content of the page.

I understand there are two generally accepted best practices:

1. Heading levels should **not be skipped**.
2. The **main content** of the page should **start with an `<h1>`**.

From a **screen reader user’s perspective**, marking `"Screen 1"` as `<h1>`
is helpful, as many users rely on heading navigation (e.g., using the "1"
key to jump to the main heading). This makes `"Screen 1"` a logical
candidate for the primary heading. Also, as the page title, it makes sense
to be the most prominent semantically.

That said, marking **both** `"ABC"` and `"Screen 1"` as `<h1>` would remove
this advantage for screen reader users, and could make the structure less
clear. So, I don't think that would be ideal either.

I'd really appreciate your thoughts on this.

* Do you agree with this approach?
* Is there a better or more widely accepted method to handle this kind of
heading structure?

Looking forward to your suggestions.

Regards,
Sumit.

From: Steve Green
Date: Aug 19, 2025 8:19AM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | Next message →

Without having seen the application, my inclination would be to make the application name <h1> because it is the highest level in the logical structure. The screen name would be <h2> because it is a subsection of the application. That said, I would not be terribly bothered if the application name isn't a heading at all as long as the name is mentioned in the <title> element. In this case the screen name would be <h1>.

Having observed countless hours of user testing, my view is that consistency from screen to screen is more important than what the heading levels are. Screen reader users have many different strategies for in-page navigation, and I have been surprised at how few jumped to the <h1> heading in our testing. Of course, this is a relatively small sample, and people may behave differently in a test session, although we hope they don't.

Steve Green
Managing Director
Test Partners Ltd

From: Richter,Susan
Date: Aug 19, 2025 8:39AM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | Next message →

I was going to suggest the same as Steve below - wherein don't make the application name an H1. We do something very similar on our subsites (ie. https://www.nscc.ca/alumni/about/index.asp). Note that the "Alumni Relations" is not an H1 but IS part of the page title. The H1 on the page is the only H1 and is the start of the content, so it works semantically.

Susan Richter
Senior Web Interface Developer
Digital Products & Experience
Nova Scotia Community College
Institute of Technology Campus
Web: nscc.ca

From: Andrews, David B (DEED)
Date: Aug 19, 2025 12:28PM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | Next message →

I agree with all of this. My practice, as a user, is to use the h key for heading, because you don't know in advance what heading level someone will use or start with. I have seen pages where someone puts a H3 or H4 at the top of the page!

Dave

From: Barry
Date: Aug 20, 2025 1:25AM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | Next message →

Just to throw a curve-ball into the topic: WCAG doesn't actually specify that a page only has one h1, so, in theory, both the title and the name could each be h1... although I'm old school and that doesn't sit well with me ????

From: Steve Green
Date: Aug 20, 2025 3:34AM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | Next message →

Different parts of WCAG are contradictory. In most places, it says that the heading levels must reflect the logical structure of the content, which is sensible. This allows pages to contain more than one h1 heading as long as their content is at the same logical level i.e. the content of the second h1 is not a subsection of the first but is unrelated.

In this case, I would argue that the page content is a subsection of the application and that the screen name therefore cannot be the same heading level as the application name.

Steve

From: Richter,Susan
Date: Aug 20, 2025 4:14AM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | Next message →

We typically avoid multiple H1's on the page for both accessibility and SEO reasons.

Having one H1 identifies the primary topic/subject of the page, making it easier for search engines to index. And, for screen reader users, it clearly defines the main topic by using H1. I suppose it's not a WCAG hard and fast rule, just a best practice we've been using based on our research.


Susan Richter
Senior Web Interface Developer
Digital Products & Experience
Nova Scotia Community College
Institute of Technology Campus
Web: nscc.ca

From: Steve Green
Date: Aug 20, 2025 4:24AM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | Next message →

It certainly isn't a hard and fast WCAG rule. If a page contains two entirely unrelated topics, it can and indeed must have two h1 headings if there isn't an overarching heading. For instance, if a page contains multiple news articles, the heading for each one should be h1 if there is no overarching "News" heading. There may not be such a heading because at level AA there is no requirement to have visual headings, although there is at level AAA. If there is a "News" heading, it would be h1 and each news article would be h2.

In my previous email I forgot to mention the way in which WCAG is contradictory. As I said, in most places, it says that the heading levels must reflect the logical structure of the content, which is what almost everyone does. However, in at least one place it says the headings should reflect the importance of the content, which is an entirely different thing. Furthermore, it is subjective because we will not have a shared view of importance. By contrast, we should be able to agree on the logical structure of a page.

Steve

From: Duff Johnson
Date: Aug 20, 2025 9:38AM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | Next message →

A shell from the peanut gallery….

This conversation is always fascinating to me given that it occurs within HTML’s interesting constraints…

- A <title> tag that does NOT enclose page content, only metadata
- No semantic markup for title content, and therefore, no way to distinguish the title from the headings
- Ambiguity regarding whether headings denote structure or importance
- Heading levels limited to 6 (effectively to 5, if h1 is reserved for the page title)

Steve raises some of the cases that have always bothered me about HTML’s fudge-up of headings. Isn’t it crazy that in 2025 there’s still ambiguity about whether headings denote structure vs importance? Or that h1 is forced to serve double-duty as a heading concept AND a titling concept?

In PDF (my world), we more-or-less followed the HTML paradigm for headings from 2001 (when Tagged PDF was introduced) until 2017, with one major difference: headings in PDF signify structure, not importance.

We changed this paradigm with PDF 2.0 (first published in 2017) because the gap between HTML’s approach to structuring content and the reality of the structures found in PDF documents was too big to ignore.

As a result PDF 2.0 added a Title tag to enclose the document's on-page title content, enriching PDF’s semantic structure to allow document titles to be clearly distinguished from document headings, and thus ending the debate (for PDF) about how / when / where H1 was correct. We also allowed heading levels above 6.

Of course, it will take years to move industry as a whole to PDF 2.0, but at least, once folks get there they will find that a document’s structure may be unambiguously determined.

IMHO, HTML could also benefit from a <title> tag inside the <body>. :-)

Duff.



> On Aug 20, 2025, at 06:24, Steve Green via WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:
>
> It certainly isn't a hard and fast WCAG rule. If a page contains two entirely unrelated topics, it can and indeed must have two h1 headings if there isn't an overarching heading. For instance, if a page contains multiple news articles, the heading for each one should be h1 if there is no overarching "News" heading. There may not be such a heading because at level AA there is no requirement to have visual headings, although there is at level AAA. If there is a "News" heading, it would be h1 and each news article would be h2.
>
> In my previous email I forgot to mention the way in which WCAG is contradictory. As I said, in most places, it says that the heading levels must reflect the logical structure of the content, which is what almost everyone does. However, in at least one place it says the headings should reflect the importance of the content, which is an entirely different thing. Furthermore, it is subjective because we will not have a shared view of importance. By contrast, we should be able to agree on the logical structure of a page.
>
> Steve
>

From: Hash, Colton
Date: Aug 20, 2025 1:03PM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | Next message →

I have read a few sources saying to have the page titles as <h1> and use a span or <h2> for web site titles. The home page can have a different heading structure, where the website title is the <h1>. However, I am also wondering about best practices for this.

Here is a link I have used as a reference from Yale Web Accessibility Resources:
https://usability.yale.edu/web-accessibility/articles/headings

This is still a question I have as well. I manage web pages with a Title for a Government Agency, Division Name and names of Division Subsections all in the Header, along with a unique web page title... so organizing that with multiple heading levels starting with H2 for the website title feels clunky, but it makes sense as a logical structure with H1 for the page title:

<header>
<h2> Government Agency
<h3>Division Name
<h4>Subsection Name
<h1> Unique Web page name
</header>

From: Steve Green
Date: Aug 21, 2025 2:12AM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | Next message →

In my view, the Government Agency, Division Name and Subsection Name should not be headings.

Steve

From: Steve Green
Date: Aug 21, 2025 2:25AM
Subject: Re: Query on Heading Hierarchy – Best Practices for Accessibility
← Previous message | No next message

The ambiguity regarding whether headings denote structure or importance only occurs in the non-normative text, which can be changed, at least in principle. There are only a tiny number of references to importance as far as I am aware, so I expect they were written by one or two people 20 years ago and somehow slipped through the proof reading. I don't know anyone in the accessibility community who would advocate applying headings based on importance, although someone clearly did once. I will give some thought to raising this on the WCAG GitHub discussion forum.

Steve