As you know, accessibility is about building products that everyone can use easily and effectively. As an Android developer, this is about developing Android apps that can be used by every user, regardless of how they interact with the device. When you develop Android apps with accessibility in mind, you make the user experience much more better for users with accessibility needs. This essay will discuss some accessibility best practices and issues in Android development.

如您所知，可访问性是指构建每个人都可以轻松有效地使用的产品。 作为一名Android开发人员，这是关于开发可被每个用户使用的Android应用程序，无论他们如何与设备交互。 在开发具有可访问性的Android应用程序时，对于具有可访问性需求的用户，可以使用户体验更好。 本文将讨论Android开发中的一些可访问性最佳做法和问题。

简介与概述 (Introduction and Overview)

Basically, accessibility refers to the design of products, devices, services or environments, which work to include everyone. Simply, accessibility is about building products that everyone can use easily. For Android developers, it is about developing apps that can be used by every user, regardless of how they interact with the Android device. People with impaired vision, color blindness, impaired hearing, impaired dexterity, cognitive disabilities, and a number of other disabilities use Android gadgets to complete tasks in their daily routines. When you develop applications with accessibility in mind, you make the user experience better for users with accessibility needs. The World Health Organization has been mentioned that one in seven users worldwide experience some forms of disability. That is over 1 billion people who have accessibility needs every day in order to live their lives. In addition, accessibility impacts everyone at some moments in their lives. This means everyone, at some situations, has had an experience where something was not sufficiently accessible. This could be temporary. For instance, you cannot use your hands due to a surgery, or when you are observing at a screen with poor contrast in bright outdoor light. Therefore, accessibility is not just only a moral imperative. It is considered as a tremendous business opportunity for developers. This means there are a number of users who have some kinds of disability, and they would love to use your app to make in-app purchases, etc.

基本上，可访问性是指产品，设备，服务或环境的设计，这些产品，工具，服务或环境可以囊括所有人。 简而言之，可访问性是指构建每个人都可以轻松使用的产品。 对于Android开发人员而言，这是关于开发可被每个用户使用的应用程序，无论他们如何与Android设备进行交互。 视力受损，色盲，听力受损，灵活性受损，认知障碍以及许多其他障碍的人在日常工作中使用Android小工具来完成任务。 在开发具有可访问性的应用程序时，可以为具有可访问性需求的用户提供更好的用户体验。 有人提到世界卫生组织 ，全世界有七分之一的用户遇到某种形式的残疾。 每天有超过10亿人需要无障碍获取生活。 此外，可访问性还会影响每个人的生活。 这意味着在某些情况下，每个人都曾经历过某些事物无法充分获得的经历。 这可能是暂时的。 例如，由于手术或在明亮的室外光线下对比度较差的屏幕上观察而无法使用手。 因此，可及性不仅仅是道德上的当务之急。 对于开发人员来说，这是一个巨大的商机。 这意味着有许多具有某种残疾的用户，他们希望使用您的应用进行应用内购买等。

准确了解您的用户 (Knowing your users accurately)

In fact, users interact with your app by using accessibility services. These are long-running privilege services, which offer various ways for users with disabilities to interact with your app. So, some commonly used accessibility services could be mentioned as follows:

实际上，用户通过使用辅助功能与您的应用进行交互。 这些是长期运行的特权服务，可为残障用户提供各种与您的应用进行交互的方式。 因此，可以提及一些常用的辅助功能：

TalkBack

顶嘴

Initially, TalkBack is a Google screen reader included on lots of Android devices. TalkBack gives users spoken feedback. Thus, they can be able to use their devices without needing to look at the screen. User discover content by moving their fingers across the screen. Besides, as a view is discovered, TalkBack announces it, and users have easy shortcuts for performing gestures like clicking, long pressing, etc.

最初， TalkBack是许多Android设备上都包含的Google屏幕阅读器。 “话语提示”为用户提供了语音反馈。 因此，他们无需看屏幕就能使用其设备。 用户通过在屏幕上移动手指来发现内容。 此外，发现视图后，“话语提示”便会宣布该视图，用户可以轻松快捷地执行诸如单击，长按等手势。

TalkBack is an Accessibility Service that helps vision-impaired users interact with, and enjoy, their devices. It uses spoken word, vibration and other audible feedback to let you know what’s on your screen, what you’re touching, and what you can do with it.

“话语提示”是一项可访问性服务，可帮助视障用户与他们的设备互动并享受其设备。 它使用语音，振动和其他声音反馈来让您知道屏幕上的内容，触摸的内容以及可以使用的功能。

BrailleBack

盲文提示

BraillBack is another common choice for blind or visually impaired users. With BrailleBack, users can connect a refresh-able Braille display to an Android device via Bluetooth. BrailleBack works properly with TalkBack to support a combined speech and Braille experience.

对于盲人或视障用户， BraillBack是另一个常见选择。 使用盲文提示，用户可以通过蓝牙将可刷新的盲文显示器连接到Android设备。 “盲文提示”可以与“话语提示”配合使用，以支持语音和盲文体验的结合。

Google BrailleBack is an app that lets users connect a refresh-able Braille display to an Android device over Bluetooth. BrailleBack works with TalkBack to provide a combined speech and Braille experience.

Google BrailleBack是一款应用程序，可让用户通过蓝牙将可刷新的盲文显示器连接到Android设备。 盲文提示可与“话语提示”配合使用，以提供语音和盲文体验的结合。

Switch Access

开关访问

Switch Access allows users interact with an Android device using one or more switches instead of the touchscreen. Switch Access can be helpful for users with dexterity impairments, which prevent them from interacting directly with the Android device. Switch Access can also scans the items on your screen, highlighting each item in turn, until the user makes a selection.

开关访问允许用户使用一个或多个开关而不是触摸屏与Android设备进行交互。 开关访问功能对有灵活性障碍的用户很有帮助，这会阻止他们直接与Android设备进行交互。 Switch Access还可以扫描屏幕上的项目，依次高亮显示每个项目，直到用户做出选择为止。

Switch Access helps people who have motor disabilities. Highlights interactive elements, and performs actions in response to the user pressing a button. Allows for controlling the device using only 1 or 2 buttons.

开关访问功能可以帮助行动不便的人。 突出显示交互元素，并响应用户按下按钮执行操作。 仅允许使用1或2个按钮控制设备。

As a matter of fact, you can be able to serve all these different users by writing just only one version of your Android app. The Android framework takes care of providing information needed by various accessibility services to render your app appropriately.

事实上，您只需编写一个版本的Android应用即可为所有这些不同的用户提供服务。 Android框架负责提供各种辅助功能服务所需的信息，以适当地呈现您的应用程序。

互动模式 (Interaction model)

When you are interacting with your phone, you can divide all of those interactions as your phone presenting information to you such as text, buttons, and images. Next, as the user, acting on the phone like pressing those buttons and swiping around can be indicated. Your actions can lead to more information to be presented, and the cycle continues in response. Users with accessibility needs benefit from having that information presented in multiple ways. Furthermore, they benefit from having multiple ways to interact with your Android app. For instance, a motor impaired user might have difficulty interacting with your app if drag and drop is the only option to use your Android application. Also, a visually impaired user will have hardly understanding the information that is presented to them if it is only available text option. As a result, the accessibility services help address this issue for you. They provide alternate ways to show information to users, and then to let those same users interact with your app properly. The end result is that if you have a visually impaired user, you do not need to write a screen reader for your app. There is already one available via an accessibility service, which is called TalkBack. Currently, you do not directly use each accessibility service. Instead, you just write your app, and then the Android framework can communicate with these accessibility services.

当您与手机进行交互时，您可以将所有这些交互划分为手机向您提供诸如文本，按钮和图像之类的信息。 接下来，作为用户，可以指示像按这些按钮并在周围滑动一样在电话上动作。 您的操作可能会导致显示更多信息，并且该循环将继续进行响应。 具有可访问性的用户需要通过以多种方式显示该信息而受益。 此外，他们还可以通过多种方式与Android应用进行交互。 例如，如果拖放是使用Android应用程序的唯一选择，那么运动障碍的用户可能难以与您的应用程序进行交互。 同样，如果视障用户只有文本选项，则他们几乎不会理解显示给他们的信息。 因此，辅助功能服务可帮助您解决此问题。 它们提供了其他方式来向用户显示信息，然后让这些相同的用户与您的应用正确交互。 最终结果是，如果您有视觉障碍的用户，则无需为您的应用编写屏幕阅读器。 通过无障碍服务(称为“话语提示”)可以使用一种服务。 当前，您不直接使用每个辅助功能服务。 相反，您只需编写您的应用程序，然后Android框架即可与这些可访问性服务进行通信。

Most of the time if you are using standard views such as TextViews and Buttons, they are built to work with the framework to provide accessibility out of the box. It means that the majority of the cases, they will demonstrate information, and allow users to perform actions using their accessibility service of choice. For example, as you are using TalkBack, you can be able move to various elements of the screen, and then there is some texts that are read to you. For this switch, TalkBack will read, “also vibrate for calls”, Off Switch, and “double tap to activate”. TalkBack gives you the label, the state of the control, the control type, and the action to interact with it. Additionally, this is presented in a standardized way that a TalkBack user is used to. As a user, you can double tap anywhere on the screen. That switch will then flip, and TalkBack will reply, “on”. For standard widgets like the switch, all this functionality comes for free.

大多数情况下，如果您使用的是诸如TextViews和Buttons之类的标准视图，则它们是与框架一起使用的，以提供现成的可访问性。 这意味着在大多数情况下，它们将演示信息，并允许用户使用其选择的辅助功能执行操作。 例如，当您使用“话语提示”时，您可以移至屏幕的各个元素，然后读取一些文本。 对于此开关，“ 话语提示”将显示为“也为通话而振动”，“关闭开关”和“双击以激活”。 “话语提示”为您提供标签，控件的状态，控件类型以及与其进行交互的操作。 此外，它以话语提示用户习惯的标准化方式呈现。 作为用户，您可以双击屏幕上的任意位置。 然后，该开关将翻转，“话语提示”将回复“打开”。 对于标准小部件(如开关)，所有这些功能都是免费提供的。

无障碍服务的一些例外 (Some exceptions for accessibility services)

To be more specific, there are some situations where the framework cannot just automatically tell accessibility services like TalkBack what to say. Images are prime example of this condition. The framework will not know how to interpret the three lines and explain this fab to the user. Therefore, it is going to mention something unhelpful like “Unlabeled button”. In other words, in some cases you will require to fill in the gaps like this for the accessibility framework. To achieve this goal, you should use the accessibility APIs as follows:

更具体地说，在某些情况下，框架不能仅仅自动告诉诸如TalkBack之类的可访问性服务该说什么。 图像是这种情况的主要示例。 该框架将不知道如何解释这三条线，并向用户解释该工厂 。 因此，将提及诸如“未标记的按钮”之类的无用的东西。 换句话说，在某些情况下，您将需要为可访问性框架填补此类空白。 为实现此目标，您应按以下方式使用可访问性API：

1. Adding labels for images unless decorative为图像添加标签，除非具有装饰性

2. Clickable links in spans

2.跨度中的可点击链接

3. Making a ViewGroup an “Alert Window”

3.使ViewGroup成为“警告窗口”

4. Changing “double tap to activate” to “double tap to toggle”

4.将“双击激活”更改为“双击切换”

For all of these cases, you would use the accessibility APIs to make those changes effectively. Moreover, issues start getting more complicated when you stray from the standard views. In short, custom views need more work to accomplish. You should be leveraging accessibility code that has already been written for you. So, for instance, if you extend for a Button, you will obtain all of accessibility features such as label, state, control type, and action from view, TextView, and Button. In summary, for most cases, if you use standard components, the Android framework will take care of interacting with the accessibility services. Furthermore, when the framework requires more details, you will provide that information using the accessibility APIs to fill in those gaps.

对于所有这些情况，您将使用可访问性API有效地进行那些更改。 此外，当您偏离标准视图时，问题开始变得更加复杂。 简而言之，自定义视图需要完成更多工作。 您应该利用已经为您编写的辅助功能代码。 因此，例如，如果扩展为Button，则将从视图，TextView和Button获得所有可访问性功能，例如标签，状态，控件类型和操作。 总之，在大多数情况下，如果您使用标准组件，则Android框架将负责与辅助功能服务进行交互。 此外，当框架需要更多细节时，您将使用可访问性API提供该信息以填补这些空白。

主要的可访问性问题 (The main accessibility problems)

1. Missing labels

1.缺少标签

Fundamentally, missing labels make it hard for screen reader users to know the aim of your controls. In other words, unlabeled Button is not particularly useful as a label. However, that is what a screen reader like TalkBack declares if you do not provide a meaningful label in your Android application.

从根本上说，缺少标签会使屏幕阅读器用户很难知道控件的目的。 换句话说，未标记的Button作为标签并不是特别有用。 但是，如果您未在Android应用程序中提供有意义的标签，那么类似TalkBack的屏幕阅读器便会声明该内容。

2. Inadequate touch targets

2.触摸目标不足

Touch targets that are extremely small could be challenging for users with dexterity issues, or even for users who may have large hands, or those who may be using your app when sitting in a bus or a car.

对于具有灵活性问题的用户，甚至对于可能有大手的用户，或者坐在公共汽车或汽车中使用您的应用程序的用户，极小的触摸目标都可能具有挑战性。

3. Low contrast

3.低对比度

Low contrast can make it relatively difficult for many users to properly digest the content of your screen. Instances where the pair of colors used for a text element and the background behind that element has a lower color contrast ratio than suggested.

低对比度会使许多用户相对难以正确地消化屏幕内容。 用于文本元素和该元素后面的背景的一对颜色具有低于建议的颜色对比度的实例。

使用辅助功能扫描仪 (Using Accessibility Scanner)

At the moment, the vital question would be: how do you find out if your Android app has these issues? A recommended point to start is with Accessibility Scanner, which is a free app that you can download from the Play Store. Accessibility Scanner performs an audit of whatever is visible on the screen, and makes suggestions for enhancing the app’s accessibility. Generally, it is extremely easy to use during the development, and you do not even need to be particularly technical to use it. Besides, you can share Scanner’s reports by email or through Google Drive. As a result, Accessibility Scanner is an indispensable tool for developers. Scanner can be run on any app, and does not require any special code changes as well. Scanner gives you details about the foreground and the background colors, and recommends a contrast ratio you should aim for. The contrast issue that are recommended: Large text: 3.00 and Smaller text: 4.50. Another suggestion could be about the touchable area for the Button. For example, Scanner indicates that your button is 24 * 24 DPs, but you really should aim for at least 48 * 48 DPs. You could either make your icon bigger, or you can expand the touchable area by adding padding or registering a touch delegate.

目前，至关重要的问题是：如何确定您的Android应用是否存在这些问题？ 推荐的入门点是Accessibility Scanner ，它是一个免费的应用程序，可以从Play商店下载。 辅助功能扫描程序会对屏幕上可见的内容进行审核，并提出增强应用程序辅助功能的建议。 通常，在开发过程中使用它非常容易，并且甚至不需要特别的技术来使用它。 此外，您可以通过电子邮件或Google云端硬盘共享扫描仪的报告。 因此，对开发人员而言， 可访问性扫描仪是必不可少的工具。 扫描仪可以在任何应用程序上运行，并且也不需要任何特殊的代码更改。 扫描仪为您提供有关前景色和背景色的详细信息，并建议您要达到的对比度。 建议使用对比度问题：大文本：3.00，小文本：4.50。 另一个建议可能是关于按钮的可触摸区域。 例如，“扫描程序”指示您的按钮为24 * 24 DP，但是您实际上应该至少瞄准48 * 48 DP。 您可以增大图标的大小，也可以通过添加填充或注册触摸代表来扩展可触摸区域。

缺少标签和最佳做法 (Missing the label and best practices)

It is significant to provide users with helpful and descriptive labels for each interactive UI element in your app. Each label should explain the meaning and purpose of a particular element. Screen readers like TalkBack can announce these labels to users who rely on these services. In most situations, you can specify a given UI element’s description in the layout resource file that includes this element. For internationalization reasons, this should always be a localized string. Also, when a labeling editable views like EditText, you should set the Android hint attribute:

为用户提供应用程序中每个交互式UI元素的有用和描述性标签非常重要。 每个标签都应说明特定元素的含义和目的。 像TalkBack这样的屏幕阅读器可以向依赖这些服务的用户发布这些标签。 在大多数情况下，您可以在包含该元素的布局资源文件中指定给定UI元素的描述。 出于国际化的原因，这应该始终是本地化的字符串。 另外，在标记可编辑视图(如EditText)时，应设置Android提示属性：

android:contentDescription=”…”android:hint=”…”

Moreover, if an element in your UI exists only for visual purposes, you should set its Android content description to “null” as follows:

此外，如果UI中的元素仅出于视觉目的而存在，则应将其Android内容描述设置为“ null”，如下所示：

android:contentDescription=”@null”

Another recommendation is that if your app supports only devices that run on Android 4.1, API level 16, or higher, you can instead set these purely decorative element “android important For Accessibility Attribute”

另一个建议是，如果您的应用仅支持在Android 4.1，API级别16或更高版本上运行的设备，则可以将这些纯粹的装饰性元素设置为“ Android重要的可访问性属性”

android:importantForAccessibilityAttribute=”no”

使用发布前报告 (Using Pre-launch reports)

Initially, pre-launch reports are automatically generated when you upload an APK for release on the Play Store. This is an automated testing solution, which crawls Android applications on multiple physical devices, and identify issues you can fix before your app reaches the end users. It detects crashes, performance issues, and a few other matters. Now, it consists accessibility. Pre-launch reports could be found on the Google Play console, and you can be able to see the list of issues identified in a report. So, you can fix those issues before launching your app on the market. In general, issues are categorized, clustered, and ranked by severity. You can consider some issues in the report like incorrect contrast ratio. Also, the report suggests a way to improve the contrast. So, if you are new to accessibility issues, this could be a useful method in practice.

最初，当您上传APK以在Play商店中发布时，会自动生成预发布报告。 这是一种自动化测试解决方案，可在多个物理设备上抓取Android应用程序，并在您的应用程序到达最终用户之前确定可以解决的问题。 它检测崩溃，性能问题以及其他一些问题。 现在，它包括可访问性。 可以在Google Play控制台上找到发布前的报告，并且您可以查看报告中确定的问题列表。 因此，您可以在市场上启动应用程序之前解决这些问题。 通常，按严重性对问题进行分类，聚类和排名。 您可以考虑报告中的一些问题，例如对比度不正确。 此外，该报告还提出了一种改善对比度的方法。 因此，如果您不熟悉可访问性问题，那么在实践中这可能是一个有用的方法。

测试您的android应用的可访问性 (Testing your android app’s accessibility)

Obviously, testing for accessibility allows you experience your app from the perspective of your users, and find usability issues that you might otherwise miss. Accessibility testing can demonstrate opportunities to make your app more powerful and versatile for all your kinds of users, including those with disabilities.

显然，通过可访问性测试，您可以从用户的角度体验应用程序，并发现您可能会错过的可用性问题。 可访问性测试可以证明有机会使您的应用程序对包括残障人士在内的所有类型的用户而言更加强大和通用。

To have the best results, you should use all of the below approaches in practice:

为了获得最佳结果，您应该在实践中使用以下所有方法：

1. Manual testing: Interact with your app using Android accessibility services.

   手动测试：使用Android辅助功能与您的应用互动。

2. Testing with analysis tools: Use tools to consider opportunities to improve your app’s accessibility.

2.使用分析工具进行测试：使用工具来考虑改善应用程序可访问性的机会。

3. Automated testing: Turn on accessibility testing in Espresso and Robolectric.

3.自动化测试：打开Espresso和Robolectric中的辅助功能测试。

4. User testing: Get feedback from real people who interact with your application.

4.用户测试：从与您的应用程序交互的真实人那里获得反馈。

自动化测试 (Automated testing)

Behind the scenes, both the Accessibility Scanner and the APIs for automated accessibility testing use Accessibility Test Framework (ATF) to run. ATF powers the two main automated testing integrations with Espresso and Robolectric. In fact, ATF is open source, and is based on evaluation (accessibility checks).

在后台，可访问性扫描程序和用于自动可访问性测试的API均使用可访问性测试框架(ATF)来运行。 ATF为Espresso和Robolectric的两个主要自动化测试集成提供支持。 实际上，ATF是开源的，并且基于评估(可访问性检查)。

ATF and Espresso integration

ATF和Espresso集成

The aim of this integration is to carry out your existing Espresso tests and to make them also test for accessibility issues. Basically, this could be accomplished with just a single line of code. So, assuming you already have those Espresso tests, this is a very easy to add.

集成的目的是执行您现有的Espresso测试，并使它们也测试可访问性问题。 基本上，这仅需一行代码即可完成。 因此，假设您已经进行了Espresso测试，那么添加起来非常容易。

AccessibilityChecks.enable()

So, the complete code could be mentioned as follows:

因此，完整的代码可以提到如下：

import androidx.test.espresso.contrib.AccessibilityChecks@RunWith(AndroidJUnit4::class)@LargeTestclass MyWelcomeWorkflowIntegrationTest {    companion object {        @Before @JvmStatic        fun enableAccessibilityChecks() {AccessibilityChecks.enable()        }    }}

By default, if your Espresso tests run into accessibility issues, exceptions would be thrown and your test will fail. However, you can use the accessibility validator to simply log the test failure instead. To do this task, you can change “setThrowExceptionsForErrors” to “false”. Now, when you are doing this task, it is easy to forget to check your logs. Throwing an exception will get your attention, which is why it is the default. Another choice that you have, if you do not want to turn off exceptions for all tests, is to use the “setSuppressingResultMatcher”. This choice allows you to suppress accessibility testing exceptions related to either specific views or ATF checks. For example, if you know of a particular Button with a contrast issue, you could suppress contrast checks for that Button using this code. In general, you want to be as specific as possible when disabling ATF checks. Eventually, using ATF is as simple as enabling accessibly checks and making sure to use ViewAction. Optionally, you can config how ATF runs using an accessibility validator. The ATF defines several matchers to help you define, which outcomes to display in your Espresso tests. The following example suppresses the results of checks that relate to a single TextView element's color contrast.

默认情况下，如果您的Espresso测试遇到可访问性问题，则将引发异常，并且测试将失败。 但是，您可以使用可访问性验证器来简单地记录测试失败。 要执行此任务，可以将“ setThrowExceptionsForErrors ”更改为“ false”。 现在，当您执行此任务时，很容易忘记检查日志。 引发异常将引起您的注意，这就是为什么它是默认值。 如果不想关闭所有测试的异常，则可以选择的另一种选择是使用“ setSuppressingResultMatcher ”。 此选择使您可以禁止与特定视图或ATF检查有关的可访问性测试异常。 例如，如果您知道某个特定按钮存在对比度问题，则可以使用此代码来取消对该按钮的对比度检查。 通常，在禁用ATF检查时，您希望尽可能具体。 最终，使用ATF就像启用可访问性检查并确保使用ViewAction一样简单。 (可选)您可以使用可访问性验证器配置ATF的运行方式。 ATF定义了多个匹配器以帮助您定义在Espresso测试中显示的结果。 下面的示例取消与单个TextView元素的颜色对比度有关的检查结果。

AccessibilityChecks.enable().apply {        setSuppressingResultMatcher(                allOf(                    matchesCheckNames(`is`("TextContrastViewCheck")),                    matchesViews(withId(R.id.countTV))                )        )}

ATF and Robolectric integration

ATF和Robolectric集成

It is very similar to previous one. You just only require to add the @AccessibilityChecks annotation to start leveraging your Robolectric tests to run accessibility checks.

它与上一个非常相似。 您只需要添加@AccessibilityChecks批注即可开始利用Robolectric测试运行可访问性检查。

手动测试 (Manual testing)

Manual testing for accessibility can catch issues not found by tools like Scanner or through automated testing. For instance, Scanner or automated tests can find missing labels; however, they cannot check if the labels are meaningful. That is where manual testing can help. In this form of testing, you test apps using accessibility services. Google recommend that, at least, you should test your app using TalkBack and Switch Access. At Google, they found that most successful app teams are those that adopt both automated and manual accessibility testing techniques as part of their development process. TalkBack exposes two common modes of navigation. Firstly, linear navigation, when a user performs swipe gestures to explore content on the screen and double taps anywhere to click on a view. Second, explore by touch when a user drags a finger over the screen to discover content, and once again, the user double taps anywhere to perform a click. Users can perform common tasks like navigating to home or opening a notification by performing simple gestures. You should explore the app with TalkBack. In addition, as you navigate, check for the following questions. Are you able to reach every element by swiping? Are you able to complete the main workflows of your app? Does the spoken feedback for each element convey its purpose appropriately? Are announcements brief, or are they needlessly verbose?

手动进行可访问性测试可以发现Scanner之类的工具或通过自动测试未发现的问题。 例如，扫描仪或自动测试可以找到丢失的标签； 但是，他们无法检查标签是否有意义。 这就是手动测试可以提供帮助的地方。 通过这种测试形式，您可以使用可访问性服务来测试应用程序。 Google建议至少，您应该使用“话语提示”和“切换访问”来测试您的应用。 在Google，他们发现大多数成功的应用程序团队都是在开发过程中采用自动和手动可访问性测试技术的团队。 “话语提示”展示了两种常见的导航模式。 首先，线性导航，当用户执行滑动手势以浏览屏幕上的内容并在任何地方双击以单击视图时。 其次，当用户在屏幕上拖动手指以发现内容时，通过触摸进行浏览，然后用户再次在任何地方双击以执行单击。 用户可以执行常见的任务，例如导航到家中或通过执行简单的手势来打开通知。 您应该使用“话语提示”浏览该应用。 另外，在导航时，请检查以下问题。 通过滑动就能触及每个要素吗？ 您是否能够完成应用程序的主要工作流程？ 每个元素的语音反馈是否适当地传达了其目的？ 公告是简短的还是不必要的冗长？

Furthermore, you can be able to find a Switch Access on the accessibility screen under Settings. To do test, you can configure the volume keys to scan the app and make selections. So, you must turn on Switch Access and start testing your app. More specifically, look for the following questions. Are you able to reach each and every element? Are you able to complete the main workflows easily? If you have text or other inputs, can you add and edit content easily?Are items highlighted only if you can perform actions with them?

此外，您可以在“设置”下的辅助功能屏幕上找到“切换访问”。 要进行测试，您可以配置音量键来扫描应用程序并进行选择。 因此，您必须打开Switch Access并开始测试您的应用程序。 更具体地说，寻找以下问题。 您能够触及每一个要素吗？ 您能够轻松完成主要工作流程吗？ 如果您有文字或其他输入内容，是否可以轻松添加和编辑内容？仅当您可以对它们执行操作时，项目才会突出显示吗？

用户测试 (User testing)

User testing with real users with accessibility needs is vitally important. Also, if you test the app by yourself, you are never going to know exactly how a visually impaired user, for example, experiences your app unless you happen to be a visually impaired user. You should find actual users in this way. Sometimes, you can leverage your network to do this task. You can also find testing agencies. There are specific agencies that specialize in accessibility user testing. Another important note is that you should pay attention to feedback from all sources by reviewing and considering all reports and issues.

对具有可访问性需求的真实用户的用户测试至关重要。 此外，如果您自己测试应用程序，则除非您碰巧是视障用户，否则您永远不会确切知道视障用户的体验。 您应该以这种方式找到实际用户。 有时，您可以利用网络来执行此任务。 您还可以找到测试机构。 有专门从事可访问性用户测试的特定机构。 另一个重要说明是，您应通过审查和考虑所有报告和问题来注意所有来源的反馈。

应用程序开发中的一些辅助功能测试策略 (Some accessibility testing strategy in app development)

It is obvious that Android apps can work properly when there is a comprehensive accessibility testing strategy as follows:

很明显，当存在如下全面的可访问性测试策略时，Android应用程序可以正常运行：

1. Testing with tools: During development process and release cycles

   使用工具进行测试：在开发过程和发布周期中

2. Using automated testing: To detect common issues quickly and on pre-submit and with Continuous Integration (CI).

2.使用自动化测试：在提交前以及使用持续集成(CI)来快速检测常见问题。

3. Using manual testing: To understand a user’s actual experience

3.使用手动测试：了解用户的实际体验

4. Using user testing: Solicit feedback from all users.

4.使用用户测试：征求所有用户的反馈。

结论 (In conclusion)

As a matter of fact, accessibility is about building products that everyone can use easily and efficiently. As an Android developer, this is about developing Android apps that can be used by every user, regardless of how they interact with the device. This essay considered some accessibility best practices and issues in Android development.

实际上，可访问性是指构建每个人都可以轻松高效地使用的产品。 作为一名Android开发人员，这是关于开发可被每个用户使用的Android应用程序，无论他们如何与设备交互。 本文考虑了Android开发中的一些可访问性最佳做法和问题。