WCAG 2.4.2: Page Titled
The page title is the label on the browser tab, the text saved to a bookmark, the headline in search results, and the first thing a screen reader speaks when the page loads. This criterion asks for something small with an outsized effect: every page needs a title that describes what it is.
The success criterion, in full
Web pages have titles that describe topic or purpose.
Two requirements hide in one sentence: a title must exist, and it must describethe page. An empty or missing title fails outright; a present-but-generic title like “Untitled Document” or “Home” on every page fails the descriptive half.
Who this helps
A descriptive title is a tiny piece of text that does orientation work for a wide range of people:
Screen reader users
The title is announced first on page load and when switching tabs — it is the primary confirmation of 'where am I?' before any content is read.
People with many tabs open
Descriptive, unique titles let anyone distinguish between a dozen open tabs. Identical titles turn tab-switching into guesswork.
People with cognitive disabilities
A clear title reinforces context and reduces the memory load of tracking which page or step someone is on within a task.
Users returning via bookmarks or history
The title is what gets saved. A meaningful title makes bookmarks and history entries findable weeks later; 'Untitled' makes them useless.
Search and voice users
Search engines show the title as the result headline, and voice assistants read it. Good titles improve both discoverability and spoken navigation.
Everyone, at a glance
Sighted users read the tab to confirm a page loaded correctly. Descriptive titles make that glance informative instead of ambiguous.
What a good title looks like
The criterion is short, so the craft is in the wording. Four habits turn a present title into a genuinely descriptive one:
- Describe the specific page. Name what this page is or does, not just the site. 'Refund policy — Acme Support' identifies the page; 'Acme Support' alone does not.
- Make it unique. Each page should have a distinct title. Repeated titles are the clearest sign that the titles are generic rather than descriptive.
- Front-load the important part. Put the page-identifying words first and the site name last. Titles get truncated in tabs and search results, and screen readers read the start first.
- Reflect meaningful state. For dynamic pages, update the title to match the state: a cart count, a search query and result count, a step in a wizard, or an error condition.
Title versus heading
Do not confuse the page title (the <title> in the head, covered here) with the on-page <h1> heading (covered by 2.4.6 Headings and Labels and 1.3.1 Info and Relationships). They serve different tools and can differ in wording, but keeping them consistent means the tab, the search result, and the top of the page all tell one story.
Pass and fail examples
✓ Passes 2.4.2
- “Contact us — Acme Support” on the contact page.
- “Shopping cart (3 items) — Acme Store” that updates with the count.
- “How to create accessible forms — Acme Blog” on an article.
- “Error 404: page not found — Acme” on a not-found page.
- A single-page app that updates the title on each view change.
✗ Fails 2.4.2
- A missing or empty
<title>element. - “Untitled Document” — a leftover default.
- “Home” or “Page” used identically across the whole site.
- The site name only, with nothing identifying the page.
- An SPA view that keeps the previous route’s title after navigating.
Code examples
Generic vs. descriptive titles
The <title> lives in the document head. Front-load the page-specific part and append the site name.
<!-- ✗ Missing, empty, or generic titles -->
<head>
<!-- no title element at all -->
</head>
<head><title></title></head>
<head><title>Untitled Document</title></head>
<head><title>Home</title></head> <!-- same on every page -->
<!-- ✓ Descriptive, unique, front-loaded titles -->
<head><title>Refund policy — Acme Support</title></head>
<head><title>Blue running shoes, size 10 — Acme Store</title></head>
<head><title>Search results for "invoice" (12 found) — Acme</title></head>Keep the title in sync with page state
When content changes without a reload, update document.title so the tab and the screen reader announcement stay accurate.
// Reflect meaningful page state in the title so it stays
// descriptive as the page changes.
// Cart item count
function setCartTitle(count) {
document.title = count === 0
? "Your cart is empty — Acme Store"
: `Cart (${count} item${count === 1 ? "" : "s"}) — Acme Store`;
}
// Search results
function setSearchTitle(query, resultCount) {
document.title =
`Search results for "${query}" (${resultCount} found) — Acme`;
}
// Surface a form error state so screen reader users notice on
// the title announcement, not only inline
function setFormTitle(hasErrors) {
document.title = hasErrors
? "Please fix 2 errors — Checkout — Acme"
: "Checkout — Acme";
}Per-route titles in a framework
Modern frameworks set the title per route. In the Next.js App Router, export a metadata object and use a template so every page appends the site name automatically.
// Next.js App Router: set a descriptive title per route.
// This renders a real <title> element on the server.
import type { Metadata } from "next";
export const metadata: Metadata = {
title: "Refund policy — Acme Support",
description: "How and when to request a refund from Acme.",
};
// A layout can define a template so child routes append the
// site name automatically:
// title: { default: "Acme Support", template: "%s — Acme Support" }Interactive demo
Type a title, or pick one of the presets, to see how it would read in a browser tab and where it falls short of describing a page. The check is a heuristic — 2.4.2 ultimately depends on human judgment about whether the title fits the page.
This is a rough heuristic to build intuition — WCAG 2.4.2 is a human judgment call about whether the title describes the page, not a character count.
Common failures
- A missing or empty <title> element, so browsers fall back to the URL and screen readers announce nothing useful.
- Leftover default titles like 'Untitled Document', 'New Page', or the CMS template name.
- The same generic title ('Home', 'Page', the site name) on every page, so nothing is distinguishable.
- Only the site or brand name, with no words identifying the individual page.
- Site name front-loaded so the unique part is truncated in narrow tabs and search results.
- Single-page apps that never update document.title on client-side navigation, leaving a stale title.
- Titles stuffed with keywords for SEO at the expense of a clear, human-readable description.
- Error and status pages (404, 500, maintenance) left with the generic homepage title instead of describing the error.
How to test for 2.4.2
- 1
Read the browser tab and window title
Load the page and look at the tab. Is there a title at all, and does it tell you what this page is without seeing the content? An empty tab, a URL, or a default like 'Untitled' is an immediate failure.
- 2
Compare titles across pages
Open several pages of the site in tabs and check that each has a distinct, descriptive title. If the homepage, contact page, and a product page all read the same, the titles are generic.
- 3
Listen to the load announcement
With a screen reader running, load or refresh the page and confirm the announced title matches the page and would help you distinguish it from other open tabs.
- 4
Exercise dynamic and single-page views
For SPAs and stateful pages, navigate between views and change state (add to cart, run a search, trigger a form error). Confirm document.title updates to reflect each new view or state.
- 5
Run an automated check, then judge quality
axe DevTools, WAVE, and Lighthouse flag a missing or empty title reliably. They cannot tell whether a present title is actually descriptive, so finish with the manual reading checks above.
For a structured audit, work through the full WCAG 2.2 checklist.
Related Success Criteria
A mechanism is available to bypass blocks of content that are repeated.
Focusable components receive focus in an order that preserves meaning.
The purpose of each link can be determined from link text or context.
More than one way is available to locate a page within a set of pages.
Headings and labels describe topic or purpose.
Frequently asked questions
What does WCAG 2.4.2 Page Titled require?
It requires that web pages have titles that describe their topic or purpose. In HTML this is the <title> element in the document head, which browsers show in the tab, bookmarks, and history, and which screen readers announce first when a page loads. The title must exist and it must be meaningful — it should tell a user what page they are on and distinguish it from other pages on the site. It is a Level A success criterion, part of WCAG since 2.0, and one of the easiest to meet yet frequently overlooked in single-page apps and templated systems.
Is the page title the same as the h1 heading?
No, though they are related and often overlap in wording. The title is the <title> element in the head; it names the page for the browser tab, bookmarks, search results, and the screen reader's initial announcement, and it exists outside the visible page. The h1 is a visible heading at the top of the content. A page can pass 2.4.2 with a good <title> even if it has no h1, and vice versa — they are governed by different criteria (2.4.2 for the title, 1.3.1 and 2.4.6 for headings). Best practice is to keep them consistent so the tab and the on-page heading tell the same story.
How does the title help screen reader users specifically?
When a page loads, or when a screen reader user moves to a new page or tab, the very first thing announced is the document title. It is their orientation cue — the equivalent of a sighted user glancing at the tab or the top of the page to confirm they landed where they expected. If every page shares the same generic title, or the title is empty, the user hears no useful confirmation and cannot tell open tabs apart. A descriptive, unique title turns that first announcement into instant context.
What makes a good page title?
A good title is descriptive, unique, and front-loaded. Put the most specific, page-identifying information first, followed by the site or section name — for example 'Refund policy — Acme Support' rather than 'Acme Support — Refund policy'. Front-loading matters because titles get truncated in narrow browser tabs and in search results, and screen reader users hear the beginning first. Keep each page's title distinct from the others, and update it to reflect meaningful state changes such as a cart item count, a search query, or a form-error condition.
Do titles need to be unique across the whole site?
Uniqueness is strongly recommended but is not the literal wording of the criterion, which asks that the title describe the page's topic or purpose. In practice a description that genuinely identifies the page ends up being unique, because two different pages have two different purposes. Duplicate titles across many pages are a strong signal that the titles are generic rather than descriptive — users cannot tell tabs, bookmarks, or history entries apart. So while a rare coincidental duplicate is not an automatic failure, systematic duplication almost always indicates a real 2.4.2 problem.
How do I handle titles in single-page apps that change views without a reload?
Treat each view as its own page and update document.title whenever the route changes. Frameworks make this straightforward — Next.js exposes a metadata/title API per route, React Router apps commonly set the title in a route effect, and most routers have a title strategy. The key point is that a client-side navigation that does not update the title leaves screen reader users on a stale announcement and gives every view the same tab label. Setting the title on view change, and optionally announcing it via a live region, keeps orientation intact without full page reloads.