Page Titled

In brief

The page title is the first thing a screen reader announces when a page loads, and it is the label in the browser tab, in the history, in bookmarks and in search results. "Untitled" or "Home" on every page tells users nothing about where they are.

This criterion requires that web pages have titles that describe their topic or purpose. A good title is specific to the page and puts the most distinctive part first.

What does it cover?

• What is covered: The title element of every web page, and the title of single-page application views as they change.
• Describes topic or purpose: The title should tell a user what the page is about, so they can decide whether it is the page they want.
• Unique where it matters: Pages in the same site should have different titles. Titles for steps in a process should say which step.
• Single-page apps: When a view changes without a page load, update the title so that it reflects the current view.
• Documents: PDF files should have a document title as well.
• Link text and title: A link and the title of the page it opens should match or be very close. This helps 2.4.4.
• Out of scope: The main heading of the page is 2.4.6. The language of the page is 3.1.1.

Who does it affect?

Screen reader users, who hear the title first when a page opens. People who have several tabs or windows open and need to find the right one. People with cognitive or memory difficulties, who rely on a clear title to confirm where they are. People using bookmarks, history or search results to find pages again.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Clear page titles are part of "operable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 2.4.2 by reference and turns it into separate clauses for each kind of ICT.

In EN 301 549 V3.2.1 the software row for this criterion is marked void. Check whether V4.1.1 changes that. Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 2.4.2 is the same in WCAG 2.1 and 2.2.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. A specific, descriptive title

Put the page-specific part first and the site name last.

<title>Home</title>

<title>Order confirmation | Example Shop</title>

2. A missing or empty title

A page without a title is announced by its URL or file name.

<head>
  <meta charset="utf-8">
</head>

<head>
  <meta charset="utf-8">
  <title>Contact us | Example Shop</title>
</head>

3. The same title on every page

If every page is called the same, users cannot tell them apart in tabs or history.

<title>Example Shop</title> <!-- on every page -->

<title>Running shoes, page 2 | Example Shop</title>

4. Steps in a process

Say which step the user is on, and mention an error if the page shows one.

<title>Checkout</title>

<title>Payment, step 3 of 4 | Checkout | Example Shop</title>
<!-- After a failed submit: -->
<title>Error: payment failed, step 3 of 4 | Example Shop</title>

5. Single-page application views

Update document.title when the route changes, and tell assistive technology about the change.

router.afterEach(() => { /* title never changes */ });

router.afterEach((to) => {
  document.title = `${to.meta.title} | Example Shop`;
  // Move focus to the main heading so screen readers announce the new view
  document.querySelector("h1")?.focus();
});

6. PDF documents

Give a PDF a real title and make viewers show it instead of the file name.

Title: scan_0042.pdf

Title: Annual accessibility report 2026
Viewer preference: DisplayDocTitle = true

Code examples for mobile

In native apps each screen needs a title for the same reasons. The screen title appears in the navigation bar and is announced when a screen reader moves to a new screen. In EN 301 549 V3.2.1 this row was void for software, so treat it as good practice.

iOS (SwiftUI)

import SwiftUI

struct OrderConfirmationScreen: View {
    var body: some View {
        NavigationStack {
            OrderSummary()
                // Avoid: .navigationTitle("") or a title shared by every screen
                .navigationTitle("Order confirmation")
                .navigationBarTitleDisplayMode(.inline)
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.material3.*
import androidx.compose.runtime.Composable

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun OrderConfirmationScreen() {
    Scaffold(
        topBar = {
            // Avoid: an empty title or one shared by every screen
            TopAppBar(title = { Text("Order confirmation") })
        }
    ) { padding ->
        OrderSummary(padding)
    }
}

How to test

• Read the tab: Open the page and read the browser tab. Does the title describe the page?
• Compare pages: Open several pages of the site. Are the titles different, and do they match the content?
• Use a screen reader: Load a page and listen to what is announced first. Is it the title, and does it make sense?
• Check dynamic views: In a single-page app, change views. Does the title change with each view?
• Check steps and errors: Does the title of a multi-step form say which step it is, and does an error page say so?
• Check PDFs: Open the document properties. Is the title meaningful, and does the viewer display it?
• Check mobile: Does each screen have a title that matches its content?
• Use a checker as a starting point: Automated tools find missing and empty titles, but cannot tell whether a title is meaningful.

Common mistakes

• "Untitled", "Home" or "Page 1" everywhere: The classic failure (F25).
• The site name only: The same title on every page.
• A title that is a file name or URL: Typical for PDFs and unlabeled pages.
• Putting the site name first: Tabs get narrow and the distinctive part is cut off.
• A title that never changes in a single-page app: Users cannot tell that the view changed.
• A keyword-stuffed title: Good for neither users nor search engines.
• Forgetting the error state: A form page that reloads with errors should say so in its title.
• A title unrelated to the heading: The title and the main heading should agree.

Sources

• Understanding SC 2.4.2: Page Titled (W3C), opens in a new tab
• H25: Providing a title using the title element (W3C), opens in a new tab
• F25: Failure of Success Criterion 2.4.2 due to the title of a web page not identifying the contents (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.