Vài best practice khi hỗ trợ accessibility trong android

[siliconprime-thanhduc]

Trong Google IO 2019 đầu năm nay, có 1 chủ đề được thuyết trình đó là Mobile Accessibility: making sure everyone can use what you create.

Thành và @phucledien thấy đây là 1 chủ đề đáng lưu ý mà hiện tại đa số những bạn lập trình viên ko để ý tới. Sau khi research về topic này, thì những lý do vì sao nên support Accessibility sẽ ko đề cập đến trong bài viết này. Xin chỉ note lại những best practice để khi lập trình chúng ta sẽ follow để có thể improve được app cho những người dùng bị khiếm khuyết có thể sử dụng.

*Bật tính năng TalkBack (tính năng để support accessibility) : Có thể xem hướng dẫn tại đây https://codelabs.developers.google.com/codelabs/basic-android-accessibility/index.html#2 Hướng dẫn sử dụng app khi đã enable TalkBack: https://codelabs.developers.google.com/codelabs/basic-android-accessibility/index.html#3

Content Labeling Tip for developer:

• Hint: It is a best practice to use android:hint instead of contentDescription on EditTexts.
• Do not add placeholder labels to dismiss lint warnings. Temporary lint warnings reminding you to add content descriptions to clickable content (or other placeholder descriptions) can be confusing.
• While it is common to override setContentDescription, you should never override getContentDescription().

Here are some tips that can enhance the experience for TalkBack users:

• Keep content brief. This is especially applicable to users w/braille displays, which are often limited to 40-character lines.
• Don't include words that describe how users should physically interact (e.g. click, tap, press) with your controls in your content description. Let the AccessibilityService itself take care of that. Accessibility includes more than just TalkBack users - for example, Switch Access or Voice Access users will not physically touch the screen at all.
• Have the most semantically important information come first in your content label. This way, if users don't need or want to hear the rest, they can mute audio feedback.

Grouping Content

The best practices for grouping and ordering elements in an accessible manner can be summarized like this:

• The view hierarchy order and on-screen positioning determine grouping and ordering of text in spoken feedback.
• You should group non-focusable items in a focusable container to have them read as a single item.
• If necessary, set an android:ContentDescription on a container to override automatic grouping and ordering of contained items (we didn't need to do this in the codelab).
• To logically group related items, it is sometimes necessary to create nested ViewGroups.

Using a Live Region

Carefully consider when using live regions, as announcements for frequently changing views can be disruptive and annoying. Live regions can easily be overused, especially when you're just starting out with accessibility. Live regions are the exception, not the rule.

Custom Views

• Since the Android framework has baked in accessibility in its default widgets, you should always try to extend these whenever possible. If a custom view is absolutely necessary, you need to make it accessible. If you don't, a service like TalkBack will skip it entirely, badly degrading the experience for users.
• Complex views that act as containers require special attention, since children need separate focus, clickable actions, etc.

Turning off TalkBack

Hint: scrolling with two fingers in TalkBack is equivalent to scrolling with one finger when not using TalkBack.

Making Touch Targets Large

• In general, you want the touchable area of focusable items to be a minimum of 48dp X 48dp. Larger than that is even better.
• Hint: Adding minWidth and minHeight is just one way of expanding the touch area of a view. You can also achieve similar results with adding padding or using the TouchDelegate API.

Ensuring Adequate Color Contrast

• Low contrast ratios between foreground and background colors can cause views to blur together for some users
• The Web Content Accessibility Guidelines recommend a minimum contrast ratio of 4.5:1 for all text, with a contrast ratio of 3.0:1 considered acceptable for large or bold text, and you should try to meet or exceed these contrast ratios in your applications.
• You can use one of the many contrast checkers available online to check your contrast ratios. Or, you can use the Accessibility Scanner.

Accessibility Scanner

• Google offers an Accessibility Scanner tool that suggests accessibility improvements for Android apps—such as enlarging small touch targets, increasing contrast, and providing content descriptions—so that individuals with accessibility needs can use your app more easily.
• Note: while tools like Scanner can help you easily resolve low-hanging fruit bugs in your apps, they're no replacement for manual testing.
• Accessibility needs to be approached holistically - Scanner, for example, won't tell you if your user interface conveys semantic information simply and clearly, or how well it supports multiple modes of interaction (touch vs voice), or if performing your app's most common use cases with TalkBack is efficient.
• Always remember to test with real users.

Reference: https://developer.android.com/guide/topics/ui/accessibility https://codelabs.developers.google.com/codelabs/basic-android-accessibility/index.html#0