accessibility

無障礙 skill 概覽

這個無障礙 skill 能做什麼

這個無障礙 skill 能幫你依照 WCAG 2.2 AA 級來設計、實作與稽核無障礙 UI。它的目標，是把產品意圖轉成具體的語意選擇：原生元素、ARIA 角色、標籤、提示、焦點行為，以及 Web、iOS 和 Android 各平台的無障礙特性。

誰適合安裝這個無障礙 skill

這個無障礙 skill 最適合前端工程師、設計系統團隊、UX 稽核人員，以及需要可直接落地實作建議、而不是一份泛用無障礙清單的產品設計師。當你在做 UX Audit 的無障礙工作，想把「這個流程看起來有風險」進一步收斂成具體修正項時，它特別有用。

這個無障礙 skill 能幫你完成什麼工作

真正要完成的工作，不只是「讓它符合規範」，而是要把元件或流程正確映射到 accessibility tree，讓輔助科技使用者拿到正確的 role、name、state、order 與互動模型。這個 skill 強調的是語意映射、焦點管理、標籤設計，以及 POUR 原則，而不是大方向的政策摘要。

為什麼選它，而不是一般 prompt

一般 prompt 常會產出含糊的無障礙建議。這個 skill 更適合你需要結構化推理的情境，例如：先判斷元件角色，再優先考慮原生語意，接著定義標籤、狀態、鍵盤行為與焦點處理。這會讓無障礙建議更容易用在實作審查與稽核上。

如何使用 accessibility skill

安裝後的情境與先讀內容

先透過你的 skills 工作流程安裝這個 skill，接著先打開 skills/accessibility/SKILL.md。這個 skill 沒有額外的 script 或參考檔案，所以幾乎所有實用指引都集中在這一份文件裡。請依序閱讀這些章節：

1. When to Use
2. Core Concepts
3. How It Works
4. 關於辨識元件角色的那一段

這是一個輕量級的無障礙安裝：設定負擔低，但你要預期自己補齊缺少的產品脈絡。

accessibility skill 需要哪些輸入

這個 accessibility skill 最好在你提供以下資訊時使用：

• platform：Web、iOS 或 Android
• component or flow：button、modal、form、tabs、menu、carousel 等
• user goal：使用者想完成什麼
• current implementation：HTML、JSX、SwiftUI/UIKit、Jetpack Compose/View XML，或截圖加行為說明
• constraints：設計系統限制、舊版標記、第三方 widget
• audit target：WCAG 2.2 AA、鍵盤支援、螢幕閱讀器行為、焦點順序、觸控目標大小，或命名／狀態問題

弱輸入：Make this accessible.
強輸入：Audit this React modal for WCAG 2.2 AA. Check semantic role, accessible name, focus trap, escape behavior, initial focus, return focus, and screen reader announcement. Suggest corrected JSX.

把粗略目標轉成強提示詞

想讓 accessibility 使用效果更好，可以用這種 prompt 結構：

• 先辨識 UI role，以及是否應該改用原生元素。
• 描述預期的 accessibility tree。
• 列出必要的 label、role、state、value 與 hint 資訊。
• 定義鍵盤與焦點行為。
• 標出 WCAG 2.2 AA 的風險。
• 回傳修正後的 code 與簡短稽核摘要。

範例：
Use the accessibility skill to review this custom dropdown on Web. First decide whether it should be a native select, button + listbox, or another pattern. Then provide the expected ARIA, keyboard interactions, focus movement, visible focus requirements, target size concerns, and revised code.

用於稽核與實作的建議工作流程

如果你是為了 UX Audit 做無障礙，先從流程層級開始，再往下拆到元件：

1. 命名任務與失敗風險
2. 辨識每個互動元素的真實角色
3. 先確認是否有原生語意替代方案
4. 驗證 labels、names、values 與 states
5. 檢查鍵盤順序與焦點可見性
6. 概念性測試螢幕閱讀器朗讀內容
7. 要求修正後的 code 或規格

如果你是要做實作而不是稽核，請直接向 skill 索取能交給工程與 QA 的 acceptance criteria，而不只是段落式說明。

accessibility skill 常見問題

這個 accessibility skill 適合初學者嗎？

適合，但前提是你已經懂基本的 UI 開發。這個 skill 會用清楚的方式解釋核心無障礙概念，但它不是一套完整的 WCAG 初學課程。它比較適合作為有引導的實作支援，而不是你唯一的學習資源。

這足以作為安裝 accessibility skill 的決策依據嗎？

大致上可以。這個 skill 的範圍清楚、工作流程具體，而且技術重點明確。主要限制在於內容包裝深度：沒有搭配範例、測試腳本或平台專屬參考檔。如果你想要大量可重用資產，這個 skill 會顯得精簡；如果你要的是快速指引，它就很容易上手。

它和一般無障礙 prompt 有什麼不同？

差別在 framing。這個 accessibility guide 會把重點放在角色辨識、語意映射、accessibility tree 思考、標籤與焦點管理。一般 prompt 則常常直接跳到 ARIA 屬性，結果可能造成過度工程化，或套錯模式。

什麼情況下不該用這個 skill？

不要只靠這個 accessibility skill 來做法務層級的定案、複雜輔助科技相容性測試，或高度專門的原生平台邊界案例。它最擅長的是設計與程式碼推理，不是取代用真機、螢幕閱讀器與純鍵盤流程進行的人工測試。

如何提升 accessibility skill

提供更完整的 UI 脈絡，不要只有 code snippet

影響品質最大的因素是脈絡。請把使用者任務、控制項是會變更狀態還是導向、畫面上實際看到什麼，以及目前哪裡壞掉都一起提供。無障礙建議取決於行為，不只是標記本身。div 可能代表好幾種模式；當你把預期互動定義清楚時，這個 skill 的表現會好很多。

先要求判斷模式，再要求 ARIA

常見失誤是把 ARIA 硬套到錯的元件上。要提升 accessibility 輸出，先問：「這到底是哪一種 pattern？」例如，先要求在原生 button、link、disclosure、tab、dialog 或 listbox 之間做判斷，再進行修正。這通常能避免不必要的自訂 widget。

以可直接落地的區塊來要求輸出

如果想讓 accessibility 使用效果更強，請要求結構化回應：

• 發現的問題
• 對使用者的影響
• WCAG 2.2 相關疑慮
• 建議的語意模式
• 精確的 code 修改
• 測試步驟

這種格式比單篇散文式回覆，更適合交接給工程、QA 或 design system 擁有人。

用真實失敗證據反覆迭代

第一次輸出後，可以把更具體的資訊回饋給 accessibility skill，讓結果更好：例如螢幕閱讀器實際朗讀內容、鍵盤陷阱、缺少可見焦點，或觸控目標尺寸。當你把它當成 UX audit 發現的迭代循環，而不是一次性的合規檢查時，它會變得有價值得多。