好，更好，最好：解開可訪問模式的複雜世界

已發表: 2022-03-10
快速總結↬在可訪問性方面，我們如何知道哪些模式是好的、更好的、最好的？ 使用已建立的模式/庫還是創建新模式/庫更好？ 有了無數的選擇，我們很快就會陷入關於這個話題的混亂網絡。

馬克·貝尼奧夫 (Marc Benioff) 令人難忘地指出，科技行業唯一不變的就是變化。 我在科技行業工作了超過 15 年，我可以證實這一點。 科技恐龍同胞可以證明，早期網絡的工作方式與我們許多人甚至想像的完全不同。

雖然技術行業的這種不斷變化帶來了我們今天看到的創新和進步，但它也引入了選擇的概念。 雖然選擇——從表面上看——似乎是一種天生的積極事物，但它並不總是等於彩虹和玫瑰。 技術變革的湧入也帶來了編碼語言的分裂和編程“熱”的永無止境的味道。 有時，這種豐富的選擇會變成過度選擇——一種經過充分研究的認知障礙，人們由於有太多選擇而難以做出決定。

在本文中，我們將嘗試解開可訪問模式的複雜世界——一步一步。 我們將通過回顧當前可訪問的模式和庫來開始，然後我們將考慮我們的一般模式需求和潛在的限制，最後，我們將通過一系列批判性思維練習來學習如何更好地評估可訪問性模式。

我們編織了多麼糾結的網

Overchoice 已經滲透到技術的各個方面，包括我們用來構建數字創作的模式和庫——從簡單的複選框到復雜的動態模式，以及介於兩者之間的一切。 但是當有這麼多選擇時，我們怎麼知道哪個模式或庫是正確的呢？ 使用用戶每天遇到的既定模式/庫會更好嗎？ 還是創建全新的模式以獲得更愉快的用戶體驗更好？

有了無數的選擇，我們很快就會因過多的選擇而癱瘓。 但是，如果我們退後一步，考慮一下為什麼我們首先要構建我們的數字產品（即最終用戶），那麼選擇可以為最多的人增加最大價值的模式或庫是否有意義？ ?

如果您認為選擇模式或庫已經是一個令人生畏的過程，那麼這可能是您開始擔心的地方。 但不必擔心——選擇一個可訪問的模式/庫不是火箭科學。 就像技術中的其他一切一樣，這個旅程始於一點點知識、大量的試驗和錯誤，以及對不存在適合每個用戶、情況或框架的完美模式/庫的理解。

我怎麼知道這個？ 好吧，在過去的五年裡，我一直在研究、構建和測試不同類型的可訪問模式，同時研究 A11y 樣式指南、Deque 的 ARIA 模式庫，並評估流行的 SVG 模式。 但我也審查了每個可以想像的框架/平台上的許多客戶端模式和庫。 在這個時間點上，我可以毫不猶豫地說，當你觀察足夠長的時間時，模式可訪問性就開始發展。 雖然偶爾會有不惜一切代價避免的模式，但它並不總是那麼明確。 談到可訪問性，我認為大多數模式都屬於好、更好、最好的漸變。 困難的部分是知道哪種模式屬於哪個類別。

跳躍後更多！ 繼續往下看↓

批判性地思考模式

那麼，在可訪問性方面，我們如何知道哪些模式是好的、更好的、最好的呢？ 這取決於。 數字可訪問性社區經常引用的這句話不是逃避，而是“我們需要更多背景才能給你最好的答案”的簡寫。 但是，上下文並不總是很清楚，因此在構建和評估模式的可訪問性時，我提出的一些基本問題包括：

  • 是否已經有我們可以使用的既定可訪問模式？
  • 我們支持哪些瀏覽器和輔助技術 (AT) 設備？
  • 是否有任何框架限製或其他集成/因素需要考慮？

當然，您的具體問題可能與我的不同，但關鍵是您需要在評估模式時開始使用您的批判性思維技能。 您可以通過首先觀察、分析然後對每個模式的可訪問性進行排名，然後再做出最終決定來做到這一點。 但在我們開始之前，讓我們先深入研究一下最初的問題。

是否已經建立了可訪問的模式？

為什麼似乎每個新框架，我們都會得到一套全新的模式？ 這種不斷地用新的模式選擇重新發明輪子可能會使開發人員感到困惑和沮喪，特別是因為通常沒有必要這樣做。

不相信我？ 好吧，這樣想：如果我們訂閱原子設計系統，我們就會明白幾個小的代碼“原子”組合在一起可以創建一個更大的數字產品。 但在科學界，原子並不是生命中最小的組成部分。 每個原子由許多亞原子粒子組成，如質子、中子和電子。

同樣的邏輯也可以應用於我們的模式。 如果我們更深入地研究現有各種框架中可用的所有模式，核心亞原子結構基本上是相同的，而不管使用的實際編碼語言如何。 這就是為什麼我欣賞具有可訪問模式的流線型編碼庫，我們可以根據技術和設計需求進行構建。

注意：除了 Smashing Magazine 最近發布的可訪問模式列表（以及文章末尾的更詳細的模式和庫列表）之外，一些著名的來源包括 Inclusive Components、Accessible Components 和 Gov.UK Design System .

我們支持哪些瀏覽器和輔助技術 (AT) 設備？

在研究了一些可能有效的基本模式之後，我們可以繼續討論瀏覽器和輔助技術 (AT) 設備支持的問題。 就其本身而言，瀏覽器支持不是開玩笑。 當您將 AT 設備和 ARIA 規範添加到組合中時，事情開始變得棘手……並非不可能，只是需要更多的時間、精力和思考過程來解決所有問題。

但這並不全是壞消息。 有一些很棒的資源，例如 HTML5 Accessibility 和 Accessibility Support，可以幫助我們更好地了解當前的瀏覽器 + AT 設備支持。 這些網站概述了可用的不同 HTML 和 ARIA 模式子元素，包括開源社區測試，並提供了一些模式示例——適用於桌面和移動瀏覽器/AT 設備。

是否有任何框架限製或其他集成/因素需要考慮？

一旦我們選擇了一些可訪問的基本模式並考慮到瀏覽器/AT 設備支持，我們就可以繼續圍繞模式及其環境提出更細粒度的上下文問題。 例如，如果我們在內容管理系統 (CMS) 中使用模式或考慮遺留代碼，則會存在某些模式限制。 在這種情況下，少數模式選擇可以很快減少到一兩個。 另一方面，一些框架更寬容，更願意接受任何模式，因此我們可以少擔心框架限制，而更多地專注於做出我們可以做出的最容易獲得的模式選擇。

除了到目前為止我們討論的所有內容之外，在選擇模式時還有許多其他考慮因素需要權衡，例如性能、安全性、搜索引擎優化、語言翻譯、第三方集成等等。 這些因素無疑會影響您的可訪問模式選擇，但您還應該考慮創建內容的人。 您選擇的可訪問模式必須以足夠健壯的方式構建，以處理圍繞編輯器生成和/或用戶生成的內容的任何潛在限制。

評估可訪問性模式

代碼往往勝於雄辯，但在我們開始討論所有這些之前，請快速注意，以下模式示例並不是每種情況下唯一可用的模式，也不是該組中被認為是“最佳”的模式。整個世界的可訪問模式。

對於下面的模式演示，我們應該想像一個假設的情況，在這種情況下，我們將每組模式與它們自己進行比較。 雖然這不是一個現實的情況，但通過這些批判性思維練習並評估可訪問性模式應該可以幫助您在現實世界中遇到模式選擇時做好準備。

可訪問的按鈕模式

我們將審查的第一組可訪問性模式幾乎在每個網站或應用程序中無處不在：按鈕。 第一個按鈕模式使用 ARIA 按鈕角色來模擬按鈕，而第二個和第三個按鈕模式使用 HTML <button>元素。 第三種模式還添加了aria-describedby和 CSS 以在視覺上隱藏事物。

請參閱 Carie Fisher 的 Pen [Accessible Button Patterns](https://codepen.io/smashingmag/pen/KKNEjKR)。

請參閱 Carie Fisher 的 Pen Accessible Button Patterns。

好： role="button"

 <a role="button" href="[link]">Sign up</a>

更好： <button>

 <button type="button">Sign up</button>

最佳： <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

雖然第一個模式乍一看似乎很簡單，但它們確實引發了一些可訪問性問題。 例如，在第一個按鈕模式中，我們看到 ARIA role="button"用於“好”模式而不是 HTML <button>元素。 從可訪問性的角度考慮，由於我們知道 HTML <button>元素是在 HTML4 中引入的，我們可以合理地推測它被所有主要瀏覽器的最新版本完全支持，並且可以很好地與大多數 AT 設備配合使用。 但是，如果我們更深入地研究 ARIA role="button" 的可訪問性支持，我們會發現從輔助技術的角度來看有一點優勢，而 HTML <button>元素缺少瀏覽器 + AT 覆蓋的某些區域，尤其是當我們考慮語音控制支持。

那麼，為什麼 ARIA 模式不在“更好”類別中呢？ ARIA 不是讓它更易於訪問嗎？ 沒有。 事實上，在這種情況下，可訪問性專家經常背誦 ARIA 的第一條規則——不要使用 ARIA。 這是一種開玩笑的說法，即盡可能使用 HTML 元素。 ARIA 確實很強大，但在壞人手中，它弊大於利。 事實上，WebAIM Million 報告指出，“有 ARIA 的頁面平均比沒有的頁面多 60% 的錯誤。” 因此，您在使用 ARIA 時必須知道自己在做什麼。

在這種情況下使用 ARIA 的另一個問題是，我們需要為role="button"模式構建我們需要的按鈕功能，而該功能已經預先烘焙到<button>元素中。 考慮到<button>元素也有 100% 的瀏覽器支持並且是一個易於實現的模式，在評估前兩個模式時，它在層次結構中略微領先。 希望這種比較有助於打破添加 ARIA 使模式更易於訪問的神話——通常情況恰恰相反。

第三個按鈕模式顯示了 HTML <button>元素以及aria-describedby鏈接到一個 ID 元素，該 ID 元素在 CSS 中隱藏。 雖然這種模式稍微複雜一些，但它通過在按鈕和用途之間創建關係，在上下文方面增加了很多。 如果有疑問，只要我們可以為情況添加更多上下文就更好了，因此我們可以假設如果編碼正確，僅比較這些特定按鈕模式時，它是最好的模式。

可訪問的上下文鏈接模式

我們將回顧的第二組模式是上下文鏈接。 這些模式有助於向 AT 用戶提供比屏幕上可見的信息更多的信息。 第一個鏈接模式利用 CSS 以可視方式隱藏附加的上下文信息。 而第二個和第三個鏈接模式將 ARIA 屬性添加到組合中：分別為aria-labelledby和aria-label 。

請參閱 Carie Fisher 的 Pen [Accessible Link Patterns](https://codepen.io/smashingmag/pen/VwmRJYv)。

請參閱 Carie Fisher 的 Pen Accessible Link Patterns。

好： visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

更好： visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

最佳： aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

雖然所有三種上下文鏈接模式看起來都一樣，但當我們檢查代碼或使用 AT 設備測試它們時，會有一些明顯的差異。 第一種模式使用 CSS 技術為有視力的用戶隱藏內容，但仍將隱藏的內容呈現給無視力的 AT 用戶。 雖然這種技術在大多數情況下都可以工作，但鏈接和附加信息之間並沒有形成真正的關係，所以這種聯繫充其量只是試探性的。 因此，第一個鏈接模式是一個不錯的選擇，但不是三者中最健壯的鏈接模式。

接下來的兩個鏈接模式評估起來有點棘手。 根據 W3C 的 ARIA 規範，“ aria-label的目的與 aria aria-labelledby的目的相同。 它為用戶提供了一個可識別的對象名稱。” 因此，理論上，這兩個屬性應該具有相同的基本功能。

然而，規範還指出，在決定向用戶傳達哪個可訪問名稱時，用戶代理優先於aria-labelledby而非aria-label 。 研究還顯示了圍繞自動翻譯和 aria-label 屬性的問題。 所以這意味著我們應該使用aria-labelledby ，對嗎？

嗯，沒那麼快。 同樣的 ARIA 規范繼續說“如果界面無法在屏幕上顯示可見標籤（或者如果可見標籤不是所需的用戶體驗），作者應該使用aria-label並且不應該使用aria-labelledby 。” 談論混亂 - 那麼我們應該選擇哪種模式？

如果我們有大規模的翻譯需求，我們可能會決定改變視覺方面並寫出顯示完整上下文的鏈接（例如“閱讀更多關於這個很棒的東西”）或決定使用aria-labelledby 。 但是，假設我們沒有大規模的翻譯需求，或者可以以合理/可訪問的方式解決這些需求，並且我們不想改變視覺 - 那麼怎麼辦？

基於當前的 ARIA 1.1 建議（承諾在 ARIA 1.2 中翻譯 aria-label），再加上aria-label相對於aria-labelledby對開發人員來說更容易實現這一事實，我們可以決定對aria-label進行加權aria-labelledby在我們的模式評估中。 這是一個明顯的例子，說明上下文在我們可訪問的模式選擇中佔很大比重。

可訪問<svg>模式

最後，但同樣重要的是，讓我們研究一組 SVG 圖像模式的可訪問性。 SVG 是代碼的可視化表示，但仍然是代碼。 這意味著 AT 設備可能會跳過非裝飾性 SVG 圖像，除非將role="img"添加到模式中。

假設以下 SVG 模式本質上是信息性的，則每個都包含一個role="img" 。 第一個 SVG 模式將<title>和<text>與 CSS 結合使用，以在視覺上對有視力的用戶隱藏內容。 接下來的兩個 SVG 模式涉及<title>和<desc>元素，但在最後一個模式中添加了aria-labelledby屬性。

請參閱 Carie Fisher 的 Pen [Accessible SVG Patterns](https://codepen.io/smashingmag/pen/poNYXvK)。

請參閱 Carie Fisher 的 Pen Accessible SVG Patterns。

好： role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

更好： role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

最佳： role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

讓我們先看看使用<title>和<text>以及視覺隱藏的 CSS 的第一個模式。 與以前在模式中可見隱藏的文本不同， <title>和<text>元素之間存在固有的關係，因為它們被分組在同一個 SVG 元素保護傘下。 但是，這種關係並不是很牢固。 事實上，如果你回顧我對 SVG 模式的研究，我們會發現 8 個瀏覽器/AT 組合中只有 3 個聽到了完整的信息。 （注：豬圖案#1 等同於燈泡圖案#7。）

儘管工作中的 W3C SVG 規範將<text>元素定義為“由文本組成的圖形元素……要繪製的字符表示為字符數據，但這是真的。 因此，視障人士可以輕鬆訪問 SVG 內容中的文本數據。” 第一個模式是可以的，但我們可以做得更好。

第二個模式刪除<text>元素並用<desc>元素替換它。 W3C SVG 規範指出：

“ <title>子元素代表元素的短文本替代項......而<desc>元素代表元素的更詳細的文本信息，例如描述。”

這意味著 SVG 中的<title>和<desc>元素可以與傳統上在<img>元素中找到的圖像替代文本和長描述選項類似地使用。 將<desc>元素添加到第二個 SVG 後，我們看到類似的瀏覽器/AT 支持，8 種組合中有 3 種聽到了完整的消息。 （注意：豬模式#2 等同於燈泡模式#10。）雖然這些測試結果似乎反映了第​​一個模式，但這種模式進入“更好”類別的原因是它更容易實現代碼-明智的做法是影響更多的 AT 用戶，因為它適用於 JAWS、VoiceOver 桌面和 VoiceOver 移動設備，而第一個模式支持不太流行的瀏覽器/AT 組合。

第三個模式再次使用<title>和<desc>元素，但現在添加了一個aria-labelledby和 ID。 根據相同的 SVG 測試，添加這段額外的代碼意味著我們可以完全支持 8 種瀏覽器/AT 組合中的 7 種。 （注意：豬模式#3 相當於燈泡模式#11。）在三種 SVG 模式中，第三種模式是“最好的”，因為它支持最多的 AT 設備。 但是這種模式在使用某些瀏覽器/AT 組合時確實存在缺陷。 您將聽到此模式的重複圖像標題/描述內容。 雖然對用戶來說可能很煩人，但我認為聽到重複的內容通常比根本不聽要好。

結束的想法

雖然我們當然都重視科技領域的選擇，但我想知道我們是否已經到了一個時間點，即過多的選擇讓我們對下一步做什麼感到癱瘓和困惑？ 在選擇可訪問模式方面，我們可以就模式/庫選項、瀏覽器/AT 設備支持、框架限制等提出直截了當的問題。

有了正確的數據，這些問題就很容易回答了。 然而，當我們超越模式並真正考慮使用它們的人時，它變得有點複雜。 那時我們才意識到我們的選擇對用戶成功能力的影響。 正如 George Dei 教授雄辯地指出：

“包容並沒有將人們帶入已經存在的事物中——它正在為每個人創造一個新的空間，一個更好的空間。”

通過花更多的時間批判性地思考模式並選擇最容易獲得的模式，我們無疑將創造一個更具包容性的空間來接觸更多的用戶——按照他們的條件。

相關資源

工具

  • 輔助功能支持，Michael Fairchild，a11ysupport.io
  • HTML5 可訪問性，史蒂夫·福克納

模式庫

  • 無障礙項目
  • 無障礙風格指南
  • 無障礙組件，Scott O'Hara
  • 可訪問drag-and-drop列表重新排序插件，Harris Schneiderman
  • Deque 的 ARIA 模式庫
  • Deque 的可訪問 React 庫
  • GOV.UK 設計系統
  • 包容性組件，Heydon Pickering
  • 美國網頁設計系統 (USWDS)
  • 無障礙網頁教程