先定每頁主要語言
網頁的英文及繁體中文內容即使寫得準確，若文件沒有標明語言，以讀屏方式使用時仍可能難以理解。W3C 的 WCAG 2.2 成功準則 3.1.1 要求每頁的預設人類語言可由程式判定。實際作用是讓屏幕閱讀器選擇適當讀音規則，也讓瀏覽器更妥善處理文字。畫面上有「English」或「中文」切換鍵，並不等於輔助科技知道目前頁面用甚麼語言；文件語言資料須與實際提供的文案一致。
如果英文及中文有不同網址，應按每個實際輸出的頁面判斷主要語言，並在 HTML 文件上相應標示。中文版即使出現英文產品名稱，只要周圍主要內容是中文，通常仍屬中文頁。W3C 指出多語頁面以最常使用的語言為預設；若使用量相同，可選首先出現的語言。不要把英文範本的語言值直接複製到所有本地化頁面。內容管理系統可能已切換可見文字，卻留下舊的文件語言標示。
判斷要以最後呈現的網頁為準，不能只看設計稿。切換版本及直接打開每個網址後，都應在網頁原始碼或瀏覽器開發工具檢查 HTML 根元素上的語言值。頁首、導覽、表格標籤、狀態訊息及頁尾也要測試；單是文章已翻譯，不能抵銷佔據大量版面的英文介面。推出清單可為各條路徑列出預期語言，避免日後改範本時無聲地改錯。
標示頁面內真正的語言轉換
成功準則 3.1.2 處理頁面中使用另一語言的段落或詞組，級別為 AA。中文服務頁可能嵌入一整句英文資格說明、雙語按鈕，或供顧客參考的英文操作指示；這與中文句子中借用一個技術詞不同。如沒有額外標示，內容會沿用頁面預設語言。應在真正包含另一語言文字的元素上標記，不要以為標點或字體外觀能向輔助科技交代語言轉換。
W3C 的說明為專有名稱、技術詞、語言不明的字詞，以及已融入周圍語言的用語列出例外。香港商業文案常有品牌名稱、型號及通用技術詞，並非每次出現都必須獨立標示。編輯應按完整詞組及有意義的轉換判斷，留意是否影響讀音或理解。把每個縮寫都加標記，會令範本嘈雜且難維護；完全忽略中文頁中的整段英文，也會失去輔助科技可利用的資訊。
語言切換器值得獨立檢查。中文頁的連結可能寫「English」，英文頁則寫「繁體中文」，即以目的地語言寫出名稱；W3C 亦有為語言名稱本身標示語言的例子。應檢查連結在脫離上下文的清單中是否仍清楚，點選後是否真的到達所承諾版本。如果網址變了，但文件語言、頁面標題或主內容仍是舊版本，即使按鈕外觀看似正確，也會誤導使用者。
用完整雙語旅程測試
設想一家香港診所的預約資訊頁，分別有中、英文版本。中文頁以中文說明開放安排，包含從同意書引入的一句英文，並連至英文版。編輯先確認中文頁根元素的語言，再標示完整英文句子，最後檢查語言切換連結。英文版亦須有自己的根元素語言，若嵌入中文段落，便要同樣檢查。這是網頁行為的示例，不是對任何真實診所的描述。
應以鍵盤配合支援相關語言的屏幕閱讀器走完整頁，聆聽頁面標題、標題層級、英文段落、導覽連結及表格訊息。之後還要檢查底層語言屬性，因為 W3C 提醒，部分輔助科技組合會把可存取名稱壓成平面字串，即使標記正確，聆聽時也未必切換語音。語音測試只能反映該組合的體驗，不能單獨作為普遍符合標準的結論。記錄瀏覽器、屏幕閱讀器、語音及頁面版本，才方便重現問題。
初次載入後才出現的內容也要測試。預約確認、驗證訊息或彈出視窗可能由程式在設定根元素語言後插入；若無另行標示，它仍承接文件語言。在英文路徑中出現中文確認訊息，跟靜態中文段落一樣需要編輯及標記判斷。電郵或 PDF 輸出要另外檢查，不應假設網頁屬性會隨匯出內容保留。重點是每份交付給讀者的內容，都能表明文字所用語言。
把語言檢查納入推出流程
每個頁面範本應有預期語言，內容編輯再標出內文真正的例外。開發人員負責設定 HTML 根元素語言，並提供安全方法讓編輯標示外語段落；編輯則核對最後頁面及文字。網站本地化審核要同時比較內容是否完整與語言資料是否正確。例如中文路徑出現未翻譯的英文錯誤訊息，問題是內容缺漏，不是把整頁標為英文的理由。正確語言代碼也無法補救錯誤翻譯。
語言代碼應視為與已交付文案相連的編輯事實。若頁面由雙語改為以單一語言為主，要重新判斷預設語言；跨語言重用的元件，也要避免把舊屬性寫死。驗收時包括直接開網址、經切換器導覽及提交表格後的狀態。瀏覽器檢查工具能找出根元素漏標，人手閱讀與輔助科技測試則能發現令人困惑的轉換。各項檢查觀察旅程的不同部分，互相補足。
可以先選一頁使用量較高的雙語內容。記下各版本預期的主要語言，找出另一語言的完整詞組，並檢查瀏覽器實際輸出的結果。修正造成不符的範本或內容欄位，再測試兩個版本及其間切換。這個範圍清楚的小型演練，可形成日後頁面的可重複驗收方法。W3C 準則支持識別語言的要求；至於特定語音聽起來是否自然，仍取決於瀏覽器、屏幕閱讀器及語音引擎組合。
寫下可重複的驗收記錄
簡單的驗收表可列出網址路徑、預期主要語言、實際根元素語言、刻意轉換語言的段落，以及切往另一版本的結果。互動文字也要包括，因為表格錯誤訊息、選單或對話框，有時比文章段落更影響操作。遇到不符時，應分辨是內容未翻譯、HTML 屬性錯誤，還是只在某個輔助科技組合觀察到的行為。三者需要不同修正方法：開發人員要知道改哪個元素或範本，編輯則要知道哪些文字缺漏或放錯版本。
不要把測試變成保證所有語音引擎對每個專有名稱都發音一致。W3C 明言語音技術會有差異，部分名稱和術語亦屬例外。更具體的驗收目標是：整頁及有意義的轉換有正確的程式語言標示、連結能到達預期版本，以及該版本文案可理解。若完成這些檢查後，讀者仍反映某句難懂，便針對實際詞句和裝置組合調查。這類回饋可促成文字修訂或較小範圍的標記調整，毋須盲目改寫整套語言機制。
應優先檢查語言錯誤可能影響決定的頁面，例如預約指示、資格說明、同意內容及錯誤修正。每頁分別經直接連結、語言切換及表格提交後，比較可見文字與文件語言。請懂相關語言的人判斷被標記的內容是否真正的完整詞組，不要只靠自動工具替每個產品名稱分類。其後用至少一種實際輔助科技組合測試，並記下裝置細節。這樣有可執行的推出抽樣，同時不會聲稱一次測試代表所有讀者。把測試樣本留在推出紀錄內，日後更新文案或範本時，便可沿同一旅程比較，包括語言切換及最後確認訊息。
推出前檢查
- 每個實際頁面是否標示其主要語言？
- 內文中有意義的語言轉換是否已標示？
- 兩個版本及切換器是否已在輸出後測試？
