Can customers tell where they are on every page?

Start with the actual task

A visitor who opens a product page from a search result, follows a support link, and then starts an application needs to know what each page is for before reading every control. The browser tab, the first visible heading, and the page structure should tell a consistent story. A beautiful visual masthead cannot substitute for those signals. This is particularly apparent when several tabs share a brand name or when a screen reader announces a page before the visitor reaches its content. Map the pages in one real customer journey and write down the distinct job of each page.

W3C's explanation of WCAG 2.4.2 says a web page title should describe its topic or purpose. Treat that as an editorial decision, not merely an HTML property to populate. “Contact” could mean sales, order support, or a location directory; “Application” could mean a blank form, a review step, or a submitted receipt. Place the distinguishing task first, then add the business name where it helps recognition. In a bilingual site, give each language page a title in its own language. An English title on a Traditional Chinese form makes the tab less useful even if the visible page is translated.

A page title and its main heading do related work but are not interchangeable. The title identifies the whole page among browser tabs, history entries and assistive technology announcements. The visible main heading confirms to someone who has arrived that the content matches the link they chose. They may have slightly different wording: “Review your order | Shop name” in the tab and “Review your order before payment” on the page. Both should describe the same state. A heading that says “Welcome” while the title says “Payment failed” creates a costly contradiction at a consequential moment.

Choose one useful page level heading before styling subheadings. W3C's page structure tutorial explains that headings communicate how sections relate. A heading is not simply a larger font: it gives a screen reader user a way to scan the document and lets every reader see the argument's outline. Write headings that name decisions or content, such as “Delivery methods” and “What happens after submission,” rather than generic labels such as “More information.” Keep levels in a logical hierarchy. Visual size can be set with CSS without promoting a minor card title to the page's main heading.

Make the structure navigable

W3C's regions tutorial recommends the HTML main element for a page's main content and nav for navigation menus. This gives assistive technology a structural route past repeated site furniture. Identify the principal content that changes from page to page. A retail product page might have a site header, primary navigation, a main region containing the product decision, complementary stock or help information, and a footer. The main region should not be an empty wrapper while the product details sit outside it. Nor should a modal or embedded widget accidentally create a second competing main region.

A site can have more than one navigation region, but identical unnamed navigation landmarks make a screen reader's region list hard to use. Give each distinct navigation set a short purpose label, such as primary navigation and on-page contents. The label should describe the set, not repeat “navigation” needlessly. Keep the visible heading and accessible name aligned when one labels the other. A footer list of policies may be useful, but do not turn every collection of links into a new landmark. The goal is a small, predictable map that corresponds to what is visually present.

Consider a worked journey through a shop: a buyer opens a product page, checks delivery, then reaches order review. On the product page, the tab names the product and shop; the main heading names the product; a delivery section explains only that product's relevant options. On the order review page, the tab and heading identify the review state and the main region contains items, price, delivery and the final action. After submission, a confirmation page uses a new title and heading. This is an illustrative content map, not a claim about a live retailer or conversion result.

Dynamic pages need particular care because a route can change without a full browser load. When a customer moves from catalogue results to a product or from order review to confirmation, update the document title and main heading as part of the route change. Do not claim that changing the title alone automatically announces the new view to every assistive technology combination. Test the actual route, focus position and reading order on supported browsers and screen readers. The same expectation applies if a client-side filter changes the page's substantive purpose rather than merely refining a small region.

Review and maintain the page map

Build a short page inventory with columns for URL or route, customer task, document title in each language, visible main heading in each language, and the main region's contents. Review a representative product, empty result, validation error, review and confirmation state rather than only the happy path. Look for two pages whose titles are indistinguishable when the site name is removed. Also look for titles that describe a state no longer shown after a form submission or route change. Resolve these in copy and templates together; a spreadsheet alone cannot repair the rendered page.

Test without relying on the visual hierarchy. Open several journey pages in separate tabs and ask a colleague to identify each from its tab label. Then navigate by headings and by landmarks using the accessibility tools the team supports. The list should reveal the intended page, its main content, and useful sections in a sensible order. Tab through the page to see whether a keyboard user can get past repeated navigation and reach the main task. A machine check can catch missing elements, but human review must decide whether the words actually distinguish the decisions.

Repeat that exercise in Traditional Chinese. A literal translation may be technically present but vague or unnatural in a local buying journey. Compare “order submitted,” “order received,” and “payment completed” against the actual system state; they are not interchangeable promises. Ask someone who uses the Chinese interface to read titles and headings without the English beside them. If they cannot tell whether the order is final or what to do next, improve the wording before release. Avoid inserting private customer names or order details into browser titles that may appear in history, screenshots or shared screens.

Assign ownership at the template level so a new campaign or service does not inherit a generic title. The page author owns the task wording; the developer ensures the title, heading and region structure render in every state; the reviewer checks both languages in the live-like preview. Record exceptions explicitly, such as a legacy embedded page whose title cannot yet be controlled, with a repair owner. Revisit the map when routes are renamed or checkout stages change. The release decision is simple: can a customer identify the current page and reach its main task through both a visual and a structural route?

A useful exception check is a page with several legitimate tasks, such as an account dashboard. The title should identify the dashboard, while headings divide recent orders, saved details and support actions into recognisable sections. Do not try to cram every item into the browser title. On a single-purpose confirmation page, by contrast, put the outcome at the front of both title and main heading. This distinction keeps titles concise while preserving orientation. If the site has a persistent promotional banner, verify it does not appear as the first heading in the document outline. A user navigating headings should encounter the page task before optional marketing material. Record that requirement in the shared template, because otherwise the same banner error can be repeated on every customer page.