在 Airbnb，我们一直在有意识地设计和构建可供所有用户平等使用的产品。使我们的移动应用程序和网站更易于访问不仅符合我们公司创造一个人们可以随处归属的世界的使命，而且还支持残疾人的公民权利并遵守法律。

在本文中，我们重点介绍了我们为使应用程序更易于访问所做的一些努力，例如，标记 UI 元素、对相关内容进行分组、支持大字体、提供标题和页面名称。Airbnb 应用程序是最受欢迎的旅行应用程序之一，拥有数百万用户并支持许多功能。使如此复杂的应用程序更易于访问是我们不断努力的一项巨大努力。

第一部分：为所有人构建：我们应用的最佳实践

在 Airbnb，我们遵循行业最佳实践来使 Android 应用程序易于访问。如果您有兴趣，您可以从官方 Android 文档中找到我们遵循的所有最佳实践，以了解平台特定指南和作为行业标准的Web 内容可访问性指南。在这里，我们想强调几个我们应用最佳实践的例子：

最佳实践：内容描述

一切都应该有准确的内容描述，除非它们应该被辅助技术忽略。在这些示例中，共享按钮具有 TalkBack 朗读的内容描述。TalkBack 跳过房子图标。

最佳实践：分组

自然组的元素可以与可聚焦的容器一起公布，以提高可用性和准确性。例如，Talkback 将卡片上的所有列表内容一起阅读。

最佳实践：字体比例

当用户增加系统字体比例时，UI 应该可用。

默认与放大字体比例：

左侧的默认字体比例。右侧放大的字体比例。

扩展最佳实践

Airbnb Android 应用程序是一款包含多个屏幕的大型应用程序。如果我们需要在任何地方添加可访问性代码，那将会很累而且不可扩展。幸运的是，我们的设计语言系统使我们能够以高效的方式在产品表面广泛应用这些最佳实践。每个屏幕都是用一组可重用的 UI 组件构建的。当我们改进一个组件的可访问性时，更改将应用 于将此组件作为视图一部分的所有页面。这对我们应用程序的辅助功能改进产生了持久的积极影响。这是一个例子：

以SectionHeader为例。此 UI 组件用于传达页面上的结构并将内容组合在一起。我们在组件代码中将此组件标记为可访问性标题，以便在包含此组件的所有屏幕中都可以访问它。

class SectionHeader(...) {
   init {
      isAccessibilityHeading = true
   }
   …
}

第二部分：为工程师提供自动化检查

我们投资了自动化的可访问性测试和 linting 以在每次代码提交时运行，这为工程师创建了一个快速反馈循环，并使他们能够在编写代码时使应用程序可访问。这些检查快速、可靠，并且可以很好地扩展我们在 Android 应用程序中快速增长的功能。

自动化测试

我们设置了基于 Espresso 的自动化测试来检查可访问性问题。Espresso是一个流行的 Android UI 测试库，具有内置的可访问性检查。它支持一套全面的可访问性规则并且易于设置：

fun View.validateAccessibility() {
    AccessibilityChecks
        .enable()
        .checkAndReturnResults(this)
}

如果可访问性检查失败，测试会输出一个错误堆栈跟踪，工程师可以使用它来调试问题。例如：

AccessibilityViewCheckException: There was 1 accessibility error:
[...] AirImageView {... res-name=logo, ...}:
View is missing speakable text needed for a screen reader

在此示例中，工程师可以向图像视图提供内容描述以满足可访问性要求。

我们还使用更大的字体截屏测试我们的组件，以确保使用Happo的行为是正确的。

Linting

除了自动化测试之外，我们还启用了 linting，包括用于可访问性的Android Lint规则和使用Ktlint构建的自定义 lint 规则。

以下是 Android 可访问性 lint 规则的示例：

除了内置的 Android Lint，我们还使用 Ktlint 来构建自定义 lint 规则。例如，当用户导航到新屏幕时，我们会提供页面名称供屏幕阅读器宣布。我们使用以下规则来确保页面名称已本地化。

class A11yPageNameCorrectnessRule(moduleResolver: ModuleResolver) {
    override fun check(element: PsiElement) {
        failIf(element.containsA11yPageNameStringLiteral() }) {
        "Please do not use String literal. The a11y page name is read out to Talkback users when they navigate to a new screen. The page name needs to be localized."
        }
    }
}

Lint 规则易于设置并提供及时的反馈，但 linting 有局限性——它只能执行静态代码分析。

今天，这些自动检查作为 CI（持续集成）检查的一部分运行，用于每次代码提交。如果拉取请求未通过检查，它将被阻止合并到主代码分支中。我们仍然使用手动测试来覆盖自动检查未覆盖的区域，例如页面上 UI 元素的遍历顺序。自动检查和手动检查可以很好地互补。

第 III 部分：展望未来：Compose 的可访问性

在过去的一年里，我们一直在将 Jetpack Compose 集成到我们的应用程序中。Google 的Compose 辅助功能文档是确保我们的 Compose 组件和屏幕保持可访问性的重要资源。虽然视图中存在一些值得注意的缺失（例如焦点顺序修改），但 Compose 仍然是一个年轻的库，我们期待未来的改进。关于我们的特定于 Compose 的可访问性工具，以下是一些值得一提的事情：

主动鼓励 API 中的内容描述

我们对 UI 组件的指导方针之一是，通过函数参数公开的内容描述不应使用默认值。当工程师使用组件时，这将可访问性放在首位，因为他们需要考虑传递什么值。在 UI 元素对于可访问性不重要的情况下，空值仍然可以接受。

@Composable
fun IconRow(
    @DrawableRes iconResourceId: Int,
    iconContentDescription: String?,
    modifier: Modifier = Modifier,
    secondaryText: @Composable () -> Unit = { },
    text: @Composable () -> Unit
)

页面名称公告

使用片段和视图时，我们在导航到新屏幕时使用View.setAccessibilityPaneTitle()和View.announceForAccessibility() API 向用户宣布描述性页面名称。Compose 中不存在这些 API，但我们希望保留该功能，因为它有助于提供更多关于新屏幕显示内容的上下文。我们当前的解决方法是在屏幕的外部可组合项上设置某些语义：

Modifier.semantics {
    liveRegion = LiveRegionMode.Polite
    focused = true
    contentDescription = // Description of the screen contents
}

我们使用liveRegion属性，以便在内容描述更改时可以宣布更改。这对于其全部内容由服务器响应确定的页面很有用。在这种情况下，TalkBack 会在网络请求挂起时宣布“内容加载”，然后在完成时宣布“内容已加载”，最后是服务器响应中定义的页面描述。这种方法的一个缺点是它需要外部容器是可聚焦的，这需要额外的导航操作才能到达内容。

结语

使我们的 Android 应用程序更易于访问是一个有影响力的旅程。提高应用程序的可访问性涉及遵循最佳实践、增加严格的执行、不断从错误中学习并投入工作。所有这些都是确保应用程序适用于所有用户的值得付出的努力。

如果您对构建高度可访问的产品和支持它们的框架感到兴奋，请查看我们的一些相关空缺职位：

员工 Android 软件工程师，访客

高级 iOS 软件工程师，基础设施

致谢

使像 Airbnb Android 应用程序这样的复杂应用程序更易于访问是一项巨大的努力。如果没有数字无障碍团队和 Airbnb 紧密联系的 Android 社 区的巨大努力，这项工作是不可能完成的。每个工程师都为使他们拥有的功能易于访问做出了贡献。让 Android 应用程序更易于访问是一项持续的努力，没有所有这些，它就不可能成功。

作者:Julia Fu , Peter Elliott

出处:https://medium.com/airbnb-engineering/making-airbnbs-android-app-more-accessible-75618172be6