fixing-accessibility

fixing-accessibility 技能概覽

fixing-accessibility 技能可幫你在 HTML 可及性問題上線前先做檢查與修正。它特別適合設計師、前端工程師，以及處理 UI 變更的 AI agent，尤其是那些會影響鍵盤操作、螢幕閱讀器、表單、對話框與視覺狀態清晰度的變動。如果你需要 fixing-accessibility for UX Audit，這個技能會把粗略審查轉成聚焦的修補流程，而不是泛泛的可及性課程。

fixing-accessibility 實際會做什麼

這個 fixing-accessibility 技能會找出具體問題，例如缺少可存取名稱、鍵盤導覽失效、焦點處理不佳、對話框行為不正確、表單錯誤訊息不清楚，以及對比或狀態顯示有問題。它的核心價值不在於大範圍的 WCAG 理論，而是在於提供實用的檢視框架，抓出最可能阻擋真實使用者的問題。

最適合的情境與明確邊界

當你在新增或修改按鈕、輸入框、選單、分頁、下拉選單、彈出視窗，或只有圖示的動作控制時，最適合使用它。它較不適合完整的企業級可及性稽核、法規合規審查，或需要人工政策判斷的視覺設計評論。這個技能最強的地方，是用來修 UI 程式碼，而不是寫一份報告。

為什麼值得安裝這個技能

fixing-accessibility install 的最大優勢，是它會把 agent 的方向收斂到最小、最精準的修正，而不是重寫整個 UI。這讓它很適合用在正式程式碼庫中，因為你需要安全變更、具體到行的發現，以及快速反覆修補可及性缺陷。

如何使用 fixing-accessibility 技能

安裝並在情境中觸發

先在你的 skill manager 中使用 fixing-accessibility install，再在以 UI 為主的對話或審查中直接呼叫它。repo 內的標準用法是 /fixing-accessibility，用來把指引套用到目前討論；如果你想針對某個檔案做審查並取得具體發現，則使用 /fixing-accessibility <file>。請讓需求明確對準你正在修改的元件或畫面。

交給技能一個它能實際處理的任務

好的 fixing-accessibility usage 一定從具體目標開始，而不是模糊的「幫我檢查可及性」。你要說清楚改了什麼、放在哪裡，以及這個 UI 有什麼互動型態。強而有力的提示會包含 UI 模式、預期行為，以及任何修改限制。

範例提示：
/fixing-accessibility src/components/Modal.tsx Review for keyboard access, focus trap, aria labeling, and escape handling. Keep fixes minimal and preserve existing design.

先讀對的檔案

先從 SKILL.md 開始，因為它包含規則優先順序與互動模型。接著檢查元件或頁面檔案，再搭配附近的表單、對話框，或共用互動工具函式。由於這個 repository 沒有額外的規則、參考資料或 scripts，這個技能刻意保持輕量；因此主要收益來自把指引審慎套用到你自己的 codebase，而不是去找隱藏的 helper。

能提升輸出品質的工作流程

1. 先辨識互動類型：表單、對話框、選單、分頁、圖示按鈕，或隱藏內容。
2. 針對技能的優先類別，要求聚焦審查。
3. 每一項違規都要提供精確的程式片段或行號。
4. 要求最小化的程式碼層級修正，不要重做設計。
5. 修改後再跑一次，檢查鍵盤流程、標籤或焦點有沒有迴歸問題。

fixing-accessibility 技能 FAQ

fixing-accessibility 是用在 UX Audit 還是程式碼修復？

兩者都可以，但它主要是偏向修復導向的審查技能。若用在 UX Audit，它能幫你找出可及性阻礙，並轉成可執行的修正。如果你需要的是帶有嚴重度評分的敘述式稽核文件，可能還是要搭配更完整的審查流程。

這跟一般的可及性提示有什麼不同？

一般提示常常只會產出一份通用檢查清單。fixing-accessibility 技能則更窄、更偏操作層面：它會以固定順序優先處理可存取名稱、鍵盤操作、焦點管理、語意、表單錯誤、朗讀提示與對比。這種結構能幫助 agent 減少不相關的建議。

初學者可以用嗎？

可以。初學者通常最能受益，因為這個技能會告訴他們應該先看什麼，以及該怎麼做最小幅度的修正。主要限制是，他們仍然需要提供具體的元件或檔案；這個技能無法自己猜出哪個 UI 面最重要。

什麼情況下不該用它？

不要把它當成法規合規簽核、複雜可及性政策判斷，或需要專門輔具驗證的測試工具。當你想要的是大範圍重新設計建議，而不是針對既有 UI 程式碼做精準修補時，它也不適合。

如何改進 fixing-accessibility 技能

提供比「讓它可及」更具體的輸入

最好的結果來自明確點出元件、互動方式與使用者風險。例如，「Review DatePicker.tsx for keyboard navigation, focus return, and announced errors after validation」會比「fix accessibility」好得多。這樣能讓技能鎖定明確的失敗面，也比較不會產出表面化的結果。

要求證據，不只是建議

當你想得到有用的 fixing-accessibility guide 輸出時，請要求助理引用違規的精確程式片段或行號，簡短說明它為什麼重要，並提出最小可行的修正。這種格式不但更容易實作，也更容易驗證問題是否真的存在。

先迭代風險最高的類別

如果第一次檢查發現很多問題，請按照這個順序修：可存取名稱、鍵盤操作、焦點與對話框，接著是語意與表單。這些類別通常對使用者影響最大，程式層級的修正也最明確。之後再把更新後的檔案重新跑一次技能，檢查狀態、對比或朗讀提示有沒有迴歸。

要避免的常見失敗模式

最常見的錯誤，是沒有指定 UI 模式或檔案就要求大範圍的可及性回饋。另一個問題是允許大幅重寫，因為這個技能本來就是設計來做定點修改。第三個問題是忽略輸入情境，例如這個 modal 是否會攔截焦點，或某個按鈕是否只有圖示；這些都可能讓建議變成空泛的通則，而不是程式真正需要的精準修正。