對螢幕閱讀器沒有加鹽時，對螢幕閱讀器的無障礙程度會有多大的減緩！
什麼是 ARIA？
ARIA 可讓網頁作者打造另類實境，但只有螢幕閱讀器才會看到 🤥?
有時，有時必須根據事實或最恰當的「假說」來展開螢幕閱讀器，瞭解網頁內容的情況。例如「專注在這裡！」或「這真的是滑桿！」。這就像是在工作台上為各種工具和小工具添加魔法便利貼。這些具有特殊性的便利貼，可以讓每個人都能相信自己寫出的內容。
每當有魔術便利貼時，它可能會覆寫我們對每項工具的看法，或是對工具的看法。例如：「這上面那樣是黏液槍！」。雖然這實際上在工作台上仍為一個空的藍色盒子，但魔術便利貼會讓我們看到它是黏膠。我們還可以加上「而且已經滿 30%！」。螢幕閱讀器現在會回報 那裡有 30% 的膠囊
在網路中，等同於使用圖片的純方塊元素 (div)，並使用 ARIA 表示這是大小為 30 的滑桿 (滿分 100)。
什麼是 ARIA？
ARIA 不會影響網頁外觀，也不會影響滑鼠或鍵盤使用者的行為。只有輔助技術的使用者才會注意到 ARIA 有任何差異。網頁程式開發人員可以新增任意 ARIA，而不會影響沒有執行輔助技術的使用者。
說得沒錯：ARIA 實際不會執行鍵盤焦點或分頁順序的任何操作。這一切都是透過 HTML 完成，有時則是稍微修改 JavaScript
ARIA 如何運作？
瀏覽器會要求螢幕閱讀器或其他輔助技術，要求瀏覽器提供每個元素的相關資訊。當元素呈現 ARIA 時，瀏覽器會接收相關資訊，並變更向螢幕閱讀器告知該元素的內容。
為什麼要使用 ARIA？
我們為什麼會不想騙我們的使用者的心！？
假設本地網路商店賣掉的是我們需要的小工具。但我們是 MacGyver dammit。我們可以用其他小工具 自行開發小工具FWIW，MacGyver 最常使用的七個東西是瑞士軍刀、口香糖、鞋子、比對、紙夾、生日蠟燭和紙膠帶。他用來製造炸彈和其他東西，不單只是隨便攜帶。這與需要建立選單列的網頁作者非常類似。選單列很實用，您可能會以為它們會融入 HTML 當中，但則不然。這個嘛！你覺得作者對連結和按鈕不滿意嗎？因此，作者會使用他們喜愛的工具組合在一起，包括 div、圖片、樣式、點按處理常式、按鍵處理常式、便條和 ARIA。
有時候，我們不會使用 ARIA 代表最大值，而是直接用來強化功能。在一些基本上已可運作的 HTML 上減少一些 ARIA，會很有幫助。例如，我們希望表單控制項指向與某些無效輸入內容相關的錯誤訊息快訊。或是指定文字方塊用於搜尋這些微調可讓一般網站更容易搭配螢幕閱讀器使用。
選單列範例
支援滑鼠點擊使用者
一起建立選單列吧。我們會使用稱為 div 的通用盒子元素顯示很多項目。只要使用者按一下 div，就會執行對應的指令。太棒了，這個方法非常適合滑鼠點擊的使用者！
接著我們要調整它外觀我們採用 CSS 技術，例如樣式、妥善貼合項目，並在這些元素周圍加入視覺外框。並確保選單列的外觀與其他選單列十分相似，使用者一看就能知道選單列是選單列和使用方式。甚至，我們的選單列甚至會針對滑鼠懸停的任何項目使用不同的背景顏色，為使用者提供實用的視覺回饋。
某些選單項目是父項。可產生子選單。當使用者將滑鼠遊標懸停在其中一個項目上時，我們就會啟動滑動子項子選單的動畫。
當然，這些內容完全無法存取，就像網路上許多事物的常見情況一樣，這很大程度是因為 HTML 標準精靈沒有新增網頁作者所需的所有項目。即使他們確實如此，網頁作者也總是會想自行發明特殊版本。
打造無障礙選單列鍵盤
首先，我們來新增鍵盤無障礙功能。這個部分只會使用 HTML，不會使用 ARIA。提醒您，ARIA 不會影響非輔助技術使用者的核心層面，例如外觀、滑鼠或鍵盤。
就像網頁可以回應滑鼠動作一樣，也可以回應鍵盤。我們的 JavaScript 會監聽所有出現的按鍵動作，並判斷按鍵是否實用。否則，系統會將訊息傳回頁面，就像是小魚無法吃的魚一樣。我們的規則如下：
- 如果使用者按下方向鍵，我們來看看內部選單列的藍圖，並決定使用中的選單項目。我們會清除現有的醒目顯示內容，並醒目顯示新的選單項目，讓視障使用者一看就知道他們的所在位置。接著網頁應呼叫
event.preventDefault()，避免瀏覽器執行常用操作 (在本例中為捲動頁面)。 - 如果使用者按下 Enter 鍵，我們就可以像點選滑鼠一樣處理，然後執行適當的動作 (或開啟其他選單)。
- 如果使用者按下的按鍵可以執行其他操作，請不要使用它！ 依預期性質傳回網頁。例如，我們的選單列不需要 Tab 鍵，因此將其丟回！這很難做到正確答案，作者常常會搞砸了。例如，選單列需要使用方向鍵，但不能使用 Alt + 方向鍵或 Command + 方向鍵。這些是您移至瀏覽器分頁網頁記錄中上一個或下一頁的快速鍵。如果作者不謹慎，選單列便會使用這些內容。這類錯誤經常發生 我們甚至尚未開始使用 ARIA！
使用螢幕閱讀器存取選單列
我們的選單列採用膠帶和 div。因此，螢幕閱讀器無從瞭解其內容。使用中項目的背景顏色只是顏色。選單項目 div 只是無特定意義的純物件，因此，選單列的使用者無法看到要按下哪個按鍵，或按下哪個項目的指示。
但不公平！選單列非常適合視視覺的使用者使用。
ARIA 指向救援。ARIA 可讓我們假定聚焦在選單列中的螢幕閱讀器。如果作者正確執行所有動作，自訂選單列在螢幕閱讀器上的外觀就會如同電腦應用程式中的選單列。
我們的第一個 ARIA 代表用 aria-activedescendant 屬性，並將其設為目前使用中選單項目的 ID，只要項目有所變更，請務必小心更新。例如：aria-activedescendant="settings-menuitem"。這樣一來，螢幕閱讀器會將 ARIA 有效項目視為焦點，會朗讀或顯示在點字顯示器上。
「子系」一詞是指某個項目包含在另一個項目中的情況，相反詞是祖系，用於表示某個項目屬於祖系。針對下一個容器向上/向下，這些參數可能會使用較具體的字詞父項/子項。舉例來說，假設有一個段落內含一個連結，連結的父項是段落，但同時包含該文件的祖系。 相反地，文件可以有多個段落子項，每個段落都有連結。這些連結都是祖父文件的所有子系。
返回「aria-activedescendant」。透過使用這個元件，從聚焦的選單列指向特定選單項目，螢幕閱讀器現在可以知道使用者移動了什麼位置，但不會知道物件的其他內容。這個 div 是什麼？這時角色屬性就能派上用場。我們會針對整個包含的元素使用 role="menubar"，然後在項目群組中使用 role="menu"，針對個別選單項目使用 role="menuitem"。
如果菜單項目可導向子選單，該怎麼辦？使用者需要知道正確的項目嗎？對視障使用者來說，選單尾端可能有一點三角形圖片，但螢幕閱讀器至少不知道該怎麼自動閱讀圖片。我們可以為每個可展開的選單項目加上 aria-expanded="false"，藉此指出 1) 有可展開的項目，以及 2) 目前未展開。新增輕觸後，作者應將 role="none" 放在圖示三角形上，藉此表示該標記僅供修飾之用。這個做法可避免螢幕閱讀器朗讀圖片本身最可能令人感到多餘且可能造成乾擾的內容。
處理錯誤
鍵盤錯誤 (HTML!)
雖然鍵盤存取是核心 HTML 的一部分，但是作者經常會搞怪，因為他們不常使用鍵盤瀏覽功能，或者是因為該做的細節難以正確執行。
錯誤示例：
- 核取方塊使用空格鍵進行切換，但作者忘記呼叫
preventDefault()。現在，空白鍵會同時切換核取方塊和分頁功能，這也是空格鍵的預設瀏覽器行為。 - ARIA 強制回應對話方塊想要將分頁導覽置於其中，且作者忘記允許 Control + Tab 進入瀏覽器。現在，Control + Tab 鍵可以在對話方塊內瀏覽，而且不會像往常一樣切換瀏覽器中的分頁。唉唷。
- 作者會建立選取清單並實作上/下實作，但不會實作 Home/end/pageup/pagedown 或第一個字母導覽。
作者應遵循已知的模式。詳情請參閱資源一節。
如果遇到純鍵盤存取問題，建議您在不啟用螢幕閱讀器 (或關閉虛擬瀏覽器模式) 的情況下試用。一般來說，螢幕閱讀器不需要發現鍵盤錯誤，而且鍵盤存取權實際上是使用 HTML，而非 ARIA 實作。畢竟，ARIA 不會影響鍵盤或滑鼠行為等基本設定，只會讓螢幕閱讀器瞭解網頁的內容、當前聚焦的項目等。
鍵盤錯誤幾乎總是是網頁內容中的錯誤，尤其是在 HTML 和 JavaScript 中，在 ARIA 中也不例外。
ARIA 錯誤：為什麼會這麼多？
在許多地方，作者都可能會犯錯 ARIA，而每個地方都會導致完全中斷或有些微差異。有些微妙之處則較糟，因為作者在發布前不會找到大部分的內容。
畢竟，除非作者是經驗豐富的螢幕閱讀器使用者，否則 ARIA 會發生問題。在選單列的範例中，作者可能會認為如果「menuitem」正確時，作者會認為「選項」角色。使用者可能會忘記使用 aria-expanded、忘了在適當時機設定並清除 aria-activedescendant，或忘記使用包含其他選單的選單列。選單項目的數量呢？螢幕閱讀器通常會提供選單項目，例如「第 3 項，共 5 項」，讓使用者知道選單項目的位置。瀏覽器通常會自動計算次數，但在某些情況下，瀏覽器可能會計算錯誤的數字，且作者必須使用 aria-posinset 和 aria-setsize 覆寫這些數字。
這裡只是選單列想出有幾種小工具，如有需要，可以瀏覽 ARIA 規格或授權做法。每種模式都可能濫用 ARIA 的幾種方式。ARIA 仰賴作者瞭解自己在做什麼。由於大部分的作者並非螢幕閱讀器，因此可能發生問題？
換句話說，實際螢幕閱讀器使用者沒有太多細微差異，在理想情況下，我們會嘗試各種不同的瀏覽器螢幕閱讀器組合，因為除了一些未完成的實作項目，還有許多實作上的難題。
摘要
總而言之，ARIA 魔法可用來覆寫或新增 HTML 程式碼所指出的所有內容。您可以運用這項工具稍微變更無障礙簡報，或打造完整的體驗。正因如此，對於我們友善的當地網路作者來說，雖然不常使用螢幕閱讀器，因為 ARIA 不僅功能強大，而且也非常危險。
ARIA 只是一個簡單的真值覆寫標記層。當螢幕閱讀器詢問情況時，如果 ARIA 存在，則會取得 ARIA 版本的真相，而不是真正的基礎資料。
附加條款 1：其他資源
包含鍵盤資訊和程式碼範例的混合式參考資料
- W3C 的 ARIA 編寫做法：本文件說明每個範例的重要鍵盤導覽特性，並提供有效的 JS/CSS/ARIA 程式碼。以下舉例著重於目前可行的做法，但不包括行動裝置。
附錄 2：最常使用 ARIA 的情況為何？
因為 ARIA 可以取代或補充各種資料內容，通常有助於朗讀螢幕閱讀器重視的內容。
以下是 ARIA 的常見用途。
- HTML 中沒有特殊小工具，例如選單列、自動完成、樹狀結構或試算表
- 位於 HTML 的小工具，但作者仍自行發明，可能是因為他們需要調整一般小工具的行為或外觀。舉例來說，HTML
<input type="range">元素基本上是滑桿，但作者希望讓元素看起來更不同。大多數情況下，都可以使用 CSS，但如果是input type="range"，CSS 無法正常運作。作者可以建立自己的滑桿，並對其使用role="slider"搭配aria-valuenow表示目前的值。 - 即時區域會告知螢幕閱讀器「本頁的這個區域，任何變動的內容都值得使用者瞭解」。
- 地標 (HTML 現已失效)。搜尋結果的運作模式有點類似標題，可幫助螢幕閱讀器使用者更快找到所需內容。但差別在於其中包含整個相關區域。例如「這個容器是網頁的主要區域」和「這個容器位於這裡是導覽面板」。
附加條款 3：什麼是 Accessibility API？
無障礙 API 是螢幕閱讀器或其他 AT 如何瞭解網頁內容和目前發生的內容。範例包括 MSAA、IA2 和 UIA。這只不過是 Windows 了！無障礙 API 包含兩個部分：
- 代表容器階層的物件「樹狀結構」。這就像俄羅斯娃娃 但每個娃娃可以包含多種其他娃娃。例如，文件可以包含多個段落，一個段落可包含文字、圖片、連結和粗體等元素。物件樹狀結構中的每個項目都可以有角色 (也就是角色、名稱/標籤、使用者輸入的值、說明) 和布林值狀態 (例如可聚焦、聚焦、必要、已勾選) 等屬性。ARIA 可以覆寫這些屬性。螢幕閱讀器會使用樹狀結構，協助使用者以虛擬緩衝區模式瀏覽內容，例如「前往下一個標題」。
- 關於樹狀結構變更的一系列事件，例如「焦點現已移至此處！」。螢幕閱讀器會透過事件讓使用者瞭解發生的情況。當重要的 HTML 或 ARIA 標記有所變更時，系統會觸發事件，讓螢幕閱讀器知道發生變更內容。
通常作者只會使用 HTML 程式碼，與這些無障礙 API 完美對應。如果 HTML 不夠安全，系統會使用 ARIA 且瀏覽器會先覆寫 HTML 語意，然後再將物件樹狀結構或事件傳送至螢幕閱讀器。