處理常見的無障礙問題

當我們在網路技術領域談論可訪問性時，大多數人會立即想到確保網站/應用程式對殘疾人可用，例如

• 視障人士使用螢幕閱讀器或放大/縮放功能訪問文字。
• 有運動功能障礙的人使用鍵盤（或其他非滑鼠功能）啟用網站功能。
• 聽障人士依靠字幕/旁白或其他文字替代品來獲取音訊/影片內容。

然而，說可訪問性僅僅關乎殘疾人是錯誤的。實際上，可訪問性的目標是使您的網站/應用程式儘可能多的人在儘可能多的情況下都能使用，而不僅僅是那些使用高效能臺式電腦的使用者。一些例子可能包括

• 移動裝置使用者。
• 使用電視、手錶等替代瀏覽裝置的使用者。
• 使用可能沒有最新瀏覽器的舊裝置的使用者。
• 使用可能處理器速度較慢的低規格裝置的使用者。

從某種意義上說，整個模組都是關於可訪問性的——跨瀏覽器測試確保您的網站能夠儘可能多的人使用。 什麼是可訪問性？ 比這篇文章更全面、更徹底地定義了可訪問性。

也就是說，本文將涵蓋圍繞殘疾人以及他們如何使用網路的跨瀏覽器和測試問題。我們已經討論了其他領域，例如 響應式設計 和 效能，這些內容在模組的其他地方有介紹。

在本節中，我們將詳細介紹圍繞網路可訪問性出現的一些主要問題，這些問題與特定技術相關，以及需要遵循的最佳實踐，以及您可以進行的一些快速測試，以檢視您的網站是否朝著正確的方向發展。

語義 HTML（元素按其正確目的使用）本身就是可訪問的——這種內容可以被有視力的人閱讀（只要你不做一些愚蠢的事情，比如將文字設定得過小或使用 CSS 隱藏它），但它也可以被輔助技術使用，比如螢幕閱讀器（字面上將網頁讀給使用者的應用程式），並帶來其他優勢。

語義結構

語義 HTML 中最重要的快速獲勝是使用標題和段落結構來組織您的內容；這是因為螢幕閱讀器使用者傾向於使用文件的標題作為路標，以便更快地找到他們需要的內容。如果您的內容沒有標題，他們得到的就是一大塊沒有路標的文字牆，什麼也找不到。不良和良好 HTML 示例

<font size="7">My heading</font>
<br /><br />
This is the first section of my document.
<br /><br />
I'll add another paragraph here too.
<br /><br />
<font size="5">My subheading</font>
<br /><br />
This is the first subsection of my document. I'd love people to be able to find
this content!
<br /><br />
<font size="5">My 2nd subheading</font>
<br /><br />
This is the second subsection of my content. I think it is more interesting than
the last one.

<h1>My heading</h1>

<p>This is the first section of my document.</p>

<p>I'll add another paragraph here too.</p>

<h2>My subheading</h2>

<p>
  This is the first subsection of my document. I'd love people to be able to
  find this content!
</p>

<h2>My 2nd subheading</h2>

<p>
  This is the second subsection of my content. I think it is more interesting
  than the last one.
</p>

此外，您的內容在原始碼順序上應該有邏輯意義——您始終可以使用 CSS 將其放置到您想要的位置，但您應該從一開始就將原始碼順序設定正確。

作為測試，您可以關閉網站的 CSS，看看沒有它內容是否仍然易於理解。您可以透過手動從程式碼中刪除 CSS 來執行此操作，但最簡單的方法是使用瀏覽器功能，例如

• Firefox：從主選單中選擇檢視 > 頁面樣式 > 無樣式。
• Safari：從主選單中選擇開發 > 停用樣式（要啟用開發選單，請從Safari > 偏好設定 > 高階 > 在選單欄中顯示開發選單）。
• Chrome：安裝 Web Developer Toolbar 擴充套件程式，然後重啟瀏覽器。點擊出現的齒輪圖示，然後選擇CSS > 停用所有樣式。
• Edge：從主選單中選擇檢視 > 樣式 > 無樣式。

使用原生鍵盤可訪問性

某些 HTML 功能可以使用鍵盤進行選擇——這是預設行為，自網路早期以來一直可用。具有此功能的元素是允許使用者與網頁互動的常見元素，即連結、<button> 和表單元素，如 <input>。

您可以使用我們的 native-keyboard-accessibility.html 示例（參見 原始碼）來試一試——在一個新標籤頁中開啟它，然後嘗試按 Tab 鍵；按幾次之後，您應該會看到 Tab 焦點開始在不同的可聚焦元素之間移動；聚焦元素在每個瀏覽器中都帶有高亮的預設樣式（在不同的瀏覽器之間略有不同），這樣您就可以知道哪個元素是聚焦的。

然後您可以按 Enter/Return 鍵來跟隨聚焦的連結或按下按鈕（我們已經包含了一些 JavaScript 來使按鈕顯示一條訊息），或者開始輸入文字以在文字輸入框中輸入文字（其他表單元素有不同的控制元件，例如 <select> 元素可以使用向上和向下箭頭鍵顯示其選項並迴圈瀏覽它們）。

請注意，不同的瀏覽器可能具有不同的鍵盤控制選項。大多數現代瀏覽器都遵循上面描述的 Tab 模式（您也可以使用 Shift + Tab 向後移動可聚焦元素），但有些瀏覽器有自己的怪癖

• Mac 上的 Safari 預設情況下不允許您使用 Tab 鍵瀏覽連結；要啟用此功能，請開啟系統設定，向下滾動到鍵盤，然後啟用鍵盤導航。如果您使用的是舊版本的 macOS，請參閱 Apple 的 macOS 使用者指南中的 使用鍵盤模擬滑鼠操作。

此示例突出了使用正確的語義元素來完成正確工作的必要性。可以使用 CSS 將任何元素的樣式設定為看起來像連結或按鈕，並可以使用 JavaScript 使其像連結或按鈕一樣工作，但它們實際上不是連結或按鈕，您將失去這些元素為您免費提供的許多可訪問性。因此，如果可以避免，請不要這樣做。

另一個技巧——如我們的示例所示，您可以使用 :focus 偽類來控制可聚焦元素在聚焦時的外觀。最好將焦點和懸停樣式結合起來，以便使用者獲得視覺提示，告訴他們控制元件在啟用時會執行操作，無論他們使用的是滑鼠還是鍵盤

a:hover,
input:hover,
button:hover,
select:hover,
a:focus,
input:focus,
button:focus,
select:focus {
  font-weight: bold;
}

構建鍵盤可訪問性

有時無法避免失去鍵盤可訪問性。您可能繼承了一個語義不太好的網站（也許您最終使用了一個生成由 <div> 構成的按鈕的糟糕 CMS），或者您正在使用一個沒有內建鍵盤可訪問性的複雜控制元件，比如 HTML <video> 元素（令人驚訝的是，Opera 是唯一一個允許您使用 Tab 鍵瀏覽 <video> 元素的預設瀏覽器控制元件的瀏覽器）。您在這裡有幾個選擇

1. 使用 <button> 元素（我們可以預設使用 Tab 鍵訪問！）和 JavaScript 建立自定義控制元件，以連線它們的功能。參見 建立跨瀏覽器影片播放器，其中包含一些很好的示例。
2. 透過 JavaScript 建立鍵盤快捷鍵，以便在您按鍵盤上的某些鍵時啟用功能。參見 桌面滑鼠和鍵盤控制元件，其中包含一些遊戲相關示例，可以適應任何目的。
3. 使用一些有趣的策略來模擬按鈕行為。例如，我們的 fake-div-buttons.html 示例（參見 原始碼）。在這裡，我們賦予了假的 <div> 按鈕可以被聚焦的能力（包括透過 Tab 鍵），方法是為每個按鈕新增 tabindex="0" 屬性（參見 WebAIM 的 tabindex 文章，其中包含更多非常有用的細節）。這允許我們使用 Tab 鍵聚焦按鈕，但不能使用 Enter/Return 鍵啟用它們。為此，我們必須新增以下 JavaScript 技巧
   js

   document.onkeydown = (e) => {
     if (e.code === "Enter") {
       // The Enter/Return key
       document.activeElement.onclick(e);
     }
   };
   

   在這裡，我們向 document 物件添加了一個監聽器，以檢測何時在鍵盤上按下按鈕。我們透過事件物件的 code 屬性檢查按下了哪個按鈕；如果它與 Return/Enter 匹配，我們使用 document.activeElement.onclick() 執行儲存在按鈕的 onclick 處理程式中的函式。 activeElement 為我們提供了當前在頁面上聚焦的元素。

文字替代

文字替代對於可訪問性非常重要——如果一個人有視覺或聽力障礙，無法看到或聽到某些內容，那麼就會有問題。最簡單的文字替代方法是簡單的 alt 屬性，我們應該將其包含在所有包含相關內容的影像上。這應該包含對影像的描述，以便成功地傳達其在頁面上的含義和內容，以便螢幕閱讀器可以讀取它並讀給使用者聽。

缺少 alt 文字可以透過多種方式進行測試，例如使用輔助功能 審計工具。

對於影片和音訊內容，alt 文字稍微複雜一些。有一種方法可以定義文字軌道（例如字幕）並在播放影片時顯示它們，以 <track> 元素和 WebVTT 格式的形式（有關詳細教程，請參閱 向 HTML 影片新增字幕）。這些功能的 瀏覽器相容性 很好，但如果您想為音訊提供文字替代或支援較舊的瀏覽器，在頁面上的某個位置或單獨的頁面上提供一個簡單的文字轉錄可能是個好主意。

元素關係和上下文

HTML 中有一些功能和最佳實踐旨在提供上下文和元素之間的關係，而這些關係在其他情況下不存在。三個最常見的示例是連結、表單標籤和資料表。

無障礙連結文字的關鍵在於，使用螢幕閱讀器的人員通常會使用一種通用功能，即拉起頁面上所有連結的列表。在這種情況下，連結文字需要在上下文中說得通。例如，標記為“點選此處”、“點選我”等的連結列表對於無障礙來說非常糟糕。連結文字最好在上下文中和非上下文中都有意義。

接下來是我們的表單 <label> 元素，它是使表單無障礙的核心功能之一。表單的問題在於，您需要標籤來說明應該在每個表單輸入中輸入什麼資料。每個標籤都需要包含在 <label> 中，以便將其明確地連結到其對應的表單輸入（每個 <label> 的 for 屬性值需要與表單元素 id 值匹配），即使源順序不是完全合乎邏輯的（公平地說，它應該）。

最後，簡要介紹一下資料表。基本資料表可以使用非常簡單的標記編寫（參見 bad-table.html 即時 和 原始碼），但它存在問題——螢幕閱讀器使用者無法將行或列關聯起來作為資料分組——要做到這一點，您需要知道標題行是什麼，以及它們是標題行、列等。對於這樣的表格，這隻能透過視覺方式完成。

如果您改為檢視 punk-bands-complete.html 示例（即時，原始碼），您會看到一些輔助功能在這裡發揮作用，例如表格標題（<th> 和 scope 屬性）、<caption> 元素等。

CSS 往往提供的基本無障礙功能比 HTML 少，但如果使用不當，它仍然可能對無障礙造成同樣大的損害。我們已經提到了幾個涉及 CSS 的無障礙提示。

• 使用正確的語義元素在 HTML 中標記不同的內容；如果您想建立不同的視覺效果，請使用 CSS——不要濫用 HTML 元素來獲得您想要的樣式。例如，如果您想要更大的文字，請使用 font-size，而不是 h1 元素。
• 確保您的源順序在沒有 CSS 的情況下有意義；您可以始終使用 CSS 以任何您想要的方式為頁面設定樣式。
• 您應該確保按鈕和連結等互動式元素具有適當的焦點/懸停/活動狀態設定，以向用戶提供關於其功能的視覺提示。如果您出於樣式原因刪除了預設值，請確保您包含一些替換樣式。

您應該考慮其他一些因素。

顏色和顏色對比度

在為您的網站選擇配色方案時，您應該確保文字（前景）顏色與背景顏色形成良好的對比。您的設計可能看起來很酷，但如果患有色盲等視力障礙的人無法閱讀您的內容，那它就沒有什麼用。使用 WebAIM 的 顏色對比度檢查器 等工具來檢查您的方案是否對比度足夠。

另一個提示是不要僅僅依靠顏色來表示路標/資訊，因為這對那些看不見顏色的人來說毫無用處。例如，不要用紅色標記必填表單欄位，而是用星號標記，並且用紅色標記。

隱藏內容

在很多情況下，視覺設計要求並非所有內容都同時顯示。例如，在我們的 選項卡式資訊框示例（參見 原始碼）中，我們有三個資訊面板，但我們將它們 定位 在彼此之上，並提供可以點選的選項卡以顯示每個面板（它也可以用鍵盤訪問——您也可以使用 Tab 和 Enter/Return 來選擇它們）。

螢幕閱讀器使用者並不關心這些——只要源順序有意義，他們就可以訪問所有內容，他們就滿意了。絕對定位（如在此示例中使用）通常被視為隱藏內容以產生視覺效果的最佳機制之一，因為它不會阻止螢幕閱讀器訪問它。

另一方面，您不應該使用 visibility: hidden 或 display: none，因為它們會將內容從螢幕閱讀器中隱藏。當然，除非您有充分的理由要將這些內容從螢幕閱讀器中隱藏。

JavaScript 在無障礙方面與 CSS 存在相同的問題——如果使用不當或過度使用，它可能會對無障礙造成災難性的影響。我們已經暗示了一些與 JavaScript 相關的無障礙問題，主要是在語義 HTML 領域——您應該始終使用適當的語義 HTML 來實現功能，無論它在哪裡可用，例如，根據需要使用連結和按鈕。如果可能，不要使用帶有 JavaScript 程式碼的 <div> 元素來偽造功能——這很容易出錯，而且比使用 HTML 提供給您的免費功能更費力。

簡單功能

通常，簡單功能應該僅使用 HTML 就可以實現——JavaScript 應該只用於增強功能，而不是完全構建它。JavaScript 的良好用途包括

• 提供客戶端表單驗證，它可以快速向用戶發出有關其表單條目問題的警報，而無需等待伺服器檢查資料。如果沒有，表單仍然可以使用，但驗證可能會更慢。
• 為 HTML <video> 提供自定義控制元件，使這些控制元件對僅鍵盤使用者可訪問（如前所述，大多數瀏覽器中的預設瀏覽器控制元件對鍵盤不可訪問）。

更復雜的 JavaScript 實現可能會導致無障礙問題——您需要盡力而為。例如，期望您使使用 WebGL 編寫的複雜 3D 遊戲對盲人 100% 無障礙是不合理的，但您可以實現 鍵盤控制，使其對非滑鼠使用者可用，並使配色方案對比度足夠高，以便色覺缺陷者可以使用。

複雜功能

對於無障礙來說，主要存在問題的領域之一是涉及複雜表單控制元件（如日期選擇器）和經常且增量更新的動態內容的複雜應用程式。

非本機複雜表單控制元件存在問題，因為它們往往涉及許多巢狀的 <div>，而瀏覽器預設情況下不知道如何處理它們。如果您自己發明它們，您需要確保它們可以透過鍵盤訪問；如果您使用某種第三方框架，請仔細檢視可用的選項，以瞭解它們的可訪問性，然後再開始使用它們。例如，Bootstrap 在可訪問性方面看起來還不錯，儘管 Rhiana Heath 的 使 Bootstrap 更具可訪問性 探討了它的一些問題（主要與顏色對比度相關），並提供了一些解決方案。

定期更新的動態內容可能成為一個問題，因為螢幕閱讀器使用者可能會錯過它，尤其是如果它意外更新。如果您有一個使用 XMLHttpRequest 或 Fetch 定期更新主內容面板的單頁應用程式，螢幕閱讀器使用者可能會錯過這些更新。

WAI-ARIA

您是否需要使用這種複雜的功能，或者簡單的語義 HTML 就足夠了？如果您確實需要複雜性，您應該考慮使用 WAI-ARIA（可訪問的富網際網路應用程式），它是一種規範，為複雜表單控制元件和更新面板等專案提供語義（以新的 HTML 屬性的形式），這些語義可以被大多數瀏覽器和螢幕閱讀器理解。

為了處理複雜的表單小部件，您需要使用 ARIA 屬性（如 roles）來宣告不同元素在小部件中的作用（例如，它們是選項卡還是選項卡面板？）、aria-disabled 來宣告控制元件是否被停用等。

為了處理定期更新的內容區域，您可以使用 aria-live 屬性，它標識一個更新區域。它的值指示螢幕閱讀器應以多快的速度讀出它。

• off: 預設值。不應宣佈更新。
• polite: 只有在使用者空閒時才會宣佈更新。
• assertive: 應儘快向用戶宣佈更新。

以下是一個示例

<p><span id="LiveRegion1" aria-live="polite" aria-atomic="false"></span></p>

您可以在 Freedom Scientific 的 ARIA（可訪問的富網際網路應用程式）即時區域 示例中看到一個實際示例——突出顯示的段落應每 10 秒更新一次內容，螢幕閱讀器應該將此讀出給使用者。 ARIA 即時區域 - 原子 提供了另一個有用的示例。

我們沒有足夠的空間在這裡詳細介紹 WAI-ARIA，您可以在 WAI-ARIA 基礎知識 中瞭解更多資訊。

現在，我們已經介紹了不同 Web 技術的無障礙注意事項，包括一些測試技術（如鍵盤導航和顏色對比度檢查器），讓我們來看看在進行無障礙測試時可以使用哪些其他工具。

有很多可用的審計工具，你可以將你的網頁輸入到這些工具中。它們會審查你的網頁並返回頁面上存在的無障礙問題列表。讓我們看一個例子，使用Wave，這是一個線上無障礙測試工具，它接受網頁地址並返回該頁面的帶註釋檢視，突出顯示無障礙問題。

1. 訪問Wave 主頁。
2. 將我們bad-semantics.html 示例的 URL 輸入到頁面頂部附近的文字輸入框中。然後按回車鍵或單擊/點選輸入框最右側的箭頭。
3. 該網站應該會返回對無障礙問題的描述。單擊顯示的圖示，以檢視有關 Wave 評估識別的每個問題的更多資訊。

Deque 的 aXe 工具 比我們上面提到的審計工具更進一步。與其他工具一樣，它檢查頁面並返回無障礙錯誤。它最直接有用的形式可能是瀏覽器擴充套件

• Chrome 版 aXe
• Firefox 版 aXe

這些擴充套件將在瀏覽器開發者工具中新增一個無障礙選項卡。例如，我們安裝了 Firefox 版本，然後使用它來審計我們bad-table.html 示例。我們得到了以下結果

aXe 也可以使用npm安裝，並且可以與像Grunt 和Gulp 這樣的任務執行器、像Selenium 和Cucumber 這樣的自動化框架、像Jasmine 這樣的單元測試框架以及更多其他工具整合（同樣，有關詳細資訊，請參閱aXe 主頁）。

使用螢幕閱讀器進行測試絕對值得，這樣你就能習慣視力嚴重障礙者如何使用網路。有很多螢幕閱讀器可用

• 有些是付費的商業產品，比如JAWS（Windows）。
• 有些是免費產品，比如NVDA（Windows）、ChromeVox（Chrome、Windows 和 macOS）以及Orca（Linux）。
• 有些是內置於作業系統中的，比如VoiceOver（macOS 和 iOS）、ChromeVox（在 Chromebook 上）以及TalkBack（Android）。

通常，螢幕閱讀器是獨立的應用程式，執行在主機作業系統上，不僅可以閱讀網頁，還可以閱讀其他應用程式中的文字。情況並非總是如此（ChromeVox 是瀏覽器擴充套件），但通常，螢幕閱讀器傾向於以略微不同的方式執行並具有不同的控制元件，因此你需要查閱所選螢幕閱讀器的文件以獲取所有詳細資訊——也就是說，它們基本上以相同的方式工作。

讓我們使用幾個不同的螢幕閱讀器進行一些測試，讓你大致瞭解它們的運作方式以及如何使用它們進行測試。

VoiceOver

VoiceOver (VO) 是你的 Mac/iPhone/iPad 的免費軟體，因此如果你使用蘋果產品，它非常適合在桌面/移動裝置上進行測試。我們將在 MacBook Pro 上的 macOS 上對其進行測試。

要開啟它，請按 Cmd + F5。如果你以前沒有使用過 VO，你會看到一個歡迎螢幕，你可以在其中選擇啟動 VO 或不啟動 VO，並執行一個非常有用的教程來學習如何使用它。要再次關閉它，請再次按 Cmd + F5。

當 VO 開啟時，顯示屏看起來基本相同，但你會在螢幕左下角看到一個黑框，其中包含有關 VO 當前選中內容的資訊。當前選中內容也會被突出顯示，帶有黑邊框——此突出顯示稱為VO 游標。

要使用 VO，你將大量使用“VO 修飾鍵”——這是一個鍵或鍵組合，你需要在實際 VO 鍵盤快捷鍵之外按下它才能使其生效。使用這種修飾鍵在螢幕閱讀器中很常見，這樣可以使它們保持命令不與其他命令衝突。在 VO 的情況下，修飾鍵可以是 CapsLock 或 Ctrl + Option。

VO 有很多鍵盤命令，我們不會在這裡全部列出。以下表格列出了你在網頁測試中需要用到的基本命令。在鍵盤快捷鍵中，“VO”表示“VoiceOver 修飾鍵”。

這似乎有很多命令，但當你習慣了它，VO 就會經常提醒你某些地方要使用什麼命令。現在試試 VO；然後，你可以繼續在螢幕閱讀器測試 部分中嘗試我們的一些示例。

NVDA

NVDA 僅適用於 Windows，你需要安裝它。

1. 從nvaccess.org 下載它。你可以選擇捐款或免費下載；你還需要提供你的電子郵件地址才能下載它。
2. 下載完成後，安裝它——雙擊安裝程式，接受許可並按照提示操作。
3. 要啟動 NVDA，雙擊程式檔案/快捷方式，或使用鍵盤快捷鍵 Ctrl + Alt + N。啟動它後，你會看到 NVDA 歡迎對話方塊。在這裡，你可以選擇幾個選項，然後按確定按鈕開始使用。

NVDA 現在將在你的計算機上處於活動狀態。

要使用 NVDA，你將大量使用“NVDA 修飾鍵”——這是一個鍵，你需要在實際 NVDA 鍵盤快捷鍵之外按下它才能使其生效。使用這種修飾鍵在螢幕閱讀器中很常見，這樣可以使它們保持命令不與其他命令衝突。在 NVDA 的情況下，修飾鍵可以是 Insert（預設設定）或 CapsLock（可以透過在按確定按鈕之前選中 NVDA 歡迎對話方塊中的第一個複選框來選擇）。

NVDA 有很多鍵盤命令，我們不會在這裡全部列出。以下表格列出了你在網頁測試中需要用到的基本命令。在鍵盤快捷鍵中，“NVDA”表示“NVDA 修飾鍵”。

螢幕閱讀器測試

現在您已經習慣使用螢幕閱讀器，我們希望您使用它進行一些快速的輔助功能測試，以便了解螢幕閱讀器如何處理良好和不良網頁功能。

• 檢視 good-semantics.html，並注意螢幕閱讀器如何找到標題並將其提供給導航使用。現在檢視 bad-semantics.html，並注意螢幕閱讀器如何無法獲取此資訊。想象一下，當嘗試瀏覽一個非常長的文字頁面時，這將是多麼令人討厭。
• 檢視 good-links.html，並注意它們在脫離上下文時是如何有意義的。 bad-links.html 並非如此，它們都只是“點選這裡”。
• 檢視 good-form.html，並注意表單輸入是如何使用它們的標籤來描述的，因為我們正確地使用了 <label> 元素。在 bad-form.html 中，它們得到一個無用的標籤，類似於“空白”。
• 檢視我們的 punk-bands-complete.html 示例，並檢視螢幕閱讀器如何能夠將內容的列和行關聯起來並一起讀出，因為我們已正確定義了標題。在 bad-table.html 中，所有單元格都無法關聯。請注意，NVDA 在您頁面上只有一個表格時，似乎表現得有點奇怪；您可以嘗試 WebAIM 的表格測試頁面。
• 檢視我們之前看到的 WAI-ARIA 即時區域示例，並注意螢幕閱讀器如何不斷地讀出不斷更新的部分。

如上所述，您不能僅僅依靠自動化工具來確定您網站上的輔助功能問題。建議您在制定測試計劃時，應儘可能包含一些輔助功能使用者組（請參閱我們在課程早期介紹的 使用者測試 部分，以獲取更多背景資訊）。嘗試讓一些螢幕閱讀器使用者參與，一些僅使用鍵盤的使用者，一些失聰使用者，以及其他可能適合您要求的其他使用者組。

以下清單為您提供了確保您已為您的專案執行了推薦的輔助功能測試的清單。

1. 確保您的 HTML 儘可能地語義正確。 驗證它 是一個很好的開始，使用 審計工具 也是如此。
2. 檢查您的內容在 CSS 關閉時是否有意義。
3. 確保您的功能 可以透過鍵盤訪問。使用 Tab、Return/Enter 等進行測試。
4. 確保您的非文字內容具有 文字替代。一個 審計工具 適合捕獲此類問題。
5. 使用合適的檢查工具，確保您網站的 顏色對比 可接受。
6. 確保 隱藏的內容 可被螢幕閱讀器看到。
7. 確保功能在沒有 JavaScript 的情況下儘可能可用。
8. 在適當的地方使用 ARIA 來提高輔助功能。
9. 透過 審計工具 執行您的網站。
10. 使用螢幕閱讀器測試它。
11. 在您網站上某個可找到的地方包含一個輔助功能策略/宣告，以說明您做了什麼。

您會在輔助功能方面遇到許多其他問題；真正需要知道的最重要的事情是如何在網上找到答案。請參閱 HTML 和 CSS 文章的 尋求幫助部分，以獲得一些有用的建議。

希望這篇文章能為您提供一個關於您可能遇到的主要輔助功能問題的基礎知識，以及如何測試和克服這些問題。

在下一篇文章中，我們將更詳細地探討功能檢測。

• 上一步
• 概述：跨瀏覽器測試
• 下一步