Decide the main language of each page
A page can contain excellent English and Traditional Chinese copy yet still be hard to listen to when its language is not identified in the document. W3C's WCAG 2.2 criterion 3.1.1 asks that the default human language of each web page be programmatically determinable. The purpose is practical: a screen reader can choose pronunciation rules, and a browser can process text more appropriately. A visible “English” or “中文” switch does not itself tell assistive technology what language the current page uses. The document's language information has to match the copy being delivered.
For separate English and Chinese URLs, decide the predominant language of each rendered page and set the HTML document language accordingly. If the Chinese edition contains English product names, it is still normally a Chinese page when most surrounding content is Chinese. W3C explains that on a page using several languages, the default is the language used most; if use is equal, the first language can be chosen. Do not copy the English template's language value into every localized page. A content-management toggle can change visible strings while accidentally leaving a stale document language.
The decision should be made on the final rendered page, not only in a design file. Check the page source or browser developer tools for the language on the root HTML element after switching editions and after a direct visit to each URL. Also test the site header, navigation, form labels, status messages and footers: translated article text does not compensate for an English-only surrounding interface that dominates the page. A release checklist can name the expected language for each route so a later template change does not silently reverse it.
Mark real changes inside the page
Criterion 3.1.2 addresses passages or phrases in another language and is a Level AA criterion. A Chinese service page may include a full English eligibility sentence, a bilingual button, or an English instruction reproduced for a customer. Those are different from a borrowed technical term in an otherwise Chinese sentence. The page's default language applies unless the changed passage is identified in markup. Put language information on the element that actually contains the different-language text, rather than hoping punctuation or a visual font change will communicate it.
W3C's explanation includes exceptions for proper names, technical terms, indeterminate language and words assimilated into surrounding speech. This matters in Hong Kong business copy: a brand name, model code or common technical term does not automatically need a separate language marker every time it appears. Apply editorial judgment to whole phrases and meaningful switches, with attention to whether the change affects pronunciation or understanding. Overmarking every acronym creates a noisy and fragile template; ignoring a complete English paragraph on a Chinese page loses information that assistive technology can use.
A language switcher deserves its own review. The visible link name may be written in the destination language: “English” on a Chinese page or “繁體中文” on an English page. W3C gives examples of language names marked with their own language. Check whether the accessible name is clear when links are listed out of context, and whether selecting the link loads the edition promised. If the site's route changes but the document language, page title or main content stays stale, the switch is misleading even if the visible control looks correct.
Test a real bilingual journey
Imagine a Hong Kong clinic's appointment information page with a Chinese edition and an English edition. The Chinese page explains opening arrangements in Chinese, contains one English sentence copied from a consent notice, and links to the English edition. The editor should first confirm the Chinese page's root language, then identify the full English sentence as an English passage, and inspect the language-switch link. The English edition needs its own root language and a corresponding check for any Chinese passage. This is a worked example of page behaviour, not a claim about a real clinic.
Walk the page using a keyboard and a screen reader configuration that supports the relevant languages. Listen to the page title, heading, English passage, navigation link and any form messages. Then inspect the underlying language attributes, because W3C warns that some assistive-technology combinations flatten accessible names and may not audibly switch despite correct markup. A speech test is useful evidence about a particular combination; it is not a universal compliance verdict. Record browser, screen reader, speech voices and page build when logging a defect so another tester can reproduce it.
Test content that appears after the initial page load as well. An appointment confirmation, validation message or modal may be inserted by a script after the root language was set. It still inherits the document language unless marked otherwise. A Chinese confirmation inside the English route needs the same editorial and markup decision as any static paragraph. Review email or PDF output separately rather than assuming the web page's attributes travel with exported content. The goal is that each delivered artefact tells its reader what language its text uses.
Put language into the release process
Give each page template a language expectation, then let content editors flag exceptions within their text. Developers can implement the root HTML language and a safe way for editors to mark genuine foreign-language passages; editors can verify the rendered result and the wording. A localization review should compare content completeness as well as language metadata. For example, a Chinese route with an untranslated English error message is a content gap, not a reason to label the whole page English. A correct language code cannot repair missing or inaccurate translation.
Treat the language code as an editorial fact tied to the delivered copy. If a page changes from bilingual to mostly one language, review the default again. If an interface component is reused across languages, confirm it does not hardcode the wrong attribute. Include direct URL visits, navigation from the switcher and post-submission states in acceptance testing. A browser inspection tool can catch a missing root attribute, while a human reader and assistive-technology test can spot confusing switches. These checks complement one another because they observe different parts of the journey.
Begin with one high-use bilingual page. Write down the expected main language of each edition, identify any full phrases in the other language, and inspect what the browser actually rendered. Fix the template or content entry that causes a mismatch, then retest both editions and the switch between them. That bounded exercise gives a team a repeatable acceptance pattern for future pages. W3C's criteria support the language-identification requirements; whether a particular voice sounds natural remains dependent on the browser, screen reader and speech engine being used.
Write a usable acceptance note
A small acceptance sheet can list the route, expected predominant language, actual root language, passages that intentionally switch, and the result of navigating to the other edition. Include interactive text, because a form error, menu or dialog can be more consequential than an article paragraph. For each mismatch, note whether the cause is untranslated content, a wrong HTML attribute or an assistive-technology behaviour observed only in one setup. These require different fixes. The developer needs to know which element or template to change; the editor needs to know which copy is missing or belongs to another language.
Do not turn the test into a promise that all speech engines will pronounce every proper name identically. W3C explicitly acknowledges variation in speech technology and exceptions for certain names and terms. The acceptance target is more concrete: correct programmatic language for the page and meaningful changes, a link that takes the reader to the expected edition, and copy that remains understandable in that edition. If a reader still reports a confusing phrase after those checks pass, investigate the actual phrase and device combination. That feedback can guide a wording change or a narrower markup adjustment without rewriting the whole language system.
Prioritise pages where a language mistake can change a decision: booking instructions, eligibility, consent explanations and error recovery. For each, compare the visible language with the document language after a direct link, a switch and a submitted form. Have a person who can read the relevant language review whether a marked passage is actually a coherent phrase, rather than trusting an automated detector to classify every product name. Then test at least one real assistive-technology combination and keep the device details. This gives the business a practical release sample without claiming that one test represents every reader. Keep the sample in the release record so a future content or template update can be compared against the same journey, including the language switch and the final confirmation.
Checks before release
- Does each rendered URL declare its actual predominant language?
- Are meaningful language changes marked in the content?
- Have both editions and the switcher been tested after rendering?
