接口可用性測試

1）為什麼，我們相信什麼「準備好了」

• 滿足了WCAG 2標準。1/2.目標平臺的2級AA；
• 界面完全通過鍵盤；
• 正確操作屏幕閱讀器；
• 對比符合規範；
• 所有狀態/錯誤/狀態都可以在視線之外且沒有鼠標的情況下訪問；
• 考慮了本地化，RTL，reduce運動和移動功能。

2）測試策略（金字塔A11y）

1.自動測試/linter（快速覆蓋高達40-60%的問題類別）。
2.手動模式檢查（鍵盤，焦點，內容，邏輯）。
3.輔助技術（AT）會話：屏幕閱讀器、縮放、顏色過濾器。
4.與用戶進行現場測試（如果可能的話）。

目的：捕捉元件/模式級別的系統缺陷,防止其繁殖。

3）基本檢查支票清單（快速運行）

• 鍵盤：禁忌/箭頭可以實現一切；焦點順序是合乎邏輯的；有調制解調器中的焦點陷阱；ESC/Enter/Space正在運行。
• 焦點指示器在任何主題/背景中都可以看到。
• 對比：第4 ≥案文。5：1（普通）,≥ 3：1（大）,圖標/控制可讀。
• 語義：正確的標簽（'button'、'a'、'label'、'ul/li'、'th/td'）、角色和'aria-'僅在需要時。
• Scrinrider：按層次結構排列的標題、按鈕/鏈接的語義名稱、圖標/圖像的替代品。
• 表格：明確的「標簽」，線索/錯誤相關（「aria-describedby」），錯誤文本是具體的。
• 動態：敬酒/橫幅/錯誤通過「aria-live」（「polite」/「assertive」）宣布。
• 動畫尊重「prefers-reduced-motion」；沒有「搖動」接口。
• 本地化/RTL：關鍵屏幕對齊，數字/日期/貨幣由實用程序格式化。
• 移動：觸摸目標≥ 44 × 44 px，不禁止變焦，屏幕旋轉不會破壞內容。

4）角色、責任和文物

設計系統：每個組件描述中的A11 y要求。
開發人員：自動反駁,單位/交互測試與A11y-assert。
QA：手動腳本+AT會議；嚴重性/頻率報告。
UX/內容：微觀錯誤/狀態，可讀性大聲。
工件：支票單，腳本，AT屏幕截圖，帶有WCAG參數的缺陷列表，建議。

5）自動化檢查

Linters/分析儀： axe, eslint-plugin-jsx-a11y, pa11y, Lighthouse.

在pipline：我們在嚴重違規時阻止PR （role/label/對比/tab陷阱）。
對比快照：視覺主題/狀態測試。

6）手動測試： 腳本

6.1個鍵盤

僅使用鍵盤（Tab/Shift+Tab/Enter/Space/箭頭）瀏覽頁面。
檢查：焦點可見性、優先級、所有活動的可用性、沒有「陷阱」和「死」元素。
在調制解調器中：內部焦點，關閉時返回到啟動器。

6.2屏幕閱讀器（最低設置）

Desktop: NVDA/JAWS (Windows), VoiceOver (macOS).

Mobile: VoiceOver (iOS), TalkBack (Android).

我們檢查：正確的標題（H層次結構）,按鈕/鏈接名稱,表格讀取（「th」/「scope」）,狀態聲明,可理解的形狀錯誤。

6.3內容和微型

我們大聲朗讀批判性文本-沒有歧義，沒有「錯誤400」。
錯誤=「什麼不是+如何修復+限制/格式」。

6.4動態和生活區域

成功的敬酒是'aria-live='polite'，錯誤是'assertive'。
進度/下載由文本解釋；skeleton比旋轉器更可取。

7）形式和錯誤（深入）

每個字段都有相關的標簽（不是placeholder）。
錯誤與以下字段相關聯：'aria-invalid='true'，'aria-describedby='［id錯誤］'。
預先指定格式公式（日期，電話）；掩碼不會破壞輸入/插入。
在submit+自動滾動時,總錯誤橫幅並關註第一個錯誤。
錯誤文本：特定，沒有技術術語。

8）表，列表，圖表

表：標題"th" so "scope="col/row"，標題，摘要。
列表是真實的「ul/ol/li」，不是天後。
圖表-備用表格/說明；傳說可用；顏色≠唯一的信號。

9）多媒體和動畫

視頻：字幕/解密；鍵盤控制；沒有自動軌道（或安靜）。
GIF/微動畫：在「prefers-reduced-motion」中關閉；避免爆發。
振動/聲音-可選且在視覺/文本中復制。

10）移動可用性

互動≥ 44 × 44 px，有足夠的間隔。
不禁止縮放（沒有「user-scalable=no」的meta viewport）。
表單/鍵盤：不隱藏系統功能的正確類型（「tel」，「email」，「number」）。
在黑暗主題和系統字體「更多」中進行驗證。

11）本地化、數字和RTL

帶上下文的i18n密鑰上的字符串；長語言（DE/TR）不會破壞布局。
日期/貨幣格式是實用程序，不是字符串。
RTL模式：導航圖標的鏡像，檢查焦點和車廂順序，雙向輸入。

12）關鍵flow的細節（iGaming）

付款/調查結果

明確指示，限制/時限/傭金-文本。
提供商的錯誤被明確聲明，沒有代碼；還有其他行動。
操作確認：專註於邏輯CTA,可取消。

CUS/驗證

照片/文件的逐步提示；進步和ETA。
「模糊/眩光/裁剪」錯誤-帶有修復示例。
中立的語氣，沒有幽默。

13）缺陷嚴重性評估

Blocker：無法完成關鍵任務（鍵盤/屏幕閱讀器）。
批評：關鍵功能起作用，但有嚴重的障礙。
專業：幹擾，有解決辦法。
次要：不影響任務的化妝品/不匹配海德。

每個缺陷都是指向WCAG準則和可重現的腳本。

14）驗收標準（Done的定義，A11y）

100%不帶鼠標的鍵盤腳本。
axe/Lighthouse：沒有嚴重或嚴重的違規行為。
AA在所有主題/狀態中的對比。
關鍵路徑（nawbar，形狀，調制解調器，敬酒）的屏幕閱讀器運行。
文檔A11y 用於新組件/fich（角色模型，aria，焦點，示例）。
CI中A11y測試的回歸是綠色的。

15）流程和自動化

在開發之前：任務中的A11 y標準，具有焦點/錯誤狀態的布局。
在開發中：局部組裝中的linters/ahe；對比/焦點的視覺快照。
在CI中：pa11y/axe-scan按關鍵頁面；在Blocker/Critical下的票據下降。
發布後：季度審核,監視A11 y標簽上的用戶投訴。

16）反模式

播放器代替標簽。
「div」而不是「button」/「a」。
斷開焦環「為了美麗」。
顏色作為唯一的狀態載體。
無焦點打擊/ESC調制解調器。
禁止移動擴展。
沒有人為解釋的「400/500錯誤」。

17）測試腳本模板

腳本1-鍵盤導航（表格頁面）

1.Tab到第一個字段,輸入數據。
2.Shift+Tab向後-確保順序正確。
3.調用驗證（submit）-焦點傳遞到第一個錯誤。
4.用ESC鍵關閉調制解調器,焦點恢復到啟動器。

腳本2-Scrinrider（付款頁面）

1.導航到頁面標題（h1）,收聽部分。
2.打開方法選擇-可以聽到角色/狀態聲明。
3.故意犯和錯誤-讀取消息並與字段相關聯。
4.關於付款的成功敬酒宣布為「polite」。

情景3-動態

1.以>3 c運行操作-包含有關進程/ETA的文本。
2.如果網絡錯誤-標語「assertive」，可從鍵盤訪問，則有「重復/幫助」路徑。

18）有用的微模式

敬酒的角色/aria

html
<div role = "status" aria-live = "polite"> Payment accepted. Balance updated. </div>
<div role = "alert" aria-live = "assertive"> The payment was denied. Try another method. </div>

錯誤與字段的關系

html
<label for = "amount "> Amount </label>
<input id="amount" aria-invalid="true" aria-describedby="amount-error">
<div id = "amount-error "> Minimum 100 UAH. Please enter a larger amount. </div>

Modalka（語義屬性）

html
<div role="dialog" aria-modal="true" aria-labelledby="m-title">
<h2 id =" m-title "> Confirm Payment </h2>
<! -- content -->
<button> Confirm </button>
<button> Cancel </button>
</div>

19）實施A11 y實踐的快速計劃

1.審核當前組件/模式（對比/焦點/角色語義）。
2.設計系統編輯：在每個組件中添加A11 y部分。
3.工具：在本地和CI中配置linters/axe/pa11y/Lighthouse。
4.培訓：設計師/開發人員/撰稿人的短篇小說。
5.飛行員：修復3-5最常見的缺陷（調制解調器，形狀，敬酒）。
6.法規：具有A11 y標準的國防部；季度審計。

最終的spargalka

檢查鍵盤、焦點、對比度、屏幕閱讀器、動態。
通過aria-live宣布狀態；錯誤-與字段相關。
尊重節拍動作，不要禁止縮放。
考慮語義（標簽/角色）而不是「外觀」。
自動驗證,但總是手動補充。
通過參考WCAG，嚴重性和播放腳本捕獲缺陷。