先寫清楚問題才畫星
五個星形本身沒有說明顧客正在評價甚麼。先訂出單一題目和時間範圍，例如「剛完成的取貨體驗」，再界定一分與五分各代表甚麼；若量表不是滿意程度，更要直接寫明。英文及繁體中文頁面都應在控制項附近展示題目及分值含意。若容許不作答，初始狀態要保持未選，並告訴顧客可以跳過；若必須作答，應在填寫當刻解釋原因，不要到提交後才突然阻止。W3C 對標籤及指示的說明，重點是讓使用者知道欄位要求；星形圖案只是視覺提示，不能代替清楚的問題和選項文字。這項設計決定應先由業務負責人確認，開發者才有準確內容可以實作。
一個答案使用一組單選欄位
五個離散分值適合先考慮原生 radio 單選欄位，以 fieldset 和 legend 表示整組問題。每個選項都要有可見文字，例如「一分／五分：非常不滿意」，而不是只放一顆星。五個 radio 共用同一欄位名稱，各自有不同的提交值，瀏覽器便只會送出已選的一項。星形可以放在標籤內作輔助裝飾，但實際欄位仍須可由鍵盤及輔助科技操作。W3C 的評分單選示例展示了這個互動模式，同時明言其自訂 ARIA 程式只是示範，不能原封不動搬到正式網站。若團隊改用自製圖形，就要自己承擔命名、選取狀態、焦點及鍵盤行為的實作與測試。
讓焦點及選擇分得清楚
鍵盤使用者應能以 Tab 進入評分組別，知道目前選了哪一分，以預期的單選方式更改，再順利離開，不會被困在五個圖案之間。W3C 的 radio group 模式說明方向鍵可在選項間移動、空白鍵可選取焦點所在選項；原生瀏覽器在某些細節可能不同，因此應測試實際採用的做法，不要對所有裝置承諾完全一樣的按鍵結果。焦點外框在已選和未選狀態都要看得清楚。滑鼠懸停不能是唯一的預覽方式，指標離開後已選分值仍要清晰。控制項取得焦點不應立即提交整份表格。若業務想在選分後即時送出，先評估顧客能否檢視及更正選擇。
兼顧觸控、放大及對比
星形看起來很大，真正可按的範圍卻可能很細。可見標籤及其對應欄位應形成易於手指點選的區域，選項之間留有合理距離，避免按到相鄰分值。要在直向窄屏手機及瀏覽器放大情況下測試；說明文字換行時，不可與所屬分值分離。已選、懸停和焦點狀態不能單靠顏色區分，否則單色或強制高對比顯示可能看不出填色差異。啟用高對比模式時，原生單選標記或同樣清楚的外框仍應保留。提交後及返回表格時，原先選擇也應保持可辨。這些驗收項目關乎顧客真正能否操作，而不是只看設計稿是否整齊。
兩種語言要保留同一量表意思
英文的「good」與中文的「滿意」未必代表同一程度。應先把五個分值作為整體量表撰寫，再請熟悉本地語境的人並排閱讀兩種版本。中間一分究竟代表中立、好壞參半，還是一般，也要作明確決定，並在介面、儲存資料及報告中保持一致。不要機械翻譯字面，卻把語氣強弱改掉。顧客在任一語言頁面選第三分，理應回答同一條問題。若評分可跳過，「沒有回答」必須與中間分值分開儲存；把兩者都記成零或三，日後便無法正確解讀。顯示語言可以變，內部穩定分值與題目版本則應可追溯。
演練一宗實際填寫
假設顧客取貨後收到一題「請評價剛才的取貨體驗」，介面標明一分是非常不滿意、五分是非常滿意，初始沒有預選答案。顧客在手機按下第四分的文字標籤，畫面持續顯示「四分／五分：滿意」。鍵盤測試者以 Tab 進入同一組欄位，按單選控制的方式改為兩分，再移到意見文字欄；表格不應在選分時自動提交。使用屏幕閱讀器的人應聽到整組問題、每個分值，以及哪一項已選。若顧客改選三分，提交資料及確認畫面也必須顯示三分。這個簡單演練能在上線前找出標籤按不到、狀態悄悄改變及意外提交等問題。
誠實處理漏選及無效值
若評分可選填，留空就是有效回應，表格應可繼續。若必填，漏選時要用文字指出哪一組欄位有問題，並讓用戶返回該處；W3C 對錯誤識別的指引要求系統自動發現錯誤時，以文字說明出錯項目與問題。不可為了避開驗證而偷偷預選中間分值。伺服器要只接受已定義的量表值，並區分「沒有作答」和「傳入格式錯誤」。若顧客可修改先前評分，儲存前要顯示哪個答案會被取代。對匿名問卷，亦應交代評分是只作匯總還是與交易連結；介面文字須符合真正的資料處理方式，不能因為頁面沒有姓名欄就默認宣稱匿名。
在正式頁面驗收控制項
驗收應在真正準備推出的頁面，以滑鼠、鍵盤、觸控、屏幕閱讀器及高對比模式逐一操作，英文與繁體中文版本都要測。核對初始狀態、五個選項、改選、留空、驗證錯誤、提交及返回修改。應檢查送往伺服器的實際值，不能只憑畫面上亮起幾顆星推斷資料正確。窄屏手機及放大文字後，標籤可能換行，更需要重測。W3C 的示例可用來理解模式，但該頁明確提醒程式不是可直接用於正式環境的保證，某些裝置組合或有支援差異。最直接的推出標準是：每名測試者都能說出題目、辨認當前選擇、更改分值，並確認已儲存答案，無須靠猜顏色或數星星。
先判斷評分是否合適
數字量表只有在商戶知道如何使用答案時才有價值。若員工真正需要知道取貨有否延誤，一條直接的是非題及意見欄，可能比星級更能協助處理。若想快速了解整體感受，則要解釋分值，並容許顧客補充背景。顧客尚未收到貨便要求評價送貨質素，時機本身已不合理。推出前應訂明何時發問、評價範圍是甚麼，以及答案可否更改。先解決這些業務問題，才不會做出一個技術上可操作、實際上卻只收集含糊數字的漂亮控制項。
不要把輸入欄與平均分展示混淆
輸入欄要求顧客選一個值，平均分展示則是報告既有回應；兩者需要不同語意。平均分旁的星形圖應配上可閱讀的分數、量表及在適當情況下的回應數，不應像可編輯欄位般取得鍵盤焦點。相反，評分輸入欄必須有真正可操作的選項及已選狀態，不能只顯示「四顆星」文字。介面應分清「你的評分」與「顧客平均評分」。若商戶公開展示評分，審核及刊登政策是另一項編輯決定。本文的驗收重點是單一顧客能否清楚知道自己選了哪一分，再有意識地提交。
保存簡潔的驗收結果
每種測試組合只需記下瀏覽器、裝置或輔助科技、語言、操作和觀察結果。有效紀錄可以是：測試者以鍵盤進入未選的評分組、選第四分、看到或聽到第四分，並確認伺服器收到數值四；單寫「已檢查無障礙」無法重做。另要加入一項反例，例如必填時留空提交，確認文字錯誤指回同一條問題。視覺設計更改後也應重測，因為隱藏原生欄位或調整標籤位置，可能破壞原先通過的互動。紀錄應幫團隊找到具體修正，而不是宣稱所有裝置組合完全相同。
推出前核對
- 問題及每個分值都有可見標籤
- 鍵盤、觸控及屏幕閱讀器使用者均可選擇及更改評分
- 未回答與中間分值分開處理
