Voiceover / Talkback

螢幕閱讀器，藉由手勢操作提供內容的有聲描述，幫助用戶在看不到螢幕時進行導航。

💡

Voiceover 為 iOS 說法，Talkback 為 Android 說法。請開啟並體驗螢幕閱讀器功能，更容易理解此篇內容。

⚠️

以下內容為螢幕閱讀器(Voiceover / Talkback)用戶體驗的建議做法，過去 KKBOX 有位工程師 (iOS) 很在意 accessibility ，因此早期元件都有定義。現在並無任何人定義，設計交付也尚未包含此規劃，因此會出現很多缺漏。

⚡️ Android 現況盤點：

→
docs.google.com
docs.google.com
因應 Google ADAP 修改需求，PM整理的表格

💡

由於多數人對於此項目不熟悉，因此以三個段落，由廣到深解釋。・ Behaviors - 螢幕閱讀器通用的交互行為・ Principles - 三大原則・ Writing Details - 細項定義

Behaviors

螢幕閱讀器通用的交互行為 - 共有兩種行為，使用者可以自由選擇自己適合的方式。

1. Explore by touch 通過觸摸瀏覽

使用者可以用手指觸及螢幕，直接聽到螢幕內容。這讓使用者快速的了解整個螢幕內容，並且藉由肌肉記憶快速找到 UI。

影片中為弱視的使用者操作

2. Linear navigation 線性導覽

使用者還可以通過在螢幕上向右或向左滑動來移動焦點，以線性方式從上到下閱讀頁面。

Principles

三大原則 - 一個好的螢幕閱讀體驗上需注意以下幾點。

1. Define each Voiceover / Talkback Label 定義元件朗誦名稱

避免名稱未定義。除非是元件本身自帶字串 - TextView。案例：

2. Define each Voiceover / Talkback scope 定義選取範圍

避免選取範圍與操作情境不符，導致選取過度零碎與無意義。案例：

3. Make sure the swiping order for each form 確保每一個事件的滑動順序

避免線性滑動順序不符合使用情境，像是功能的操作流程、上下文順序、畫面跳轉後框選的地方等。

⚠️

設計不需特別定義。預設會依左至右上、上至下作為滑動順序。設計檢測時仍須注意是否會有卡住或不符合體驗流程的狀況。

案例：

Ｗriting Details

細項定義

1. Not accessibility element 非可訪問性元素

情境：不需要被閱讀器讀取。如因為實作而出現的隱形物件，或是資訊龐大而想省略時(前提是不影響操作)。 Element. isAccessibilityElement (iOS) / importantForAccessibility (Android) 定義：元件是否為 Accessibility 元件？詳述：設計不需特別定義。設計檢測如遇元件不需被選取，或有特殊需求時，即可請開發修正此屬性。案例：

2. Accessibility element 可訪問性元素

情境：需要被閱讀器讀取。

⚠️

旁白文字預設描述順序： TextView/ Label → Traits/ Value → Hint 為避免文字重複性內容，通常 TextView/Label 擇一，Traits/Value 擇一。

❶TextView. 定義：在 TextView（或其子類）中，呈現的文本會自動提供給無障礙服務。通常不需要其他內容標籤。

⚠️

如是 ImageView, CheckBox 等沒有文本的 View 則會需要標籤。

案例：

標題

❷Label. accessibilityLabel (iOS) / ContentDescription (Android) 定義：輔助元件的標籤。詳述：描述輔助元件的字串，用於元件沒有文字內容閱讀時。

⚠️

1. 需提供多語系。 2. 如果沒定義 Label，將會朗讀開發者的內部描述。例如： icon_32。如遇開發者也沒有內部描述，即會朗讀原始檔名 xxxx.png 3. 無需在標籤中包含類型(Traits)或狀態(ex.已選/非選)的資訊。例如： Label - 返回按鈕，實際即會朗讀 - 返回按鈕按鈕 (因為Label, Traits 都有按鈕的字串，導致贅字) 4. 如果遇到過長(…)這樣的視覺呈現，閱讀器仍會閱讀 Raw data(TextView) 上的完整文字。

案例：