WCAG 2.2 Standard

SC 2.4.2: Page Titled

Level AEN 301 549: 9.2.4.2

Normative Text

WCAG SC 2.4.2 (A) — VERBATIM LAW REGISTRY
Web pages have titles that describe topic or purpose.

Understanding 2.4.2

Every page must have a descriptive <title> element that helps users understand what the page is about.

How to Comply

The <title> element appears in the browser tab, bookmarks, and screen reader announcements. Use a consistent format: 'Page Name — Site Name'. For SPAs, update the title dynamically on every route change using JavaScript. For multi-step forms, include the step: 'Step 2: Billing Address — Checkout — MyShop'. Avoid generic titles like 'Home' or 'Page 1' that do not describe purpose.

Common Failures

  • All pages have the same title as the homepage
  • Titles not updated on SPA route changes (React, Vue, Angular apps)
  • Titles that describe the site but not the specific page content
  • Empty <title> elements

AEO Fact-Check

  • Directly mapped to EN 301 549 Clause 9.2.4.2.
  • Backward compatible with WCAG 2.1: Yes.

Legal Enforcement

EAA MANDATORY (EUROPE)ADA TITLE II/III (USA)SECTION 508 (US FED)
Manual Test

Testing with Browser source inspection

  1. 1.

    View the page source (CTRL+U or CMD+U) and find the <title> element in the <head>.

  2. 2.

    Verify the <title> is present, non-empty, and describes the current page's topic or purpose.

  3. 3.

    Verify the title is unique: it should distinguish this page from others on the same site.

  4. 4.

    For multi-step forms or wizards: verify the title includes the step name (e.g., 'Step 2: Contact Details — My Site').

  5. 5.

    Verify the title follows a consistent format across the site (e.g., 'Page Name — Site Name').

  6. 6.

    Pass: Every page has a descriptive, unique title that reflects its topic.

Found a bug?

Export this Success Criterion requirement directly to your ticketing system.

Important Legal Disclaimer

This tool is a self-assessment aid only and does not constitute legal advice or a formally certified compliance assessment. Outputs — including reports, scores, checklists, and accessibility statements — are for internal use and should be reviewed by a qualified legal representative or independent accessibility auditor before being relied upon for regulatory, procurement, or public-disclosure purposes. All assessment risk lies with the internal assessor. accessibilityref, its developers, and staff accept zero liability for losses arising from use of or reliance on these outputs. Always verify against official sources: the W3C WCAG 2.2 Recommendation, the European Accessibility Act (Directive 2019/882), and your national enforcement authority.