測試應用程式的無障礙功能 (Views)

概念和 Jetpack Compose 實作

透過測試無障礙功能，您可以從使用者的角度體驗應用程式，並找出可能遺漏的可用性問題。這類測試可讓您發掘改進空間，提供更強大、更靈活的應用程式給所有使用者，包括身心障礙者。

本文將說明下列方法：

  • 使用分析工具進行測試：運用相關工具，發掘應用程式無障礙功能的改進空間。
  • 自動化測試：在 Espresso 和 Robolectric 中開啟無障礙功能測試。

使用分析工具進行測試

透過分析工具，您可以發掘手動測試時可能遺漏的改進空間，讓無障礙功能更臻完善。

無障礙功能檢查工具

無障礙功能檢查工具應用程式會掃描畫面內容及提供建議，協助改善應用程式的無障礙功能。這項工具會採用無障礙功能測試架構，並在檢查內容標籤、可點擊項目、對比度等事項後，給出具體建議。

Android 無障礙功能測試架構已整合至 Android Studio，有助於找出版面配置中的無障礙功能問題。如要啟動面板，請按一下錯誤報告按鈕 ! 。

示範無障礙功能檢查工具的使用方式 圖 1. 示範無障礙功能檢查工具的使用方式。

詳情請參閱下列資源：

UI Automator Viewer

uiautomatorviewer 工具提供便利的 GUI，用於掃描及分析 Android 裝置上當前顯示的 UI 元件。您可以使用 UI Automator 檢查版面配置階層，以及查看裝置前景所顯示 UI 元件的屬性。相關資訊可讓您建立更精細的測試，例如建立符合特定可見屬性的 UI 選取器。這項工具位於 Android SDK 的 tools 目錄中。

在無障礙功能測試中，此工具很適合用來找出並修正以其他測試方法發現的問題。舉例來說，如果手動測試結果顯示檢視區塊沒有可朗讀的必要文字，或是焦點移至不應聚焦的檢視區塊，您就能使用這項工具找出問題來源。

如要進一步瞭解 UI Automator Viewer，請參閱「使用 UI Automator 編寫自動化測試」。

Lint

Android Studio 會顯示各種無障礙功能問題的 Lint 警告，並提供原始碼中相關位置的連結。在下方示例中，圖片缺少 contentDescription 屬性，因此系統顯示以下訊息：

[Accessibility] Missing 'contentDescription' attribute on image

圖 2 為 Android Studio 中此訊息顯示方式範例：

Android Studio 回報部分圖片缺少內容說明的示例圖。
圖 2 Android Studio 中的訊息指出圖片缺少 contentDescription 屬性。

自動化測試

Android 平台支援多種測試架構，例如 Espresso，此架構可讓您建立並執行自動化測試，評估應用程式的無障礙功能。

Espresso

Espresso 是用來加速及簡化 UI 測試的 Android 測試程式庫。透過此程式庫，您可以與應用程式中接受測試的 UI 元件互動，並斷言會發生特定行為或滿足特定條件。

如果想概略瞭解如何使用 Espresso 測試無障礙功能，請觀看以下影片中 31 分 54 秒至 34 分 19 秒的片段：考量多元包容的設計與測試：打造更符合無障礙設計的應用程式 - 2016 年 Google I/O 大會。

本節說明如何使用 Espresso 執行無障礙功能檢查。

啟用檢查功能

您可以使用 AccessibilityChecks 類別啟用及設定無障礙程度測試作業：

Kotlin

import androidx.test.espresso.accessibility.AccessibilityChecks

@RunWith(AndroidJUnit4::class)
@LargeTest
class MyWelcomeWorkflowIntegrationTest {
    init {
        AccessibilityChecks.enable()
    }
}

Java

import androidx.test.espresso.accessibility.AccessibilityChecks;

@RunWith(AndroidJUnit4.class)
@LargeTest
public class MyWelcomeWorkflowIntegrationTest {
    @BeforeClass
    public void enableAccessibilityChecks() {
        AccessibilityChecks.enable();
    }
}

根據預設，當您執行 ViewActions 中定義的任何查看動作時，會執行檢查。每個檢查都包含在其上執行動作的檢視區塊，以及所有子系檢視區塊。在每項檢查期間，您可以將 true 傳遞至 setRunChecksFromRootView()，以評估螢幕的整個檢視區塊階層，如下方程式碼片段所示：

Kotlin

AccessibilityChecks.enable().setRunChecksFromRootView(true)

Java

AccessibilityChecks.enable().setRunChecksFromRootView(true);

略過部分結果

Espresso 對應用程式執行無障礙功能檢查後，應用程式無障礙功能的一些改進機會可能無法立即解決。為避免 Espresso 測試因這些結果而持續失敗，您可以暫時予以忽略。無障礙功能測試架構 (ATF) 使用 setSuppressingResultMatcher() 方法提供這項功能，藉此指示 Espresso 略過所有符合指定比對器運算式的結果。

如果您對應用程式的變更可解決一個方面的無障礙問題，Espresso 會盡可能顯示更多其他方面的無障礙設計結果。因此，建議僅略過特定的已知改進機會。

當您暫時略過計劃稍後處理的無障礙功能測試發現結果時，請務必小心操作，不要意外略過相似的發現結果。出於此原因，建議使用限定範圍的比對器。如要這麼做，請選擇一個比對器，讓 Espresso 僅略過符合以下所有無障礙功能檢查條件的特定結果：

  1. 特定類型的無障礙功能檢查，例如檢查觸控目標大小。
  2. 用於評估特定 UI 元素 (例如按鈕) 的無障礙功能檢查。

ATF 定義了數個比對器，協助您定義要在 Espresso 測試中顯示的結果。下列範例會略過與單一 TextView 元素色彩對比相關的檢查結果。這個元素的 ID 是 countTV。

Kotlin

AccessibilityChecks.enable().apply {
        setSuppressingResultMatcher(
                allOf(
                    matchesCheck(TextContrastCheck::class.java),
                    matchesViews(withId(R.id.countTV))
                )
        )
}

Java

AccessibilityValidator myChecksValidator =
    AccessibilityChecks.enable()
        .setSuppressingResultMatcher(
            allOf(
                matchesCheck(TextContrastCheck.class),
                matchesViews(withId(R.id.countTV))));