可理解性

本文提供了關於如何編寫 Web 內容的實用建議,使之符合 Web 內容無障礙指南 (WCAG) 2.0 和 2.1 中概述的可理解性原則中的成功標準。可理解性指出資訊和使用者介面操作必須易於理解。

注意:要閱讀 W3C 對可理解性及其指南和成功標準的定義,請參閱 原則 3:可理解性 — 資訊和使用者介面操作必須易於理解

指南 3.1 — 可讀性:使文字內容可讀且易於理解

本指南側重於使文字內容儘可能易於理解。

成功標準 如何符合標準 實用資源
3.1.1 頁面語言 (A) 每個網頁的預設人類語言應透過程式碼可檢測。這對於確保讀者已訪問到適合其語言的網頁等目的至關重要。實現此目的的最簡單方法是在頁面的 lang 屬性上設定 <html> 元素,使其值等於最能代表頁面所用語言的語言程式碼。 請參閱 設定文件的主要語言
3.1.2 部分語言 (AA)

在頁面內容包含與主要語言不同的語言的單詞或短語的情況下,請使用 lang 屬性在圍繞所述術語的元素(例如,如果不存在語義元素,則為 <span>)上設定適當的語言。

對於無論語言如何都相同的單詞或短語(例如專有名詞、不屬於特定語言的技術術語),您無需設定不同的語言。

3.1.3 罕見詞語 (AAA) 使用技術術語、行話或習語/俚語時,應為這些短語/詞語提供定義。您的網站應提供包含這些單詞/術語定義的詞彙表,然後您可以在這些單詞/術語出現時連結到詞彙表,或者至少在周圍文字中提供定義,或者在頁面底部的 描述列表 中提供定義。
3.1.4 縮略語 (AAA)

使用縮略語時,應提供其擴充套件或定義(視情況而定)。

通常認為,<abbr> 元素是提供縮略語擴充套件的首選方式 - 它接受一個 title 屬性,其中包含擴充套件,並且當滑鼠懸停在縮略語上時,擴充套件就會顯示。但是,標題內容無法透過鍵盤訪問,並且螢幕閱讀器也無法可靠地朗讀。更好的處理方法是再次提供指向包含縮略語擴充套件和解釋的詞彙表頁面的連結,或者至少在上下文文字中包含它們。

請參閱 縮略語
3.1.5 閱讀水平 (AAA)

如果提供的文字需要高於初中水平的閱讀水平(通常為 11-14 歲的兒童),請提供補充解釋材料來幫助無法閱讀的人,或者提供以初中水平編寫的替代版本。

這並不意味著所有主題都應該被所有人理解,而是指寫作風格應該對所有人來說都是無障礙的。最好將所有內容都以初中水平編寫,即使是程式設計教程等技術文件,除非有充分的理由不這樣做(例如,出於詩歌效果而使用其他風格),或者必須採用嚴格的風格(例如 W3C 規範)。

3.1.6 發音 (AAA)

應提供一種機制,以便使用者可以訪問需要理解內容才能完全理解內容的單詞的發音。

HTML <audio> 元素可用於建立控制元件,允許讀者播放包含正確發音的音訊檔案,並且在難詞之後包含文字發音指南也是有意義的,就像您在詞典條目中找到的那樣。

請檢視 影片和音訊內容 以及 英語詞典發音指南

注意: 同時請檢視 WCAG 對 指南 3.1 可讀性:使文字內容可讀易懂 的描述。

指南 3.2 — 可預測性:使網頁以可預測的方式顯示和操作

該指南側重於使使用者介面直觀易懂。

成功標準 如何符合標準 實用資源
3.2.1 獲取焦點 (A)

當控制元件或其他頁面功能獲取焦點時,不應以可能混淆或使使用者感到困惑的方式改變上下文。

這是一個合理的的設計問題 - 人們不希望介面讓他們感到意外;他們希望介面直觀並按預期執行。例如,聚焦導航選單選項不應改變顯示的頁面 - 應在顯示改變之前啟用它。

Elementfocus 事件包含一些有用的資訊。同時請檢視 構建鍵盤輔助功能 獲取一些有用的實現思路。
3.2.2 輸入 (A)

當資料輸入控制元件或更改設定時,上下文不應意外更改。在更改發生之前,應警告/告知使用者即將發生的更改。

同樣,應實施合理的設計。例如,如果按下按鈕會導致應用程式退出當前檢視,則應詢問使用者是否確認此操作,並在適當的情況下儲存其工作等。

input 事件在此處很有用。
3.2.3 導航一致性 (AA)

導航選單/控制元件的樣式和位置應在網頁的不同頁面或檢視之間保持一致,並且現有專案應以相同的順序出現,即使例如添加了新專案。如果使用者啟動了更改,例如選擇導航的不同配色方案或位置,則應在所有頁面上尊重他們的選擇。

同樣,合理的設計 - 使所有頁面或檢視上的導航控制元件相同。

請檢視 頁面佈局 獲取有關現代佈局標記的資訊。同時請檢視 將連結樣式化為按鈕 獲取一個有用的可訪問導航選單示例。
3.2.4 標識一致性 (AA)

具有相同功能的控制元件或元件應在不同頁面或檢視中以相同的方式標識。例如,出現在世界旅行網站每個頁面上的貨幣轉換器應該在語義上和標籤方面完全相同。

同樣,合理的設計!

“標籤”可以指文字內容中的描述性資訊或 HTML 表單標籤。請檢視 有意義的文字標籤 獲取更多資訊。
3.2.5 按需更改 (AAA)

可能導致使用者混淆或迷失方向的上下文更改僅應在使用者請求時發生,或者使用者應該能夠關閉它們。

如果你需要做一些會顯著改變當前檢視(例如內容或控制元件)的事情,讓使用者控制他們希望何時發生這種改變(例如,顯示哪個頁面,何時前進到相簿中的下一張照片...)。

如果你需要在頁面上使用像輪播這樣的功能,提供一個選項來停止它自動前進。如果可能,最好避免使用這種功能。

3.2.6 幫助一致性 (A)

包含幫助機制的網頁(包括自助選項和人工聯絡方式),這些機制在多個網頁上重複,需要將這些機制以相同的順序放置在所有頁面上,除非使用者啟動更改。

檢視 一致性幫助文件 瞭解有關此標準的更多資訊。

注意: 同時請檢視 WCAG 對 指南 3.2 可預測性:使網頁以可預測的方式出現和執行 的描述。

指南 3.3 — 輸入輔助:幫助使用者避免和糾正錯誤

該指南圍繞著幫助使用者以最少的錯誤輸入必要的資訊。

成功標準 如何符合標準 實用資源
3.3.1 錯誤識別 (A)

當用戶填寫表單或在選項之間進行選擇時,應向用戶清楚地報告檢測到的任何錯誤,以及與錯誤相關的表單控制元件。

建議透過 HTML 表單驗證功能和/或 JavaScript 實施客戶端錯誤檢測和處理,無論哪種方法最適合你的情況。當檢測到錯誤時,應該在有錯誤的表單輸入旁邊顯示直觀的錯誤訊息,以幫助使用者更正其輸入。對於螢幕閱讀器使用者,你可以使用 aria 即時區域來提醒使用者頁面上的更改。

注意: 伺服器端驗證應始終與客戶端驗證一起使用。客戶端驗證很容易被關閉或繞過,因此不能單獨依賴它。

請檢視 表單資料驗證 獲取全面的驗證資訊,以及 WAI-ARIA:動態內容更新 獲取有關即時區域的資訊。
3.3.2 標籤或說明 (A)

在需要資料輸入時,應提供清晰的說明。當需要簡單的說明或提示時,你可以使用 <label> 元素用於單個輸入,例如姓名或年齡,或者使用 <label><fieldset>/<legend> 用於多個輸入組合(例如出生日期或郵政地址的元素)。

如果需要更復雜的解釋,你也可以始終包含解釋性段落,或者你可能需要嘗試使你的表單更直觀。

3.3.3 錯誤建議 (AA)

當檢測到錯誤並且已知更正建議時,向用戶提供這些建議(例如,當用戶選擇已存在的使用者名稱時,建議替代方案),除非這樣做會導致安全問題(例如輸入密碼)或上下文問題(例如,他們試圖回答測驗應用程式中的問題)。

在這種情況下,如果合適,你可能需要使用 JavaScript 和伺服器端功能的組合來檢查輸入是否正確,如果輸入不正確,可以向用戶提供哪些可行的建議。這些建議應該在上下文中以有用的方式顯示,就像錯誤訊息一樣(參見 3.3.1)。

還沒有教程建議。
3.3.4 錯誤預防(法律、財務、資料)(AA)

在涉及敏感資料輸入的表單(例如法律協議、電子商務交易或個人資料)的情況下,以下至少一項應為真

  • 提交是可逆的。
  • 對資料進行錯誤檢查,並且使用者有機會更正錯誤。
  • 提供了一種機制,可以在最終提交之前確認和更正資訊。

可逆 - 對於任何可以輸入資料的檢視,提供一個等效的檢視,允許你根據需要編輯或刪除條目(例如,請檢視 Django Web 框架)。

檢查資料 - 如 3.3.1 中所述,應使用客戶端和伺服器端驗證的組合來檢測錯誤並向用戶顯示有用的訊息,以允許他們更正其輸入。

確認和更正 - 在適當的情況下,在填寫一系列表單欄位以執行任務(例如購買產品)後,應向用戶顯示一個確認螢幕,讓他們可以在其中檢視其輸入並更正任何看起來不對的地方。這種模式通常用在亞馬遜等電子商務網站上。

3.3.5 可用上下文敏感幫助 (AAA) 在上下文中提供說明和其他適當的提示,以幫助完成和提交表單。 這實際上只是在 3.3.1 和其他類似標準的基礎上,需要更全面的上下文幫助資訊和服務,例如,在每個頁面上提供一個指向幫助頁面或服務的專用連結,提供成功完成應該是什麼樣子的示例。
3.3.6 錯誤預防(所有)(AAA) 這一原則是在 3.3.4 的基礎上,將其要求擴充套件到所有使用者輸入情況,而不僅僅是涉及敏感資料的使用者輸入情況。 同樣,請檢視 3.3.4。
3.3.7 重複輸入 (A) 在相同流程或使用者流程中,使用者之前已輸入或提供的必要資訊,要麼自動填充,要麼從選項列表中提供給使用者選擇,除非重新輸入資訊對於安全原因至關重要或必不可少,或者資訊已失效。 檢視 瞭解重複輸入 瞭解更多資訊。
3.3.8 可訪問身份驗證(最低)(AA) 除非提供替代方案,例如物體或個人內容(例如影像、影片和音訊)識別,或輔助機制(例如複製和貼上以及自動儲存密碼),否則任何身份驗證流程中的任何步驟都不需要認知功能測試,例如記住密碼。 檢視 可訪問身份驗證文件 瞭解有關此標準的更多資訊。
3.3.9 可訪問身份驗證(增強)(AAA) 任何身份驗證流程中的任何步驟都不需要認知功能測試,例如記住密碼,除非提供不依賴於認知功能測試或提供機制來幫助使用者完成認知功能測試的替代方案。允許需要使用者識別物體或識別使用者提供給網站的非文字內容的身份驗證測試。 檢視 增強型可訪問身份驗證文件 (AAA) 瞭解更多資訊。

注意: 同時請檢視 WCAG 對 指南 3.3 輸入輔助:幫助使用者避免和更正錯誤 的描述。

另請參閱