顧客不用滑鼠，能否選到預約日期？

先釐清預約任務，再挑日曆

選日工具的價值，取決於顧客能否完成其後的預約。診所、維修店或課程主辦者，可能要顧客選日期、時段、分店及服務長度；日曆亦可能標示不開放日期、公眾假期或截單時間。先寫清顧客選日前必須知道甚麼：以哪個時區計算、最早可預約哪天、週末是否營業，以及選中日期是正式確認還是只用來搜尋時段。這些都是要用文字說明的服務規則。漂亮的月份格子不能替公司解釋未寫出的規則；控制項做得易用，也不能彌補錯誤的可預約量計算。

W3C 的 WCAG 鍵盤準則要求網頁功能可經鍵盤介面操作，並列出只適用於本質上依賴移動路徑輸入的例外。相關技術文件建議先列出頁面所有功能，再逐項用鍵盤檢查。對預約日期而言，按 Tab 到日曆圖示只是起點。顧客還要能開啟、移動日期、分辨目前焦點與已選日期、選取或取消、離開控制項，最後提交有效預約。任何一步只准用滑鼠，任務仍然受阻；後面的提交按鈕可用鍵盤，不能彌補月份格子只接受點擊。

設計可從符合服務需要的最簡單輸入方式開始。W3C 表單教學指出，HTML 日期欄位可利用瀏覽器的日期處理功能；較舊瀏覽器則可能顯示普通文字欄位。原生控制項可減少小團隊自行維護焦點及按鍵邏輯，但仍須在顧客實際使用的瀏覽器與輔助工具上測試顯示和操作。如預約規則需要更複雜的自訂日曆，適用時也應保留清楚的日期輸入途徑，並寫明兩者如何互動。選哪套元件庫是實作選擇；驗收重點是顧客能否完成真實預約。

開啟、移動及關閉都要可預期

若用自訂彈出日曆，開啟按鈕應有明確名稱，例如「選擇預約日期」；輸入格式提示也應連到欄位，讓輔助工具讀出。W3C 的日曆對話框示例包含日期欄位、開啟按鈕及對話框內的日曆。有有效日期時，開啟後焦點會落在該日；沒有時，示例聚焦今天。示例亦示範在格子移動、轉月份及年份、選取日期，並以 Escape 關閉。它只是示意做法，不應直接照抄作正式產品。W3C 特別提醒，部分瀏覽器與輔助工具組合仍有支援差異，流動裝置尤其要實測。

不要讓顧客靠碰運氣猜按鍵。若用格子模式，方向鍵可在日期間移動，Tab 可轉到日曆其他控制項；畫面上一句簡短指示，便能說清這套操作。焦點日期要有清晰可見標記，已選日期要另有辨識方式；不可預約日期不能只用另一種顏色表示。不能預約的日子，也不應直到最後提交才告知。翻到另一月份後，新月份及年份應讓屏幕閱讀器能得知。關閉日曆時，焦點須回到合理位置，並以文字確認剛選的日期。

能退出與能進入同樣重要。顧客應可取消而保留原有值、跳到下一個欄位，稍後回來改日期。測試欄位空白、已填有效日期，以及輸入無效文字時開啟日曆的情況。若無效值令格子跳到意料之外的月份，顧客可能失去方向。非模態彈窗不應困住 Tab；模態對話框也不應讓背景控制項仍可操作而令人混亂。焦點細節要視乎選用元件，但實際任務必須容易理解，且可返回修改。

把可預約規則說清楚

某天是有效曆日，不等於該天仍可預約，兩種判斷應分開。如果分店星期一休息，選日前就標示不可選，並在附近解釋原因。若可預約情況隨服務種類或員工而變，修改條件後要更新選項，並提示原選日期可能需要重選。顧客轉換分店時，不宜暗中清走已選日期；應說明哪些資料改了，以及下一步到哪個欄位。最終提交時，伺服器仍須按最新名額核對，因為顧客填表期間，最後一個時段可能已被別人預訂。

W3C 表單指引建議清楚標示必填欄位、合理容納不同輸入格式，並在用戶端提示之外於伺服器再次驗證。香港預約頁應明寫日期顯示格式及時區，不應假設每名顧客都把 03/04 看成同一天。如容許手動輸入，要決定斜線、連字號及前置零如何處理，驗證後才轉成沒有歧義的儲存日期。拒絕日期時，應說清是格式錯、日子不存在，還是服務當日已滿。保留其他已填答案，讓顧客只修正該項，不必重新開始；這是日期與可預約規則的具體補救。

例如顧客為香港分店選了星期六維修時段，日曆顯示星期六可約，但下一步選的技師只在平日工作。系統應在確認前阻止不相容組合，或解釋衝突並提供可選日期，同時保留顧客聯絡資料。使用屏幕閱讀器的顧客返回改日期時，應聽到目前已選日子及新可選日期。如分店有截單時間，也要先寫明所用時區和規則，不要等顧客試了被排除的日期才知道。例子中的星期六只是說明情境，不代表任何商戶實際有名額。

按真實輸入方式驗收全程

驗收可先完全不用指標裝置，從預約頁開始用 Tab 到日期欄位，開啟日曆、移到另一週及月份、選一天、再改一次，並試取消後完成預約。之後用屏幕閱讀器，以及顧客可能使用的流動裝置或外接鍵盤重做。記下瀏覽器與輔助工具組合；在一個組合成功，不等於所有環境都適用。W3C 的示例亦明言，正式使用前須用輔助工具測試。請測試者說出自己以為焦點在哪一天、已選哪一天，而不只看按鍵後畫面有否變動。

測試要包括容易出錯的狀態：月尾、跨年、剛被訂滿的日子、停業分店、手動輸入無效日期，以及送出前名額已變而被伺服器拒絕的預約。確認錯誤有指出欄位、顧客能修正，其他答案仍保留。放大畫面後，彈窗及操作按鈕也須可到達。若服務有英文和繁體中文版本，兩者的操作指示與狀態提示都要核對。這是一份產品驗收建議，不代表跑過一次測試就取得 WCAG 符合性認證。

老闆可要求開發者只用鍵盤示範一次正常預約及一次失敗後修正，並展示已選日期如何被讀出和更改。把情境保存為可重跑的驗收個案，以便日後修改名額規則或日曆元件時再測。亦要指定誰維護分店停業日和截單時間，以及顧客找不到可約日期時由誰回應。技術可以準確顯示並讓人到達選項，背後的服務時間仍由企業負責。真正完成的是顧客明白、能修改並成功提交的預約，不是頁面上出現了一個日曆元件。

若自訂日曆到上線前仍未通過驗收，團隊須有替代決定：可先提供有標籤、能驗證的日期欄位，延後彈出日曆；或改用較簡單的原生控制項，再重測完整流程。臨時方案應記錄已測的瀏覽器及輸入方式，並用文字保留預約規則。不可把難用的日曆放在顯眼處，卻把可用的替代欄位藏得難以發現。若日期會影響價錢或取消期限，最終確認前要展示後果，並讓顧客容易回頭修改。確認通知應重述最後日期、時區、分店及服務，方便顧客察覺選錯。客服也須有清楚更正程序，不應叫顧客再次重做無法操作的步驟。日曆是服務預約的工具，不能倒過來限制顧客。