Headings must accurately preview page content

What it is

A page-heading content and task contract names the object or task people have reached and the main kind of content they can expect. It need not enumerate every module or use an identical string in every surface. The visible heading, browser or window title, and page name available to assistive technology should share a stable conceptual core. When object, step, filter, or state changes, the title separates stable identity from the dynamic qualifier needed for orientation.

Why it happens

A heading provides information scent before entry and orientation after it. People use it to decide whether to read and to confirm location across transitions, back navigation, tabs, and screen-reader navigation. A broad title cannot rule out wrong paths, a narrow one omits the main task, and a site name alone cannot distinguish pages. Dynamic content can also tempt products to place counts, names, and transient states in every title, creating visual churn, unrecognizable history, and repetitive announcements. A stable object or task plus a small decision-relevant state remains learnable while reflecting changes that alter page meaning.

Studying it

Run heading-prediction tasks: show a candidate heading, collect expected content and actions, then reveal the page and record surprises, wrong entry, orientation time, and backtracking. Cover empty, loading, error, forbidden, completed, and personalized-object states. Start keyboard and screen-reader tests from deep links and client-side transitions; inspect computed page name, meaningful focus, and whether the change is perceived. Interpret results by task and title version rather than using click-through as proof of an accurate contract.

Where it stops holding

Aggregations can use stable categories such as “Home” or “Dashboard” when nearby summary explains the range. A branded name can work with a descriptive subtitle. Brief loading, success, and error states need not replace the main heading; use a status region unless object, step, or permission changes the page's core meaning. Visible heading, document title, and accessible page name serve different contexts and need not be verbatim, but they cannot name different concepts. Accurate copy cannot repair a broken information architecture, permission model, or content scope.

Applying it

• Define stable page concept, main task, visible heading, document/window title, accessible page name, and allowed dynamic qualifiers for every route, including each qualifier's source.
• Lead templates with the object or task, then add a step, object name, or durable state only when needed. Do not inject rapidly changing counts, time, or background progress into the main heading by default.
• Synchronize page naming across SPA transitions, deep links, refresh, back, multiple tabs, and loading/empty/error/forbidden states. Follow platform focus or status-announcement patterns so assistive users do not remain in the old context.
• Validate by heading prediction, page inspection, and a paraphrase of current location and next step. If main content surprises people, revise the heading or scope; after dynamic changes, verify that history and return paths remain recognizable.

Related

• Same group: T2.02.2 Creative headings undermine predictability · T2.02.3 Labels must match the target page's heading
• Adjacent: G4.09.1 Page titles must reflect the current specific content, not repeat the site name · T3.01.2 Headings, lists, and code blocks carry the scan anchors
• Search terms: page heading contract · accessible page title · content prediction