WAI-ARIA 基礎

讓我們首先看看什麼是 WAI-ARIA，以及它能為我們做什麼。

隨著 Web 應用程式變得越來越複雜和動態，一整套新的無障礙功能和問題開始出現。

例如，HTML 引入了一些語義元素來定義常見的頁面功能（<nav>、<footer> 等）。在這些元素出現之前，開發人員會使用帶 ID 或類的<div>，例如 <div class="nav">，但這些元素存在問題，因為沒有簡單的方法可以輕鬆地以程式設計方式找到特定的頁面功能，例如主導航。

最初的解決方案是在頁面頂部新增一個或多個隱藏連結，以連結到導航（或其他任何內容），例如

<a href="#hidden" class="hidden">Skip to navigation</a>

但這仍然不是很精確，並且只能在螢幕閱讀器從頁面頂部開始讀取時使用。

作為另一個例子，應用程式開始提供複雜的控制元件，例如用於選擇日期的日期選擇器、用於選擇值的滑塊等。HTML 提供特殊的輸入型別來呈現此類控制元件

<input type="date" /> <input type="range" />

這些控制元件最初支援得不好，而且在一定程度上仍然難以設定樣式，導致設計師和開發人員選擇自定義解決方案。一些開發人員沒有使用這些原生功能，而是依賴於 JavaScript 庫，這些庫會將此類控制元件生成一系列巢狀的<div>，然後使用 CSS 設定樣式，並使用 JavaScript 控制。

這裡的問題是，它們在視覺上有效，但螢幕閱讀器根本無法理解它們是什麼，它們的使用者只會被告知他們看到了一堆雜亂無章的元素，沒有語義來描述它們的含義。

WAI-ARIA（Web 無障礙性倡議 - 可訪問的富網際網路應用程式）是 W3C 編寫的規範，定義了一組可以應用於元素的額外 HTML 屬性，以便在缺少語義的情況下提供額外語義並提高無障礙性。規範中定義了三個主要功能

角色

它們定義了元素是什麼或做什麼。許多角色是所謂的“地標角色”，它們在很大程度上覆制了結構元素的語義值，例如 role="navigation" (<nav>) 或 role="complementary" (<aside>)。其他一些角色描述了不同的頁面結構，例如 role="banner"、role="search"、role="tablist" 和 role="tabpanel"，這些角色在 UI 中很常見。

屬性

它們定義了元素的屬性，這些屬性可以用來賦予它們額外的含義或語義。例如，aria-required="true" 指定表單輸入需要填寫才能有效，而 aria-labelledby="label" 允許您在元素上新增 ID，然後將其引用為頁面上任何其他內容的標籤，包括多個元素，這在使用 <label for="input"> 時是無法實現的。例如，您可以使用 aria-labelledby 指定包含在<div> 中的鍵描述是多個表格單元格的標籤，或者您可以將其用作影像 alt 文字的替代方案 - 指定頁面上現有的資訊作為影像的 alt 文字，而不是必須在 alt 屬性中重複它。您可以在文字替代 中看到此示例。

狀態

定義元素當前條件的特殊屬性，例如 aria-disabled="true"，它告訴螢幕閱讀器表單輸入當前已停用。狀態與屬性的區別在於，屬性在應用程式生命週期中不會改變，而狀態可能會改變，通常是透過 JavaScript 以程式設計方式進行的。

關於 WAI-ARIA 屬性的一個重要點是，它們不會影響網頁的任何內容，除了瀏覽器無障礙性 API（螢幕閱讀器從中獲取資訊）公開的資訊。WAI-ARIA 不會影響網頁結構、DOM 等，儘管這些屬性對於透過 CSS 選擇元素很有用。

這個問題沒有簡單的答案。很難找到明確說明 WAI-ARIA 的哪些功能受支援以及在哪裡受支援的資源，因為

1. WAI-ARIA 規範中包含許多功能。
2. 需要考慮的作業系統、瀏覽器和螢幕閱讀器的組合有很多。

最後一點是關鍵 - 首先要使用螢幕閱讀器，您的作業系統需要執行具有必要的無障礙性 API 的瀏覽器，這些 API 可以公開螢幕閱讀器執行其工作所需的資訊。大多數流行的作業系統都安裝了一個或兩個瀏覽器，螢幕閱讀器可以與之配合使用。Paciello Group 有一篇相當最新的文章提供了這方面的資料 - 請參閱粗略指南：瀏覽器、作業系統和螢幕閱讀器支援更新。

接下來，您需要擔心所討論的瀏覽器是否支援 ARIA 功能並透過其 API 公開它們，還需要擔心螢幕閱讀器是否識別該資訊並將其以有用的方式呈現給使用者。

1. 瀏覽器支援幾乎是普遍的。
2. 螢幕閱讀器對 ARIA 功能的支援還沒有達到這個水平，但最受歡迎的螢幕閱讀器正在接近這個水平。您可以透過檢視 Powermapper 的WAI-ARIA 螢幕閱讀器相容性 文章來了解支援水平。

在本文中，我們不會嘗試涵蓋每個 WAI-ARIA 功能及其確切的支援詳細資訊。相反，我們將涵蓋您需要了解的最關鍵的 WAI-ARIA 功能；如果我們沒有提及任何支援詳細資訊，您可以假設該功能得到了很好的支援。我們會明確提及任何例外情況。

我們之前討論過促使 WAI-ARIA 誕生的部分問題，但本質上，WAI-ARIA 在四個主要領域非常有用

路標/地標

ARIA 的role 屬性值可以充當地標，它們要麼複製 HTML 元素的語義（例如，<nav>），要麼超越 HTML 語義來提供指向不同功能區域的路標，例如，search、tablist、tab、listbox 等。

動態內容更新

螢幕閱讀器在報告不斷變化的內容時往往會遇到困難；使用 ARIA，我們可以使用 aria-live 來通知螢幕閱讀器使用者何時動態更新了內容區域：例如，透過頁面中的 JavaScript從伺服器獲取新內容並更新 DOM。

增強鍵盤無障礙性

有一些內建的 HTML 元素具有原生的鍵盤無障礙性；當其他元素與 JavaScript 一起使用來模擬類似的互動時，鍵盤無障礙性和螢幕閱讀器報告會因此受到影響。在不可避免的情況下，WAI-ARIA 提供了一種方法，允許其他元素獲得焦點（使用 tabindex）。

非語義控制元件的無障礙性

當使用一系列巢狀的 <div> 以及 CSS/JavaScript 來建立複雜的 UI 功能，或透過 JavaScript 極大地增強/更改原生控制元件時，無障礙性可能會受到影響 - 螢幕閱讀器使用者會發現很難弄清楚該功能的作用，如果沒有語義或其他線索。在這些情況下，ARIA 可以幫助透過結合使用 button、listbox 或 tablist 等角色，以及 aria-required 或 aria-posinset 等屬性來提供更多功能線索。

不過有一點要記住 - 您應該只在需要時使用 WAI-ARIA！理想情況下，您應該始終使用原生 HTML 功能 來提供螢幕閱讀器所需的語義，以便告訴使用者正在發生什麼。有時這是不可能的，要麼是因為您對程式碼的控制有限，要麼是因為您正在建立沒有簡單的 HTML 元素來實現的複雜內容。在這種情況下，WAI-ARIA 可以成為一個有價值的增強無障礙性的工具。

但再次強調，只有在必要時才使用它！

在下一部分中，我們將更詳細地介紹這四個方面，並提供實際示例。在繼續之前，您應該配置一個螢幕閱讀器測試環境，以便您可以在瀏覽示例時測試一些示例。

有關更多資訊，請參閱我們關於測試螢幕閱讀器 的部分。

WAI-ARIA 將role 屬性 新增到瀏覽器，使您能夠在網站上需要的地方新增額外的語義值。這在提供螢幕閱讀器的資訊以使使用者能夠找到常見的頁面元素方面非常有用。讓我們看一個例子 - 我們的website-no-roles 示例（檢視即時示例）具有以下結構

<header>
  <h1>…</h1>
  <nav>
    <ul>
      …
    </ul>
    <form>
      <!-- search form -->
    </form>
  </nav>
</header>

<main>
  <article>…</article>
  <aside>…</aside>
</main>

<footer>…</footer>

如果你嘗試在現代瀏覽器中使用螢幕閱讀器測試示例，你將會得到一些有用的資訊。例如，VoiceOver 會告訴你以下資訊：

• 在 <header> 元素上 - "banner, 2 items"（它包含一個標題和 <nav>）。
• 在 <nav> 元素上 - "navigation 2 items"（它包含一個列表和一個表單）。
• 在 <main> 元素上 - "main 2 items"（它包含一篇文章和一個側邊欄）。
• 在 <aside> 元素上 - "complementary 2 items"（它包含一個標題和一個列表）。
• 在搜尋表單輸入框上 - "Search query, insertion at beginning of text"。
• 在 <footer> 元素上 - "footer 1 item"。

如果你去 VoiceOver 的地標選單（使用 VoiceOver 鍵 + U 訪問，然後使用游標鍵迴圈瀏覽選單選項），你會發現大多數元素都被很好地列出來了，以便快速訪問。

但是，我們還可以做得更好。搜尋表單是一個非常重要的地標，人們會想要找到它，但它沒有列在地標選單中，也沒有被視為一個值得注意的地標，除了實際的輸入被識別為搜尋輸入框（<input type="search">）。

讓我們透過使用一些 ARIA 功能來改進它。首先，我們將新增一些 role 屬性到我們的 HTML 結構中。你可以嘗試複製我們的原始檔案（參見 index.html 和 style.css），或者導航到我們的 website-aria-roles 示例 (檢視即時示例)，它具有以下結構：

<header>
  <h1>…</h1>
  <nav role="navigation">
    <ul>
      …
    </ul>
    <form role="search">
      <!-- search form -->
    </form>
  </nav>
</header>

<main>
  <article role="article">…</article>
  <aside role="complementary">…</aside>
</main>

<footer>…</footer>

在這個示例中，我們還提供了一個額外的功能 - <input> 元素被賦予了屬性 aria-label，它為其提供了一個描述性標籤，即使我們沒有包含 <label> 元素，螢幕閱讀器也會讀出這個標籤。在這樣的情況下，這非常有用 - 像這樣的搜尋表單是一個非常常見且易於識別的功能，新增一個可視標籤會破壞頁面設計。

<input
  type="search"
  name="q"
  placeholder="Search query"
  aria-label="Search through site content" />

現在，如果我們使用 VoiceOver 檢視這個示例，我們會看到一些改進：

• 搜尋表單被識別為一個單獨的專案，無論是瀏覽頁面時還是在地標選單中。
• 當表單輸入被選中時，aria-label 屬性中包含的標籤文字會被讀出來。

除此之外，該網站更有可能對 IE8 等舊版瀏覽器的使用者可訪問；為了這個目的，包含 ARIA 角色是值得的。如果出於某種原因，你的網站只是使用 <div> 構建的，你絕對應該包含 ARIA 角色來提供這些急需的語義！

搜尋表單改進後的語義展示了 ARIA 在 HTML 可用語義之外所能實現的功能。你將在下面的內容中看到更多關於這些語義和 ARIA 屬性/特性功能的資訊，特別是在 非語義控制元件的可訪問性 部分。不過現在，讓我們看看 ARIA 如何幫助處理動態內容更新。

載入到 DOM 中的內容可以使用螢幕閱讀器輕鬆訪問，從文字內容到附加到影像的替代文字。因此，傳統的靜態網站，其內容主要為文字，對於視力障礙者來說很容易做到可訪問。

問題是，現代 Web 應用程式通常不僅僅是靜態文字 - 它們通常透過從伺服器獲取新內容並更新 DOM 來更新頁面的某些部分。這些有時被稱為 **即時區域**。

讓我們看一個簡單的例子 - 參見 aria-no-live.html（以及 檢視即時示例）。在這個示例中，我們有一個簡單的隨機引語框

<section>
  <h1>Random quote</h1>
  <blockquote>
    <p></p>
  </blockquote>
</section>

我們的 JavaScript 使用 fetch() API 透過包含一系列隨機引語及其作者的 JSON 檔案來載入內容。完成之後，我們啟動一個 setInterval() 迴圈，每 10 秒將一個新的隨機引語載入到引語框中

const intervalID = setInterval(showQuote, 10000);

這工作正常，但對於可訪問性來說並不理想 - 內容更新沒有被螢幕閱讀器檢測到，因此他們的使用者不知道發生了什麼。這是一個相當簡單的例子，但想象一下，如果你正在建立一個具有大量不斷更新內容的複雜 UI，比如聊天室、策略遊戲 UI 或者即時更新的購物車顯示 - 在沒有某種方法提醒使用者更新的情況下，無法以任何有效的方式使用該應用程式。

幸運的是，WAI-ARIA 提供了一種有用的機制來提供這些提醒 - aria-live 屬性。將其應用於某個元素會導致螢幕閱讀器讀出被更新的內容。內容被讀出的緊急程度取決於屬性值：

off

預設值。不應該宣佈更新。

polite

只有在使用者處於空閒狀態時才應宣佈更新。

assertive

應儘快向用戶宣佈更新。

我們希望你複製 aria-no-live.html 和 quotes.json，並更新你的 <section> 開啟標籤，如下所示：

<section aria-live="assertive">…</section>

這會導致螢幕閱讀器在內容被更新時讀出內容。

這裡還有一個額外的考慮 - 只有更新的那部分文字會被讀出來。如果我們始終讀出標題，這樣使用者可以記住正在讀出的內容，也許會更好。為了做到這一點，我們可以將 aria-atomic 屬性新增到該部分。再次更新你的 <section> 開啟標籤，如下所示：

<section aria-live="assertive" aria-atomic="true">…</section>

aria-atomic="true" 屬性告訴螢幕閱讀器將整個元素內容作為一個原子單元讀出來，而不僅僅是更新的部分。

如本模組其他地方所述，HTML 在可訪問性方面的一大優勢是內建的鍵盤可訪問性，例如按鈕、表單控制元件和連結。通常情況下，你可以使用 Tab 鍵在控制元件之間移動，使用 Enter/Return 鍵選擇或啟用控制元件，有時還需要使用其他控制元件（例如，使用向上和向下箭頭鍵在 <select> 框中的選項之間移動）。

但是，有時你最終需要編寫一些程式碼，這些程式碼要麼使用非語義元素作為按鈕（或其他型別的控制元件），要麼使用可聚焦控制元件來實現與預期目的不符的功能。你可能在嘗試修復你繼承的一些不良程式碼，或者你可能正在構建一些需要這種功能的複雜小部件。

在將不可聚焦的程式碼變為可聚焦的方面，WAI-ARIA 用一些新的值擴充套件了 tabindex 屬性：

• tabindex="0" - 如上所述，此值允許通常不可聚焦的元素變為可聚焦的。這是 tabindex 最有用的值。
• tabindex="-1" - 這允許通常不可聚焦的元素透過程式設計方式獲得焦點，例如透過 JavaScript，或者作為連結的目標。

我們在我們的 HTML 可訪問性文章中更詳細地討論了這一點，並展示了一個典型的實現 - 參見 重新構建鍵盤可訪問性。

這緊隨上一節 - 當一系列巢狀的 <div> 與 CSS/JavaScript 一起使用來建立複雜的 UI 功能，或者原生控制元件透過 JavaScript 大幅增強/改變時，不僅鍵盤可訪問性會受到影響，螢幕閱讀器使用者也會發現很難理解該功能的作用，因為沒有語義或其他線索。在這種情況下，ARIA 可以幫助提供這些缺失的語義。

表單驗證和錯誤提醒

首先，讓我們回顧一下我們在 CSS 和 JavaScript 可訪問性文章中首次看到的表單示例（閱讀 保持非侵入性 以獲取完整回顧）。在本節的末尾，我們展示了我們在錯誤訊息框上添加了一些 ARIA 屬性，該訊息框會在你嘗試提交表單時顯示任何驗證錯誤

<div class="errors" role="alert" aria-relevant="all">
  <ul></ul>
</div>

• role="alert" 會自動將它所應用的元素變成一個即時區域，因此對它的更改會被讀出來；它還在語義上將它識別為一個提醒訊息（重要的時效性/上下文相關資訊），並且代表了一種向用戶發出提醒的更佳、更易訪問的方式（像 alert() 呼叫這樣的模態對話方塊存在許多可訪問性問題；參見 WebAIM 的 彈出視窗）。
• aria-relevant 的值為 all，它指示螢幕閱讀器在對錯誤列表進行任何更改時（即新增或刪除錯誤時）讀出錯誤列表的內容。這很有用，因為使用者會想知道剩下的錯誤是什麼，而不僅僅是列表中添加了什麼或刪除了什麼。

我們可以進一步使用 ARIA，並提供更多驗證幫助。如何指示哪些欄位是必需的，以及年齡的範圍應該是多少呢？

1. 在這一點上，請複製我們的 form-validation.html 和 validation.js 檔案，並將它們儲存到本地目錄中。
2. 在文字編輯器中開啟它們，並檢視程式碼是如何工作的。
3. 首先，在 <form> 開啟標籤之前新增一個段落，就像下面這個一樣，並在表單 <label> 上標記一個星號。這通常是我們為視力正常的使用者標記必填欄位的方式。
   html

   <p>Fields marked with an asterisk (*) are required.</p>
   

4. 這在視覺上是有意義的，但對於螢幕閱讀器使用者來說並不容易理解。幸運的是，WAI-ARIA 提供了 aria-required 屬性，以便讓螢幕閱讀器提示他們告訴使用者哪些表單輸入需要填寫。請按以下方式更新 <input> 元素：
   html

   <input type="text" name="name" id="name" aria-required="true" />
   
   <input type="number" name="age" id="age" aria-required="true" />
   

5. 如果你現在儲存該示例並使用螢幕閱讀器測試它，你應該聽到類似 "Enter your name star, required, edit text" 的內容。
6. 為螢幕閱讀器使用者和有視力使用者提供年齡值應為多少的提示可能也很有用。 這通常以工具提示或佔位符的形式顯示在表單欄位中。 WAI-ARIA 確實包含 aria-valuemin 和 aria-valuemax 屬性來指定最小值和最大值，螢幕閱讀器支援本機 min 和 max 屬性。 另一個得到良好支援的功能是 HTML placeholder 屬性，它可以包含在輸入中未輸入任何值時顯示的訊息，並且可以由一些螢幕閱讀器朗讀。 像這樣更新您的數字輸入
   html

   <label for="age">Your age:</label>
   <input
     type="number"
     name="age"
     id="age"
     placeholder="Enter 1 to 150"
     required
     aria-required="true" />
   

始終為每個輸入包含一個 <label>。 雖然一些螢幕閱讀器會宣佈佔位符文字，但大多數不會。 為表單控制元件提供可訪問名稱的可接受替代方法包括 aria-label 和 aria-labelledby。 但是，帶有 for 屬性的 <label> 元素是首選方法，因為它為所有使用者提供了可用性，包括滑鼠使用者。

WAI-ARIA 還支援一些高階表單標記技術，超越了經典的 <label> 元素。 我們已經討論過使用 aria-label 屬性來提供標籤，我們不希望標籤對有視力使用者可見（參見上面的 路標/地標 部分）。 一些其他標記技術使用其他屬性，例如 aria-labelledby，如果您想指定一個非 <label> 元素作為標籤或用同一個標籤標記多個表單輸入，以及 aria-describedby，如果您想將其他資訊與表單輸入相關聯並將其也讀出來。 有關更多詳細資訊，請參閱 WebAIM 的高階表單標記文章。

還有許多其他有用的屬性和狀態，用於指示表單元素的狀態。 例如，aria-disabled="true" 可用於指示表單欄位已停用。 許多瀏覽器會跳過停用的表單欄位，從而導致螢幕閱讀器無法讀出它們。 在某些情況下，停用的元素會被感知，因此建議包含此屬性，以讓螢幕閱讀器知道停用的表單控制元件實際上是被停用的。

如果輸入的停用狀態可能發生變化，那麼在它發生時以及結果是什麼時也很有必要進行指示。 例如，在我們的 form-validation-checkbox-disabled.html 演示中，有一個複選框，當選中時，會啟用另一個表單輸入以允許輸入更多資訊。 我們已經設定了一個隱藏的即時區域

<p class="hidden-alert" aria-live="assertive"></p>

它使用絕對定位從檢視中隱藏。 當選中/取消選中時，我們更新隱藏的即時區域內的文字，以告知螢幕閱讀器使用者選中此複選框的結果，以及更新 aria-disabled 狀態和一些視覺指示器

function toggleMusician(bool) {
  const instruItem = formItems[formItems.length - 1];
  if (bool) {
    instruItem.input.disabled = false;
    instruItem.label.style.color = "#000";
    instruItem.input.setAttribute("aria-disabled", "false");
    hiddenAlert.textContent =
      "Instruments played field now enabled; use it to tell us what you play.";
  } else {
    instruItem.input.disabled = true;
    instruItem.label.style.color = "#999";
    instruItem.input.setAttribute("aria-disabled", "true");
    instruItem.input.removeAttribute("aria-label");
    hiddenAlert.textContent = "Instruments played field now disabled.";
  }
}

將非語義按鈕描述為按鈕

在本課程中，我們已經多次提到了（以及使用其他元素來偽造按鈕、連結或表單元素背後的可訪問性問題）按鈕、連結或表單元素的本機可訪問性（請參閱 HTML 可訪問性文章中的 UI 控制元件，以及上面的 增強鍵盤可訪問性）。 基本上，在許多情況下，您可以使用 tabindex 和一些 JavaScript 將鍵盤可訪問性添加回來，而不會遇到太多麻煩。

但是螢幕閱讀器呢？ 它們仍然不會將這些元素視為按鈕。 如果我們在螢幕閱讀器中測試我們的 fake-div-buttons.html 示例，我們的偽按鈕將使用諸如“點選我！，組”之類的短語進行報告，這顯然令人困惑。

我們可以使用 WAI-ARIA 角色來解決這個問題。 製作 fake-div-buttons.html 的本地副本，並向每個按鈕 <div> 新增 role="button"，例如

<div data-message="This is from the first button" tabindex="0" role="button">
  Click me!
</div>

現在，當您使用螢幕閱讀器嘗試此操作時，您將使用諸如“點選我！，按鈕”之類的短語來報告按鈕。 雖然這要好得多，但您仍然需要新增使用者期望的所有本機按鈕功能，例如處理 enter 和點選事件，如 button 角色文件 中所述。

引導使用者完成複雜的視窗小部件

還有許多其他 角色 可以將非語義元素結構識別為超越標準 HTML 中可用內容的常見 UI 功能，例如 combobox、slider、tabpanel、tree。 您可以在 Deque 大學程式碼庫 中看到幾個有用的示例，這些示例可以幫助您瞭解如何使這些控制元件變得可訪問。

讓我們來看一個我們自己的例子。 我們將回到我們簡單的絕對定位選項卡式介面（參見我們的 CSS 和 JavaScript 可訪問性文章中的 隱藏內容），您可以在 選項卡式資訊框示例 中找到它（參見 原始碼）。

這個示例本身在鍵盤可訪問性方面執行良好——您可以輕鬆地在不同的選項卡之間切換，並選擇它們來顯示選項卡內容。 它也很容易訪問——即使您看不到螢幕上發生了什麼，您也可以滾動瀏覽內容並使用標題進行導航。 但是，內容究竟是什麼並不那麼明顯——螢幕閱讀器當前將內容報告為連結列表，以及三個標題的一些內容。 它不會讓您瞭解內容之間的關係。 始終為使用者提供更多關於內容結構的線索是件好事。

為了改進，我們建立了示例的新版本，名為 aria-tabbed-info-box.html（檢視它正在執行）。 我們已經更新了選項卡式介面的結構，如下所示

<ul role="tablist">
  <li
    class="active"
    role="tab"
    aria-selected="true"
    aria-setsize="3"
    aria-posinset="1"
    tabindex="0">
    Tab 1
  </li>
  <li
    role="tab"
    aria-selected="false"
    aria-setsize="3"
    aria-posinset="2"
    tabindex="0">
    Tab 2
  </li>
  <li
    role="tab"
    aria-selected="false"
    aria-setsize="3"
    aria-posinset="3"
    tabindex="0">
    Tab 3
  </li>
</ul>
<div class="panels">
  <article class="active-panel" role="tabpanel" aria-hidden="false">…</article>
  <article role="tabpanel" aria-hidden="true">…</article>
  <article role="tabpanel" aria-hidden="true">…</article>
</div>

使用的 ARIA 功能包括

新角色 — tablist、tab、tabpanel

這些標識了選項卡式介面的重要區域——選項卡的容器、選項卡本身以及相應的選項卡面板。

aria-selected

定義當前選中的選項卡。 當用戶選擇不同的選項卡時，此屬性在不同選項卡上的值將透過 JavaScript 更新。

aria-hidden

隱藏元素，使其不被螢幕閱讀器讀出。 當用戶選擇不同的選項卡時，此屬性在不同選項卡上的值將透過 JavaScript 更新。

tabindex="0"

由於我們已經刪除了連結，因此我們需要為列表項提供此屬性，以使其具有鍵盤焦點。

aria-setsize

此屬性允許您向螢幕閱讀器指定元素是系列的一部分，以及系列中有多少個專案。

aria-posinset

此屬性允許您指定元素在系列中的位置。 與 aria-setsize 一起，它為螢幕閱讀器提供了足夠的資訊來告訴您您當前位於專案“1 of 3”等。 在許多情況下，瀏覽器應該能夠從元素層次結構中推斷出此資訊，但這確實有助於提供更多線索。

在我們的測試中，這種新的結構確實在總體上有所改進。 選項卡現在被識別為選項卡（例如，螢幕閱讀器會說“選項卡”），選中的選項卡透過在選項卡名稱中讀出“選中”來指示，螢幕閱讀器還會告訴您您當前位於哪個選項卡編號。 此外，由於 aria-hidden 設定（只有未隱藏的選項卡的 aria-hidden="false" 設定），未隱藏的內容是您唯一可以向下導航的內容，這意味著選中的內容更容易找到。

您已經到達了本文的結尾，但是您還記得最重要的資訊嗎？ 您可以在繼續之前找到一些進一步的測試來驗證您是否保留了此資訊——請參閱 測試您的技能：WAI-ARIA。

本文絕不是涵蓋了 WAI-ARIA 中所有可用的內容，但它應該為您提供了足夠的資訊來了解如何使用它，並瞭解一些需要它的最常見模式。

• Aria 狀態和屬性：所有 aria-* 屬性
• WAI-ARIA 角色：ARIA 角色的類別以及 MDN 上涵蓋的角色
• HTML 中的 ARIA 在 W3C 上：一個規範，它為每個 HTML 功能定義瀏覽器隱式應用於它的可訪問性 (ARIA) 語義以及在需要額外語義時可以在它上面設定的 WAI-ARIA 功能
• Deque 大學程式碼庫：一個非常有用和實用的示例庫，展示了使用 WAI-ARIA 功能使複雜 UI 控制元件變得可訪問。
• WAI-ARIA 創作實踐 在 W3C 上：來自 W3C 的一個非常詳細的設計模式，解釋瞭如何在實現不同型別的複雜 UI 控制元件的同時，使用 WAI-ARIA 功能使其變得可訪問。

• 上一個
• 概述：無障礙性
• 下一個