為何同一按鈕會有兩個名稱
顧客看見按鈕寫着「查詢空檔」，便用語音控制說出這幾個字，按鈕卻沒有反應。原因可能是畫面上的字與網頁提供給輔助技術的名稱不同。程式若以 aria-label 把按鈕命名為「搜尋時段」，語音軟件可能依據後者辨識，而顧客自然只會照畫面讀前者。W3C 的「標籤包含於名稱」準則規定：介面元件若有文字或文字圖片作可見標籤，其無障礙名稱應包含畫面呈現的文字。讓可見文字放在名稱開首是較好的做法。這條準則針對已有可見標籤的控制項；它本身並非要求所有只有圖示的控制項都新增可見文字，但其他無障礙要求仍須處理。純看畫面的檢查很容易漏掉問題，因為兩個版本外觀完全一樣。文案更新後亦常出現：市場同事把「送出查詢」改成「索取報價」，隱藏名稱卻仍是舊詞。可見文字和程式算出的名稱應視作同一項內容決定，每次介面改動都要核對。
逐項檢查顧客真正使用的控制項
沿一條完整顧客路線，列出畫面上的按鈕、連結、表格標籤、分頁及選單項目。優先處理付款、提交資料、修改預約及選擇產品選項等重要操作。每個控制項記錄顧客當前語言看見的字，以及瀏覽器無障礙工具顯示的計算後名稱。後者是命名規則運算的結果，不能只看原始 aria-label 屬性。一般按鈕往往取自身可見文字作名稱；正確關聯的表格標籤也可為輸入欄命名。aria-label 或 aria-labelledby 可能覆蓋開發者原本預期的名稱，因此只讀原始碼並不足夠。動態狀態也要查：「加入購物籃」可能改為「已加入」，無障礙名稱卻留在舊狀態；切換中文頁後，可見字已翻譯，隱藏名稱卻仍是英文。重複按鈕需要足夠上下文區分，但補充文字仍應保留整句可見標籤。W3C G208 技術說明可把額外詞語放在可見文字之後；補充背景有時更適合放在描述，而非名稱。先找出真實不一致項目，才決定哪些文案需要改，避免全站盲目重寫。
以索取報價流程作例子
假設一家香港維修公司的報價頁讓顧客選家電類型、填地區，再按畫面上的「取得估算」按鈕。開發者昔日為了讓屏幕閱讀器明白用途，把 aria-label 設成「提交表格」。現在計算出的名稱是「提交表格」，顧客用語音說「點擊取得估算」便可能找不到按鈕。直接修正方法，是在「取得估算」確實描述操作的前提下，讓按鈕的可見文字成為名稱。若同頁有多個估算按鈕，需要加上服務類別作區分，名稱可以「取得估算」開首，再加補充詞；或把合適背景放進描述。具體方式須配合頁面互動測試。送出後，按鈕若改顯示「要求已送出」，計算後名稱及狀態亦應反映真正發生的事。公司只是收到查詢時，不能把它寫成「報價已確認」。這只是說明用例，並非真實客戶成果報告。驗收重點是英文與中文頁面都能用畫面顯示的詞語找到並啟動該控制項。
補充上下文時保留原字及次序
W3C 準則要求無障礙名稱包含畫面呈現的文字。其說明指出，為配合語音控制，大寫小寫及一般標點差異通常不是核心問題；把詞換成另一組詞則不同。G208 技術測試名稱是否包含可見標籤相同的字母及相同次序。因此畫面寫「儲存修改」、程式名稱卻是「更新個人檔案」，即使設計者認為兩者近義，也應處理。「儲存修改：送貨地址」較合適，因為名稱由顧客看得見的詞語開始。同頁有數個「更多」連結時，可能要在名稱後加相關項目，或在版面容許時把可見文字改得更具體；不應讓隱藏名稱完全變成另一句。aria-describedby 可以提供補充說明而不改變名稱的計算，欄位仍叫「送貨日期」，描述則交代可選日期。不過也不能用描述掩飾一個本來就含糊的操作。如果可見標籤本身會誤導，應先修正顧客看得到的字，再讓程式名稱跟上。
英文和中文逐一核對
雙語網頁可能英文版通過，翻譯後卻失敗。畫面「Choose plan」改成「選擇方案」，未翻譯的 aria-label 仍寫「Select subscription」；屏幕閱讀器或許仍可讀到某個名稱，但顧客看到的中文詞未必可用作語音指令。須在每個語言版本完成渲染後核對，因為計算出的名稱可能混合已翻譯按鈕、未翻譯的隱藏文字、附近標題或範本字串。兩種語言的決定含義應一致，但毋須逐字保持英文語序。中文可見文字若是「更改地址」，中文無障礙名稱便應按同一次序包含這四字，不必模仿英文句式。控制項若包含產品名稱或型號，應確認可見標籤與名稱都有同一識別資料；可行時再用合適輔助技術或使用者測試發音及辨識。單看程式不能宣稱所有語音軟件都識別成功，效果也受軟件及語言設定影響。團隊可以誠實記錄較窄的證據：計算後名稱包含可見詞語，指定測試環境能以該詞啟動控制項。
處理圖示、文字圖片及狀態變化
沒有可見文字的控制項，不能把這條準則機械套上去。「標籤包含於名稱」針對標籤中有文字或文字圖片的元件；只有圖示的控制項仍需按其他準則提供有意義的無障礙名稱。圖示旁若有文字，要先判斷文字是否標示同一個控制項，再確認計算後名稱包含它。宣傳圖片中的可讀文字若直接充當按鈕標籤，即使文字畫在圖內，也要算進去。普通文字可行時，盡量不用文字圖片，因為前者較易隨語言及狀態同步。動態控制項須反覆檢查：按鈕在「顯示詳情」與「隱藏詳情」之間切換，名稱要跟當下可見動作一致。按鈕暫不可用，也不應把名稱換成一段只在程式裏的解釋；不可用原因可在合適訊息或描述中交代。開始載入時，須測試可見字、名稱及狀態同時更新會否造成重複播報。轉換前、中、後都要清楚交代動作，伺服器尚未確認前不能暗示操作已完成。
建立可重做的上線檢查
中英文各選一個代表性頁面，從進入流程走到確認。對每個有可見標籤的控制項，記錄畫面詞語、計算後名稱、當前狀態及真正會執行的操作。名稱漏掉或打亂可見詞語，翻譯後留下舊語言，或狀態變了名稱未變，都要標記。修正造成覆蓋的來源，而不是再疊上一個新的隱藏標籤。之後用鍵盤及屏幕閱讀器檢查角色與上下文仍然正確。若有語音操作工具，就直接說畫面上的詞語，確認啟動預期控制項；同頁有多個相近按鈕時要逐一試。記下瀏覽器、輔助軟件、語言及結果，方便另一編輯者重做。自動檢查通過可作提示，但工具未必知道旁邊哪段文字才是真正的可見標籤，也不能判斷業務動作是否被如實命名。上線前應讓顧客看到的文字、計算後名稱及實際操作表達同一件事。設計、翻譯或共用元件有改動後要重測，因為它們都可能在按鈕外觀不變時改變名稱計算結果。
進行前先確認
- 每個有可見標籤的控制項，計算後名稱是否包含同一詞語？
- 翻譯或狀態改變時，名稱有否跟畫面文字同步？
- 在指定語音測試中，說出畫面詞語能否啟動正確控制項？
- 標籤是否如實描述操作結果？
