Skip to main content

2.4.2 Page Titled: what it requires and how to test it

Every page needs a title that says what it's about, because the title is the first thing a screen reader announces and the label on every tab.

Level A · Added in WCAG 2.0 · Last reviewed October 18, 2026

What 2.4.2 requires

Web pages must have titles that describe their topic or purpose. In HTML that's the <title> element. The criterion asks for a descriptive title, not just a present one. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 2.4.2 (opens in a new tab) [1][2].

Exceptions and scope:

  • Descriptive, not unique, is the requirement. Distinct titles across pages help people tell tabs and history entries apart, and are good practice.
  • Single-page apps count each view as a page to the user. If the view changes but the title doesn't, people lose track (our single-page-app guide treats this alongside status messages).

Why it matters

When a page loads, screen readers usually announce its title first. It's also what people see in browser tabs, bookmarks, history and search results. "Untitled", "Home | Brand" on every page, or a title that never changes as an app moves between views all make it harder to know where you are. That's especially true for people who rely on audio, or who have many tabs open.

Common failures

Missing or empty title

<!-- Fails -->
<title></title>

<!-- Better -->
<title>Checkout: Payment details | Example Store</title>

The same title on every page

<!-- Fails -->
<title>Example Store</title>  <!-- on every page -->

<!-- Better -->
<title>Navy wool coat | Women's coats | Example Store</title>

SPA view changes without a title update

The URL and content change; the title stays on the previous view.

/* Fails */
router.push('/orders'); // title still 'Dashboard'

/* Better */
router.push('/orders');
document.title = 'Orders | Example App';

Title that doesn't reflect the state

A form that fails validation keeps the same title, so the reload sounds like nothing changed.

<!-- Fails -->
<title>Sign up | Example</title>  <!-- after a failed submit -->

<!-- Better -->
<title>Error: Sign up (2 problems) | Example</title>

Can automated testing check 2.4.2?

Partly. axe-core checks that a non-empty <title> exists. Whether it describes the page is a human judgment.

axe-core 4.13.0 ruleWhat it checks
document-titleeach HTML document has a non-empty <title> element

What automation can't decide: Whether the title describes the page's topic or purpose, whether it changes when the content does (route changes, multi-step forms, error states), and whether it puts the specific part first.

A clean automated result is never proof that 2.4.2 is met. See why sites pass axe-core but fail real screen reader users.

How to test it by hand

  1. Open the page and read its title in the tab or with a screen reader. Does it say what this page is?
  2. Compare titles across a template (products, articles, steps of a checkout). Can you tell them apart?
  3. In single-page apps, navigate between views and confirm the title updates every time.
  4. Submit a form with errors and check whether the title reflects the new state.

New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.

How Accessible helps (and where it stops)

Scanning runs document-title on every URL on a paid plan, so blank titles are found sitewide. The free page check includes it for one page. For single-page apps, our single-page app guide covers why titles need updating on every route change.

Where it stops: Accessible doesn't judge whether a title is descriptive, or verify that titles update after every route change. Read through the titles, and test route changes in apps by hand. No automated tool, ours included, can certify that a criterion is met.

Sources

  1. Understanding Success Criterion 2.4.2: Page Titled (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
  2. Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 2.4.2 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
  3. axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.

Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.

Frequently asked questions

Should the site name go first or last?

W3C's examples put the specific page first and the site name last, so screen-reader users and people scanning tabs hear the distinctive part first.

Do titles have to be unique?

2.4.2 requires descriptive titles. Unique titles help people tell pages apart in tabs and history, and they're good SEO practice too.

Does the H1 count as the page title?

No. 2.4.2 is about the page title (<title> in HTML). A clear H1 helps too, under headings and labels, but it doesn't replace the title.

Find every page with a blank title.

Check a page free, or scan every URL on a paid plan.