2.4.2 Page Titled
- Level A
- Operable
- Since WCAG 2.0
Summary
The page title is the first thing a screen reader announces when a page loads, and it is what everyone else sees in the browser tab, the window list, the history, bookmarks, and search results. For a screen reader user with fifteen tabs open, titles are the only way to tell them apart without visiting each one. For people with cognitive disabilities, a clear title confirms they have arrived where they intended. This criterion asks for one thing: every web page must have a title that describes its topic or purpose.
The auditor's mental model is simple: read the title of every page and every distinct state, and ask whether someone who could see nothing else would know what the page is for. A good title identifies the specific page first and the site second ("Order history, ACME Store", not "ACME Store, the home of great deals, order history"). Identical titles across different pages fail in practice, because a title shared by every page cannot describe any particular page's topic. Placeholder titles ("Untitled document", framework template leftovers) fail outright.
Official wording
Web pages have titles that describe topic or purpose.
EN 301 549 mapping
- Web pages
- Clause 9.2.4.2
- Software and native apps
- No software requirement: the corresponding chapter 11 clause is void in the standard.
Clause 9.2.4.2 applies this criterion to web pages unchanged. For software the standard declares the corresponding clause void, so native apps carry no mandatory equivalent: software product names are trademarked and cannot be required to be descriptive. Non-web documents keep their own titling requirement in the standard's document chapter.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Read the browser tab on every page in the audit sample. That is genuinely most of the test. For confirmation, open developer tools and check document.title, or inspect the title element in the head; there should be exactly one, it should be non-empty, and it should name the page's topic or purpose. Check that the distinguishing part comes first: front-loading matters because tabs truncate and screen readers announce the title from the beginning.
Single-page applications are the modern classic failure. Load the app, then navigate through several routes without a full page reload and watch the tab: if the title never changes, every "page" in the SPA shares one title and each route fails to describe its own topic. Also exercise meaningful states within a page: a search results view, a checkout step, or an error state reached by URL should each carry a title that reflects it.
The other failures are older but still everywhere: "Untitled document" from an editor, template leftovers like a framework's default app name, a bare domain name as the title, or a marketing strapline repeated on every page. A title does not need to match the on-page H1 word for word; it needs to describe the same topic.
iOS
The European standard declares this criterion void for software: a software product's name is a trademark, and the standard cannot require a trademarked name to be descriptive. So there is no mandatory equivalent of 2.4.2 to grade against native iOS screens. Note the boundary, though: non-web documents such as PDFs shipped or displayed by the app keep their own titling requirement in the standard's document chapter, so a PDF with no document title is still a finding, just not a software one.
As guidance, apply the good practice anyway, because the user need is identical: people moving through an app still need to know which screen they are on. Check that each screen sets a clear navigation bar title, and run VoiceOver while navigating: on a screen change VoiceOver should announce something that identifies the new screen, which usually comes from the navigation title or the first focused element. Screens with no title and an ambiguous first element leave VoiceOver users guessing. Record these as good-practice recommendations, or file the underlying defect under whichever criterion actually captures it (a modal whose purpose is never exposed to assistive technology is typically a naming or structure finding, not a 2.4.2 one).
Android
The same void applies on Android: the European standard has no software equivalent of this criterion, for the same trademark reason, and PDFs or other documents bundled with the app fall under the standard's document chapter instead.
As guidance, check screen titling the way the platform expects it. Each activity or destination should present a visible, descriptive title (app bar title, or a pane title such as accessibilityPaneTitle on the root of a fragment or Compose screen). With TalkBack running, navigate between screens: TalkBack announces window and pane titles on navigation, so a well-titled screen is announced as you arrive and an untitled one produces a silent or generic transition. Silent transitions between visually distinct screens are the Android failure spot to note. Grade them as good-practice recommendations or under the criteria that govern names and structure, not under 2.4.2.
Pass and fail examples
Passes:
- A product page titled "Wireless keyboard K380, ACME Store": the specific topic is front-loaded and the site name follows.
- A documentation site where every page's title is the article name plus the manual's name, each one unique and descriptive.
- A single-page application that updates
document.titleon every route change, so "Inbox", "Settings", and "Profile" each show their own tab title. - A search results page titled "Search results for 'invoices', ACME Docs": the title reflects the state the user is in.
- A title of "ACME Store, order history": site name first is weaker practice, but the title still describes the page's topic, and this criterion does not mandate word order.
Fails:
- Every page on the site is titled "Home" or just the company name: no page's topic is described.
- A page titled "Untitled document" or "New page 1": placeholder text describes nothing.
- A template leftover such as a framework's default application title shipped to production.
- A single-page application whose title is set once at load and never updated, so every route shows the same tab title.
- An empty
titleelement, or notitleelement at all.
Not a fail under this criterion:
- A missing or badly structured on-page heading: heading markup is graded under SC 1.3.1 Info and Relationships, not here.
- A visible heading that is vague or misleading: the quality of headings and labels belongs to SC 2.4.6 Headings and Labels.
- A title that does not repeat the H1 verbatim: the two serve different jobs, and 2.4.2 only requires that the title describe the topic or purpose.
- An iframe without a useful
titleattribute: that is an accessible-name finding on the frame, graded under SC 4.1.2 Name, Role, Value, not a page title finding.
Commonly confused with
- SC 1.3.1 Info and Relationships. The page H1 is not the title element. Whether headings exist and are marked up as headings is a structure question under 1.3.1; 2.4.2 is only about the document title announced in the tab and by the screen reader on load.
- SC 2.4.6 Headings and Labels. "This heading does not describe the section" is a 2.4.6 finding. Auditors often file a vague H1 under 2.4.2 because both criteria talk about describing topic or purpose; keep them separate, one grades the title element, the other grades visible headings and labels.
- SC 4.1.2 Name, Role, Value. Untitled iframes and unnamed dialogs feel like "untitled page" findings but are accessible-name defects on components, not document titles.
- SC 3.1.1 Language of Page. Both are checked in the
headwithin seconds of each other, which is the only reason they get conflated: 3.1.1 grades thelangattribute, 2.4.2 grades thetitleelement.
How AUDITSU tests this
AUDITSU's audit walkthrough asks the page title question on every screen in the sample: read the tab title (with the screen reader confirming what is announced on load), judge whether it describes this page's topic or purpose, and note whether it is distinct from the other pages you have already graded. For single-page applications, the walkthrough has you re-check the title after in-app navigation, which is where the common failure surfaces. Each answer records a pass, fail, or not applicable result per screen with the evidence attached, so a site-wide duplicate-title problem shows up as a consistent pattern across screens rather than one vague finding.
On native app screens, where the European standard declares the criterion void for software, the walkthrough marks it accordingly and routes screen-title observations into good-practice recommendations instead of conformance failures.
For the full guided workflow, see the audit platform.