萬字干貨！超全面的無障礙讀屏體驗設計指南

你知道盲人是如何使用手機的嗎？受益于無障礙讀屏，盲人能在看不到屏幕的情況下，讓手機讀出屏幕上的每項內容。結合簡易的手勢、語音輸入，盲人也能和明眼人（即視覺無礙的人）一樣自由地享受科技。

無障礙讀屏體驗的重要性主要體現在以下 3 個方面:

①滿足用戶需求

我們堅信，每個人都應該能平等地使用數字產品、服務，而不受視覺能力的限制。通過考慮視障群體的訴求，我們可以打破數字世界中的障礙，使他們能夠與其他用戶一樣獲得信息和參與交互。

②提升產品競爭力

優良的無障礙讀屏體驗可以增加產品的吸引力、競爭力。若視障群體能輕松使用產品，他們會感受到關注、尊重。這種積極的用戶體驗將增加他們對產品的滿意度，并提升他們繼續使用、推薦產品的可能。

③推動科技向善

推行無障礙讀屏體驗符合聯合國《殘疾人權利公約》的精神，該公約呼吁各方關注并消除殘疾人面臨的障礙，以促進社會的包容、可持續發展。通過為視障群體提供更好的用戶體驗，我們也在推動科技的持續向善。

可見，無障礙讀屏體驗是不可忽視的。因此，我們建議將無障礙讀屏體驗納入到日常設計的考量范圍內。

更多無障礙設計干貨：

一、設計原則

參考 WCAG 2.2，無障礙讀屏體驗的設計原則有以下 3 點：

1. Perceivable：能和明眼人一樣在應用中獲取信息。
2. Operable：能完成和明眼人幾乎一樣多的操作。
3. Understandable：對應用內的信息，能達到和明眼人接近的理解效果。

二、基礎概念

在了解如何設計無障礙讀屏體驗前，我們需先了解其相關的基礎概念。

1. 常見讀屏應用

目前，市面上有諸多讀屏應用。其中，最為常見的的系統級讀屏應用主要有以下 3 個：

盡管本文的內容更側重于觸摸屏環境中的 VoiceOver 和 TalkBack，但整體設計思想是通用的。

2. 交互模式

無障礙讀屏體驗中，主要有以下 3 種交互模式：

①Linear Navigation

讀屏應用是以線性的順序（sequentially）探索、朗讀屏幕上的 UI 元素的。以 iOS 端的 VoiceOver 為例：向右輕掃選擇下一項，向左輕掃選擇上一項，焦點所在元素的內容會被朗讀，雙擊即可觸發元素。

②Direct Command

和明眼人一樣，視障用戶同樣可以通過語音助手、捷徑（shortcuts）、快捷鍵（keyboard shortcuts）等功能實現更為直接、高效的交互。

關于快捷鍵，建議搭配閱讀我們之前發布的《設計快捷鍵》一文。

③Explore by Touch

視障用戶也可以直接將手指按在屏幕的特定位置，以讓焦點直接抵達此位置，而無需通過 linear navigation 的順序一步步導航至此。

可見：

1. 保證可交互元素的響應熱區足夠大，也有利于無障礙讀屏體驗。
2. 若能保持 UI 元素位置穩定，視障用戶也能通過形成肌肉記憶來提升無障礙讀屏效率。

此外，用戶還可以可通過盲文閱讀器（braille display）等外接設備進行無障礙讀屏。

3. Accessibility Attributes

Accessibility attributes 指的是 UI 元素被讀屏應用朗讀的內容。

為 UI 元素設計其 accessibility attributes 是無障礙讀屏體驗中至關重要的一環。因為，讀屏應用朗讀的內容幾乎就是視障用戶能獲取到的所有信息。

通常，讀屏應用會為各個元素按以下順序朗讀 accessibility attributes：

1. Label
2. Value
3. Traits
4. Hints

①Label

Label 指的是用于描述 UI 元素的文本。

默認情況下，label 的值等于 UI 元素在屏幕上展示的文本。若 UI 元素不含文本，則需手動為其填寫 label。

舉幾個例子：

1. 一個 button 的 label 是「添加」，和它在屏幕上展示的文本一致；
2. 一個 icon 的 label 是「播放」，盡管在屏幕上它并沒有文本標簽。

②Value

Value 指的是 UI 元素當前的值、內容、已選項。

Value 是非必填項。只有當元素的 label 無法清晰描述其當前值或內容時，才需添加 value。

舉幾個例子：

1. 一個 slider 的 label 是「屏幕亮度」，其當前的 value 是「60%」。
2. 一個 pull-down button 的 label 是「性別」，其當前的 value 是「女」。

③Traits

Traits 指的是用于描述 UI 元素的狀態（state）、行為（behavior）、用途（usage）的文本。

每個元素都至少要有 1 個 trait。因為，操作系統需根據元素的 traits 來賦予其不同的交互特性。

舉幾個例子：

1. 虛擬鍵盤中的按鈕的 traits 為「Keyboard Key」。
2. 音樂播放器中的播放按鈕的 traits 為「Button, Starts Media Session」。

④Hints

Hints 指的是用于描述 UI 元素執行結果的文本。

Hints 是非必填項。只有當元素的 label 無法清晰描述其執行結果時，才需添加 hints。

Hints 不一定會被朗讀，因為用戶可以在設置中選擇是否讓讀屏應用朗讀 hints。可見，我們可以將 hints 理解為是為「非熟練用戶」提供的內容。

舉幾個例子：

1. 一個 butoon 的 label 是「收藏」，其 hints 可以是「收藏內容更新時會提醒你」。
2. 一個 icon 的 label 是「一鍵三連」，其 hints 可以是「輕點兩下來同時點贊、收藏、關注」。

4. Rotor

Rotor（轉子）是 VoiceOver 中的一種工具，用于在觸摸屏環境下提供各種快捷設置、實用功能。在不同的頁面、場景，rotor 提供的選項會有所不同。

其使用方法為：

1. 在屏幕上轉動雙指，即可喚出 rotor。
2. 繼續轉動手指可以聽取更多選項。
3. 聽到想要的選項時，停止轉動手指，然后用手指在屏幕上上下輕掃就可以使用、更改選項了。

舉幾個例子：

1. 在電子書應用中，可以喚出 rotor 并選取「語速」選項。接著，上下輕掃即可更改朗讀語速。
2. 在文檔應用中，可以喚出 rotor 并選取「標題」選項。接著，上下輕掃即可使用「只讀標題」的功能。

可見，rotor 能提供更快、更靈活的頁面訪問方式。

以下是常見的 rotor 選項及其效果：

5. Item Chooser

Item chooser（項目選取器）是 VoiceOver 中的一種工具，用于快速選擇特定 UI 元素。其特別適用于頁面中有大量元素的場景。

其使用方法為：

1. 在屏幕上用兩根手指輕點三下屏幕，即可喚出 item chooser。
2. 接著，可以通過索引或搜索來選擇特定 UI 元素。

可見，item chooser 能讓我們更方便地選擇目標元素。

三、設計流程

為體系化地設計無障礙讀屏體驗，我們建議采取以下設計流程：

1. 確定讀屏范圍
2. 定義讀屏順序
3. 進行元素分組
4. 設計朗讀內容
5. 設計朗讀方式

1. 確定讀屏范圍

并非頁面上的所有信息都需要被讀屏應用朗讀。因為，對于視障用戶來說，純裝飾性的、用于構建視覺層級的 UI 元素是不需要的。

舉幾個例子：

1. 模塊間的分割線；
2. 構建賣場氛圍的背景插畫。

2. 定義讀屏順序

建議使 focus order 與明眼人的 visual order（視線流）一致，而不是使用的「從左到右、從上到下」的默認順序。

這與為鍵盤導航設計 tab order 的思路是一致的。可見，穩健的鍵盤導航體系是無障礙讀屏體驗的堅實基礎。關于鍵盤導航，建議搭配閱讀我們之前發布的《設計鍵盤導航》一文。

3. 進行元素分組

建議將關系緊密的元素合為一組。這樣，讀屏應用就會將這一組視為一個 UI 元素來朗讀，而不是分別朗讀每個子元素。

這樣做主要能為我們帶來以下 2 方面的好處：

①提供清晰的信息結構

更清晰的信息結構使得視障用戶能夠更好地理解頁面的組織、導航方式，從而更有效地瀏覽內容。如：

將「飛行模式」文本和一個 switch 放在同一組中，讀屏軟件就能將其朗讀為：「飛行模式，切換按鈕，關閉，輕點兩下來切換設置」。若不放在同一組中，我們就需聽完「飛行模式」后向右輕掃，才能聽到「切換按鈕，關閉，輕點兩下來切換設置」。況且，當下所聽到的「切換按鈕」具體應用的對象也是不清晰的。

②大幅簡化導航和操作

通過將相關元素分組，可以使視障用戶更輕松地導航和操作頁面。

舉幾個例子：

1. 將列表項及其側滑出現的「標為未讀」「不顯示」「刪除」放在同一組中，當讀屏焦點抵達此列表項時，讀屏應用會提示用戶有 custom action 可用。用戶不需要將讀屏焦點離開此列表項，即可向上或向下輕掃來完成「標為未讀」「不顯示」「刪除」。
2. 將瀑布流中的帖子及其「點贊」按鈕放在同一組中，當讀屏焦點抵達此帖子時，讀屏應用會提示用戶有 custom action 可用。用戶不需要將讀屏焦點離開此帖子，即可向上或向下輕掃完成「點贊」。

進行元素分組的思路，與為鍵盤導航設計 focus group 的思路是一致的。這再次印證了，穩健的鍵盤導航體系是無障礙讀屏體驗的堅實基礎。

4. 設計朗讀內容

清晰、簡潔、有條理的朗讀內容是無障礙讀屏體驗的重點。

以下是面向 label、traits、hints 等 accessibility attributes 的設計指引。

①設計 Label

力求簡潔

簡潔的 label 能帶來更高的讀屏效率。

舉幾個例子：

UI 元素的 label 還能用于語音控制、盲文閱讀。因此，若標簽不夠簡潔，語音控制和盲文閱讀的交互成本將顯著提升。

1. 音樂播放器中的 3 個主按鈕，其 label 應被寫為「上一首」「下一首」「播放」，而不是「上一首歌曲」「下一首歌曲」「播放這首歌曲」。
2. 文件管理器中的刪除按鈕，其 label 應被寫為「刪除」，而不是「把文件從當前文件夾刪除并放入回收站」。

不含元素的類型信息

UI 元素的類型信息應體現于 traits 中，如：文件管理器中的刪除按鈕，其 label 應被寫為「刪除」，而不是「刪除按鈕」。

隨 UI 更新

如：原 label 為「添加」的圖標按鈕，在完成添加操作后，其圖標會變為垃圾桶的樣式，其 label 也應更新為「刪除」。

為含語義的動畫添加 Label

如：表達加載的動畫元素的 label 可以寫為「正在加載」。

為含語義的圖片添加 Label

含有文本的圖片、表達特定信息的圖片（如數據圖、示意圖等）都需要添加用來描述圖片信息的 label。如：用來表達頁面無內容的插畫的 label 可以寫為「暫無內容」。

本地化

支持系統的首選語言。

②Value

只有當 UI 元素的 label 無法清晰描述其當前值或內容時，才需添加 value。

隨意為元素添加 value 可能會導致讀屏應用的朗讀內容過于冗長或不合邏輯。

③設計 Traits

在實現層面，我們僅需為 UI 元素從讀屏應用提供的 traits 中選擇 1 個或多個即可，而無需親自撰寫。

以 VoiceOver 為例，其提供以下 3 類 traits 選用：

以下是針對部分 traits 的設計指引。

Selected

用于表明 UI 元素是當前選定的項目。如：tab、segmented control 上被選定的項目等。

Not Enabled

用于表明 UI 元素是不可交互的。

Adjustable

用于表明 UI 元素的 value 可以被更改。如：slider、pull-down button 等。

讀屏應用會告知用戶可以在此元素上垂直滑動以更改 value。

Update Frequently

用于表明 UI 元素的 label 或 value 會變化。

這會讓設備定期輪詢此元素以獲取更新。因此，為不必要的元素添加此 trait 會降低設備的性能和電池壽命。

Causes Page Turn

用于表明 UI 元素用于翻頁。如：在電子書中用于翻頁的 button 等。

Play Sound

用于表明 UI 元素一旦被激活就會播放聲音。

Starts Media Session

用于表明 UI 元素一旦被激活就會開始播放或錄制媒體。

Allows Direct Interaction

用于表明 UI 元素允許直接進行觸摸交互（即明眼人操作手機的常規形式）。

此 trait 適用于直接觸摸交互是合理形式的場景，如：

1. 在 GarageBand 中使彈鋼琴；
2. 在圖片編輯器中繪畫。

Modal

用于表明 UI 元素是以模態的形式呈現的。

這會讓讀屏應用暫時忽略模態視圖以外的內容。

Link

一般情況下，用于表明 UI 元素能導航到特定網頁或撥打電話。

按慣例，用于在應用內導航的元素應使用 button 這一 trait。

Search Field

用于表明 UI 元素允許輸入字符串以執行搜索。

Summary Element

用于表明 UI 元素提供當前頁面內容的概覽。如：iOS 原生天氣應用頂部的摘要部分。

這會讓讀屏應用一進入此頁面的時候就開始朗讀此元素（無論此元素在視圖層次結構中的位置如何），但導航順序不會受到影響。

Header

用于表明 UI 元素是分隔內容的標題。如 navigation bar title、table section header 等。

借助前面提到的 rotor，我們可以讓讀屏應用跳過大段內容并僅朗讀這類元素。對于視障群體來說，這應是一項基本技術。因為，他們無法直觀地瀏覽屏幕以快速了解、定位信息。

每個頁面都至少有一個這類元素。

Image

用于表明 UI 元素是含語義的圖片。純裝飾性的圖片則無需添加此 trait。

一般來說，此 trait 不應用于圖像按鈕，但可用于可以點擊以獲得更大版本的圖片。

Static Text

用于表明 UI 元素是用戶無法更改或很少更改的靜態文本。

一般來說，此 trait 不應用于圖像按鈕，但可用于可以點擊以獲得更大版本的圖片。

④設計 Hints

簡明扼要地描述執行結果

盡管很少有 UI 元素需要 hints，但還是需盡可能讓 hints 保持簡短，以減少用戶在使用該元素之前必須花費的時間。

省略主語，并以動詞開頭

在撰寫 hint 時，可以想象我們是在向朋友描述如何使用此元素。如：我們會說「你輕點兩下來這個按鈕就可以播放音樂了」，所以此元素的 hint 就可以寫為「輕點兩下來播放歌曲」。

不含元素的類型信息

UI 元素的類型信息應體現于 traits 中

因此，諸如「輕點兩下按鈕來播放歌曲」「輕點兩下鏈接來購買禮包」「輕點兩下按鈕來刪除項目」都是不理想的 hints，更優的寫法是「輕點兩下來播放歌曲」「輕點兩下來購買禮包」「輕點兩下來刪除項目」。

在英語環境下，用動詞的第三人稱單數形式

如：使用第三人稱單數形式「Plays」，而不是命令式的「Play」。因為，命令式的表達會讓 hints 聽起來像命令?！窹lays」傳達的是「Tapping this control plays the song」，而「Play」更像是在傳達「You must to play the song」。

在英語環境下，以大寫單詞開頭，以句號結尾

盡管 hint 是一個短語，而不是一個句子，但以句號結束提示有助于讀屏應用以適當的語調來朗讀。

本地化

支持系統的首選語言。

⑤用 Design Token 管理 Accessibility Attributes

我們建議從 component 層面開始設計朗讀內容：將 label、value、traits、hints 作為 design token 的 property，以實現更為科學、高效的設計管理。

關于 design token，建議搭配閱讀我們之前發布的《給設計師的 design token 指南》系列文章。

5. 設計朗讀方式

貼合邏輯、符合語境、富有情感的朗讀形式能提升無障礙讀屏的體驗。

為向讀屏應用指明該以什么樣的形式、語氣來朗讀，我們可以使用以下屬性：

1. Language
2. Spell Out
3. Punctuation
4. Phonetic Notation

①Language

用于指定使用何種語言來朗讀。

②Spell Out

用于指定使用何種形式來朗讀數字。如：

1. 對于電話號碼「10086」，可指定朗讀為「一零零八六」，而不是「一萬零八十六」。
2. 對于訂單號「266 900 828」（為方便識別，此訂單號采用每三個數字為一組的形式），可指定朗讀為「二六六 九零零 八二八」，而不是「二百六十六 九百 八百二十八」或「二億六千六百九十萬零八百二十八」。
3. 對于時間「2023/08/23 16:00」，可指定朗讀為「二零二三年八月二十三號 十六點整」，而不是「二千零二十三，斜杠，八，斜杠，二十三，斜杠，十六比零」

③Punctuation

用于指定是否朗讀標點符號。如：對于代碼，朗讀標點符號一般來說是更合理的。

④Phonetic Notation

用于指定對特定字詞的口音、音高、語氣等。如：

1. 對于「番禺」，可指定朗讀為「pān yú」，而不是「fān yú」；
2. 對于「下個路口左轉」，對于明眼人來說，能看到「左轉」被加粗強調，所以應讓讀屏應用在朗讀「左轉」時提升音高（pitch）以起到等效的強調效果。

在英語環境下，我們還可以指定是否將縮寫（abbreviation）以全稱形式朗讀。如：對于「BG」「FG」，可分別指定朗讀為「Foreground Color」「Background Color」。

此外，在 visionOS 中，我們還可以運用 Spacial Audio 來構建更為豐富的發聲模式。

四、進階設計

1. 充分運用 Rotor

VoiceOver 支持開發者自定義 rotor。由此，我們可以根據實際需求，在 rotor 中為用戶設計快捷設置、實用功能。

①用 Rotor 簡化朗讀信息

對于一些信息較多的 UI 元素（特別是由多個子元素組合構成的復雜元素），我們可以讓讀屏應用默認只讀其關鍵信息，而其他信息則需用戶通過激活 rotor 中的「more content」選項才會被朗讀。

由此，用戶可以在他們需要或感興趣的情況下才去聽更多信息，而無需被大量信息所淹沒。這是「Progressive Disclosure」設計模式的一種。

舉幾個例子：

在理財產品售賣頁，每個列表項均有很多信息。若讓讀屏應用挨個閱讀，效率勢必差強人意。因此，我們可以將諸如「風險等級」「成立以來最大回撤」等附加信息指定為「more content」。這樣一來，只有當用戶想進一步了解此產品的信息時，才需通過 rotor 選擇「more content」選項，并通過向上或向下輕掃的手勢來依次聽取這些附加信息

在機票售賣列表頁，我們也可以將諸如「航空公司」「餐食」「機上 Wi-Fi」等附加信息指定為「more content」。

②用 Rotor 簡化導航流程

對于一些信息較多的頁面，我們可以將頁面的元素進行分類，以支持用戶可以通過 rotor 來實現只在某類元素間進行導航的效果。

由此，用戶可以只在感興趣的類目下導航。這是「篩選」設計模式的一種。

如：在地圖應用中，有非常多的 POI。若我們的目的是找某個公園，則可以通過 rotor 選擇「parks」選項，即可只在公園的 POI 間導航，從而更快找到心儀的公園。

以下是常用的用于簡化導航流程的 rotor 選項：

2. 優化數據圖的體驗

前面我們提到，對于含語義的圖片，我們應盡可能通過 label 來描述圖片信息。但對于數據圖，常規的描述手段很難清晰、簡潔地傳達信息。因為，相比于普通的圖片，數據圖更注重對數據的解讀和傳達。

①用 Audio Graph 傳達數據走勢

我們可以通過 audio graph 來「朗讀」數據圖的整體輪廓。

在 audio graph 中，每個軸的數據都會被轉化為聲音。通常，我們會將 y 軸轉化為音高（pitch），x 軸轉化為時間。

我們還需提供方便的音頻播放控制功能，如播放、暫停、停止和調整音量等。由此，用戶可以根據自己的需要靈活地控制 audio graph 音頻的播放。

②簡化數據點間的導航

我們可以將每個數據點都創建成可訪問的元素，以支持用戶訪問數據圖中特定點的數據。但有時，會出現數據點太多的問題。

正如前面我們提到的「元素分組」，面對這樣的情況，我們建議將圖表分成合理的區間，以方面用戶在大量數據點間導航。

3. 創建 Accessibility Notifications

若頁面發生的變化并不在焦點所處的元素上，視障用戶就無法像明眼人一樣用邊緣視覺（peripheral vision）察覺到變化了。

因此，當頁面中的 UI 元素發生變化、有 UI 元素出現或消失時，我們需通過 accessibility notification 來進行告知，即自動朗讀變化信息。有時，還可以自動將焦點移動到發生變化的元素上。

舉幾個例子：

在計算器中，輸入完「1+2」后點擊「=」，讀屏應用會自動朗讀「Result，3」，而無需用戶導航到結果區域才能聽取結果。

在微信存儲空間頁，當「微信已用空間」計算完畢時，讀屏應用會自動播報「微信已用空間」的具體數據。

五、設計驗收

1. 用輔助工具搜尋問題

對于 Apple 設備，可用 Xcode 中的 Accessibility Inspector 來幫助搜尋問題；

對于 Android 設備，可用 Accessibility Scanner 來幫助搜尋問題。

下面，我們將重點介紹使用 Accessibility Inspector 來進行驗收的方式。

Accessibility Inspector 是 Xcode 自帶的無障礙檢查工具。我們可以在 Xcode 的中通過「Xcode > Open Developer Tool > Accessibility Inspector」打開，也可以直接通過 Spotlight 搜索來打開。

若需驗收的應用非 macOS 應用，我們需先在應用所安裝的設備上打開「Developer Mode」。

①檢查特定元素

點擊 Accessibility Inspector 窗口右上方的「Inspection Pointer」toggle button。

點擊想要檢查的 UI 元素。

在 Accessibility Inspector 窗口的「Inspection Detail」區，查看此元素的各項 accessibility attributes，并檢查其完整性、正確性。

②檢查導航流程

若需驗收在無障礙讀屏體驗中的 liner navigation，可點擊 Accessibility Inspector 窗口右上方的「Auto Navigate」toggle button，Accessibility Inspector 就會按導航順序挨個朗讀 UI 元素。

③自動化搜尋問題

我們也可以利用 Accessibility Inspector 一鍵檢查應用特定頁面的所有 UI 元素。

1. 打開需檢查的特定頁面。
2. 在 Accessibility Inspector 窗口左上角的「Device Target」pop-up button 中，選擇所需檢查的應用。
3. 點擊 Accessibility Inspector 窗口右上角的「Audit」。
4. 點擊 Accessibility Inspector 窗口中的「Run Audit」，即可看到搜尋到的所有無障礙問題。
5. 在列表中，可以查看問題描述、截圖、修復建議。

2. 在擬真環境中上手體驗

在 iOS 中，我們可以打開「連按三次電源鍵以快速打開和關閉 VoiceOver」的選項。這不僅能讓每次啟動或禁用 VoiceOver 更快，也能在不確定要使用哪個手勢時輕松禁用旁白。

為了能更貼近視障用戶的感受，我們還可以在使用 VoiceOver 的過程中打開 Screen Curtain（屏幕簾）。當 Screen Curtain 打開時，設備屏幕將始終處于關閉狀態。

3. 驗收 List

以下 checklist 僅供參考，可以根據實際需求進行調整。

六、不僅僅是無障礙讀屏

優良的無障礙讀屏體驗，還能與其他諸多體驗有機結合，共建完善的設計體系。

1. 語音控制

語音控制指的是用語音命令來執行各種操作的能力，如：打開應用、更改設置、瀏覽文件等。

語音控制與無障礙讀屏的關系在于：

1. 視障群體也可以通過語音控制實現無障礙讀屏的 direct command，而無需通使用觸屏手勢。
2. 無障礙讀屏設計中的 label，也可以作為語音控制的口令。因此，簡短的 label 能讓語音口令更易于記憶和說出。

2. 切換控制

借助切換控制，用戶可以使用多種自適應設備 (如 switch、joystick、鍵盤空格鍵或觸控板) 操作 app：逐個掃描 UI 元素，到達所需的 UI 元素后，使用設備執行適當的操作。

切換控制與無障礙讀屏的關系在于：

1. 視障用戶也可以用切換控制的設備來進行操作，而無需使用觸屏手勢。
2. 無障礙讀屏的導航順序、元素分組也同樣適用于切換控制。

3. 鍵盤導航

鍵盤導航指的是使用鍵盤進行頁面導航的能力。

鍵盤導航與無障礙讀屏的關系在于：

1. 在 PC 端，兩者往往是配合使用的（通過鍵盤導航來移動焦點、操作）。
2. 鍵盤導航的 tab order、focus group 等設計理念同樣適用于無障礙讀屏。

4. 明眼人的體驗

無障礙讀屏設計不僅對視障群體有意義，對于明眼人來說也同樣具有重要意義。

1. 足夠大的響應熱區，穩定的界面布局，對于明眼人和盲人都同樣重要。明眼人可以從中學習如何更好地設計用戶界面，以提供更清晰、簡潔和易于理解的信息。
2. 無障礙讀屏設計中的 label，有利于對頁面進行檢索。對于網頁來說，其對 SEO 更是大有裨益。
3. 無障礙讀屏設計本身可以可以幫助更多人理解殘障人士的需求和難處，促進社會平等和包容性的提高。

結語

設計優良的無障礙讀屏體驗可以幫助視障群體獲得與其他人相同的使用權力和機會，更可以讓我們深入關注社會公正與可持續發展。我們希望能有更多設計師能參與到設計無障礙讀屏的工作中來，真正實現科技相善。

歡迎關注作者微信公眾號：「We-Design」