Hi, nice to meet you! 👋 🏻

In this article, I’m going to share some of the best practices for Android accessibility. I hope this article will help you and your specific user groups.

preface

Recently our team received some feedback from users:

According to users’ feedback, some of our function buttons cannot be recognized normally under barrier-free conditions. In fact, this is not the first time I have seen the feedback, the first time was in 2016, the ios terminal received user feedback, made an optimization. To be ashamed, it is our Android side has not been specially adapted.

What are accessibility features?

For some visually impaired or hearing-impaired people, ordinary apps may be difficult to use. On Android, for these users, the device is mainly controlled by TalkBack, a screen reader attached to the system.

Therefore, accessibility is an important part of application development. By integrating accessibility features and services, it can improve the ease of use of applications, especially for users with disabilities.

Background and Current Situation

China now has 16.91 million visually impaired people, 27.8 million hearing-impaired people and 29.77 million physically disabled people, according to the 7th national Census in 2021, according to the official website of China Internet Network Information Center.

At home, specially to deal with not too much, many developers because it did not know why (we mentioned below), and relative income may not be high and generally has no user feedback, it has been too much, for accessibility features, may be part of the tool more often in the App, For example, some plug-ins such as grab red envelopes.

The adaptation of barrier-free functions is relatively common in foreign countries, and even some countries may not be able to put on the shelves if they do not adapt;

Throughout the industry, Tencent products do better in this respect, of course, this and their internal standard development rules and huge user groups also have a relationship.

So why don’t most developers know?

In fact, the main reason is that the Android native UI is not mandatory for accessibility, so most domestic developers don’t even pay attention to accessibility when they first enter Android, so it seems that it is not that important in China, as shown below:

We normally write the layout in XML, and the default compiler prompts us, but since it’s not mandatory, it doesn’t seem to involve [contenDescription] at all if you don’t hit prompt (Option + Enter), as shown below:

This is not official inaction, on the contrary, the Android team has been working to improve this aspect of the experience, and the compiler has been prompting us to do as much optimization as possible. But it has more to do with the fact that Android’s native UI is deeply rooted in accessibility, i.e., non-explicit.

Technical support

For a long time, the Android team has been advising us to adapt accessibility features, and there is even an official website and documentation describing it, which is also mentioned at the annual IO Conference:

Android native UI- Build more accessible apps

Compose – Support for accessibility

Googleio-2021 – Accessible segmentation

Is it difficult to adapt without obstacles?

No, thanks to official support, we developers have very little to do.

For Android native UIs, if the application mainly uses [system components], the experience will not be too bad in accessibility, such as the common Text, Button. In barrier-free conditions, the corresponding display text information will be read as the description.

What if I use Compose for UI development?

It seems that the Android team has also figured out this problem that used to be optional, perhaps benefiting from the ease of declarative development.

Compose is much more accessible than the native UI. If you are using a non-text component, you must pass the corresponding contentDescription. This value can also be null, but you must explicitly declare it. As follows:

So the technical level is not a problem at all, all we developers need to do is pay attention to some buttons in the development or add some description to the image, so that it can be adapted to barrier-free features at a very low cost.

Accessibility mode development guidelines

  • followMaterialAccessibility development rules in
  • forThe TextOf the classViewAdd suitablecontentDescription
  • For someDecorative UI elementsRemove labels and focus
  • EditTextthroughhintSet up the label
  • More complex pages are usedGrouped togetherThe way of
  • Barrier-free adaptation of custom views

Adaptive skills

Through the following tips, you can quickly master the adaptation, landing into the development.

Ps: This will be updated continuously and will be synchronized as more practices become available in the business.

Add a description to your View

For components inherited from the TextView class, the Android framework itself can read the text information, so in general, we do not need to manually adapt again, we mainly need to adapt the Image or a class of components that cannot be described.

Add the corresponding description as shown below.

android:contentDescription="xxx"
Copy the code
view.contentDescription="xxx"
Copy the code

Use ImageBtn instead of Image

For buttons (that is, actions that you can interact with), Android officials recommend using an ImageButton instead of a normal ImageView.

I believe that many students define their Bar, must use the Image as the return button, this is also very common, but why the official recommendation for everyone to use ImageButton?

This is mainly because when adapting to the barrier-free mode, when the barrier-free service reads the Image, if the description information is added at this time, it will directly read the text name, but what if it is a button that can be interactive?

For us ordinary users, we know we can click here, but they don’t know, so if we use ImageButton here, the feedback under accessibility is:

XxxApp, back button. Double click to go to next

For visually impaired users, this will improve their ease of use to facilitate their use.

Modifies the selected state of a non-standard component

Similar to the screenshot above, if the selection box is defined using ImageView, the accessibility service will not be able to recognize the corresponding state.

If the default components such as CheckBox or Switch are used, the corresponding state can be read correctly. If the control cannot be adjusted directly due to business problems, the control can be indirectly added to the barrier-free state by manually adding barrier-free proxy, as shown in the following code:

view.accessibilityDelegate = object : View.AccessibilityDelegate() {
            override fun onInitializeAccessibilityNodeInfo(
                host: View? , info:AccessibilityNodeInfo?). {
                super.onInitializeAccessibilityNodeInfo(host, info) info? .isCheckable =true
                // Set the selection stateinfo? .isChecked = isSelect } }Copy the code

Increase the touch range of buttons

In the MD design, the touchable range of the button is at least 48dpx48DP, so if our button size is insufficient, we can optimize it in the following directions:

  • usepaddingAdd padding around the button icon
  • usetouchDelegateFor details, seeReading knowledge source long | originally can enlarge the View click area

With the focus

For part of the View, we might not want to be read under the accessibility, or needs to be some View merging, at this time can increase importantForAccessibility for its properties, the default provides the following options:

<attr name="importantForAccessibility" format="integer">
            <! -- Default behavior, the system automatically determines whether to read the child view according to its type -->
            <enum name="auto" value="0" />
            <! Allow access in barrier-free mode -->
            <enum name="yes" value="1" />
            <! -- Disable access in barrier-free mode -->
            <enum name="no" value="2" />
            <! All views are disabled from accessibility mode -->
            <enum name="noHideDescendants" value="4" />
</attr>
Copy the code

Example:

For example, in the above example, if there is no special description, by default, when clicked, only TextView will be triggered in the red box in barrier-free mode, which is obviously not what we want. In this case, we can move the contentDescription up to the ViewGroup in the external red box.

Accordingly, in some business rules, if you do not want it to be selected in accessibility, such as [Micro-blog] if it is not installed at this time, you can ignore its focus and disable accessibility in accessibility:

android:focusable="false" 
android:focusableInTouchMode="false" 
android:importantForAccessibility="no"
Copy the code
view.isFocusable = false
view.isFocusableInTouchMode = false
view.importantForAccessibility = IMPORTANT_FOR_ACCESSIBILITY_NO
Copy the code

Compatible with custom View

Our project will have more or less a lot of custom views, some based on views, some based on ViewGroup composition effects. So how to make compatible with custom View?

SetContentDescription () can be called for all View pages.

Note that if your custom View is a Button and you don’t use an ImageButton or inherit it from a Button, then if you add contentDescription, the View will only read the description when clicked without any barrier. However, ImageButton or Button will be read as XX Button in barrier-free mode. By contrast, the latter is more symbolic of a behavioral effect, while the former is just like an ordinary text, which will have a lot of impact on the experience of visually impaired users.

So how do we quickly integrate?

It’s pretty simple, but if you look at the difference between an Image button and an Image, what do you see?

GetAccessibilityClassName (), we only need to return the corresponding Class Name. So if you have a View that has an action or represents a custom Button, you can override this method and return a Button, or an ImageButton, so that in accessibility mode it will be judged to be an interactive Button.

Of course, strictly speaking, we should use system components whenever possible, but business changes make it impossible to do so all the time, so the above solution is a bit of a cheat.

For more information about the adaptation of custom views, you can check out the Official Android documentation – making custom views easier to use, which is mainly about barrier-free proxy classes to achieve.

Test your accessibility fit

In turn, Google provides some tools to see if your fit is right.

For example, the official use of the scanner is as follows.

The accessibility scanner is mainly used to scan all views on the current screen and give suggestions, mainly including the following aspects:

  • The content label
  • The size of the target to be touched
  • Whether there is something clickable
  • Contrast between text and images

We can use it as a reference.

For example:

It will automatically flag up views that we think can be optimized, some for touch buttons that are too small, some for contrast, which can be adjusted quickly during development.

Afterword.

Hi, here are some of my personal thoughts, but I still think I should write them out. I think every technical student loves their users, so if we can do better, we don’t want to do badly. Although sometimes due to the busy time, we are still willing to do better.

I am a sensitive person. The first time I saw the feedback about accessibility was a few months ago. One of my colleagues in the group sent a screenshot.

When I first saw this, it was kind of sad and kind of happy.

As a developer, our App is used by most people, which is a feeling of approval; And it’s kind of sad that we can do better. So on that day, I made a post like this:

Adapting to accessibility is not that difficult, the Android team has done a lot, and we as developers can write better accessibility experiences with a little attention.

The technique should have [depth], but it can also have [temperature].

Who is he who comes from mountains, lakes and seas, but is confined to day and night, kitchen and love

Omnipotent Youth Hostel Band

reference

  • Keep track of Android accessibility practices
  • Android accessibility guidelines
  • Make custom views easy to use
  • Android accessibility help

I am Petterp, a third-rate development, if this article is helpful to you, welcome to like support, your support is my continuous creation of the biggest encouragement!