DEV Community: Sigute

Accessible Text Scaling for Android

Sigute — Thu, 11 Mar 2021 20:18:08 +0000

Do you ever open the app and cannot read the full text because it's cut off in some way? This scenario became frequent to me once I increased the font size on my phone. Technology agency from the Netherlands, Q42, carried out extensive research on 1.5 million iOS users and found that as many as 33% of people change the text size on their phone, and increasing text size is more common than making the text size smaller (20% increasing vs 13% decreasing). With such a large percentage, it is reasonable to assume that Android users likely also change these settings in similar frequency.

That is a big group of people, which makes it really important to consider how this setting will be supported when developing and testing your apps.

Common issues and solutions

I have been using various apps on my phone with non-default text and density settings. Reducing font size rarely causes any issues. However, even slightly larger than the default font size often means that a lot of issues appear. The following problems are the most common and often easily fixed.

1. Text does not scale

In some apps, after changing the font size, the text does not scale up at all. This is the number one issue on the list. While the layout is displayed correctly and text is visible, the user is not able to gain any benefit from the device setting and, as such, will struggle with reading the text.

Most of the time this is caused by using dp for text sizing instead of sp. dp, density-independent pixels, are used for displaying consistently sized user interface across any screen size. sp, scalable pixels, have the same default value as dp. However, sp changes with the user's font preference and dp does not. This means sp should be used for text elements so the size of the text will increase or decrease with the device setting.

In this screenshot, you can see how the text defined in dp remains the same size regardless of the user's font preference.

In other cases, the text does not scale because it is part of the image, instead of TextView. Providing content description is important for these scenarios, however just providing content description is not enough for an accessible solution. Not every user with vision issues is using Talkback: a better approach is using TextView over the image, as then the text size can still be increased.

Lastly, autosizing TextViews can also cause the issue of the text not scaling in an expected way. This solution ensures that the text fits inside the view nicely and layouts do not break, but this doesn't always provide a benefit if the user is not able to easily read the text at that size. The limits need to be set carefully and testing with different font and density combinations will help to spot issues when using autosizing.

In the screenshot, the top TextViews do not use autosizing, meaning the text does not fit as it grows longer and the font size is increased. With autosizing, the issue appears to be fixed, as all the text is visible. However, it is not a full solution, as while the text is now visible it is very small. In this case there is no easy fix in the code, and the design should be reimagined to support longer text better.

2. Text is cut off

In this scenario the text is cut-off in some way. Often half a line or the end of the text is missing. This usually indicates an issue with the layout constraints.

To resolve this, prefer wrap_content and minHeight/Width over hardcoding layout limits. This allows the content to scale to different lengths and sizes. When using constraint layout, make sure to set start AND end constraints, so the view does not end up out of visible screen space.

In this screenshot, TextView height is constrained, so when the text grows beyond the height, it gets unreadable. In the code below, adding the minHeight attribute instead of fixed height allows the field to grow and remain usable.



<TextView
            android:layout_width="wrap_content"
            android:layout_height="32dp"
            android:text="Hello"
            android:textSize="48sp" />

<TextView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:minHeight="32dp"
            android:text="Hello"
            android:textSize="48sp" />

In this screenshot, the text has grown beyond the boundary of the screen. This can easily happen if the content is coming from the API and is longer than it was initially expected to be, especially with increased font size. Where no issues would happen in the following code example with short text, it's important to think about having constraints at both sides of the elements to avoid issues when the text length changes.



    <TextView
        android:id="@+id/title"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginStart="40dp"
        android:text="Title" />

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="0dp"
        android:text="@string/long_text"
        app:layout_constraintStart_toStartOf="@+id/title"
        app:layout_constraintTop_toBottomOf="@+id/title" />

Adding a constraint for the end as well fixes this issue and all text remains visible.



    <TextView
        android:layout_width="0dp"
        android:layout_height="0dp"
        android:text="@string/long_text"
        app:layout_constraintEnd_toEndOf="@id/title"
        app:layout_constraintStart_toStartOf="@+id/title"
        app:layout_constraintTop_toBottomOf="@+id/title" />

3. Text overlays other elements

In some cases, the views overlay each other. This causes unreadable screens, especially if several text views end up on top of each other. It can be caused by badly defined constraints. For example, an icon starts overlaying the text as the text becomes longer through the font sizing. This problem can also often be seen with translated text when some languages use much longer text than the one for which the app was designed in.

In the screenshot, TextView is not constrained at the end and grows to overlay the icon. This makes it hard to read the text and to see what the icon is to get more context.



    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Hello World"
        android:textSize="20sp"
        app:layout_constraintStart_toStartOf="parent" />

    <ImageView
        android:layout_width="wrap_content"
        android:src="@drawable/ic_android"
        app:layout_constraintEnd_toEndOf="parent"
        android:layout_height="wrap_content"/>

To fix this, TextView is constrained against the icon, so the elements cannot end up on top of each other.



<span class="nt">&lt;TextView</span>
    <span class="na">android:layout_width=</span><span class="s">"0dp"</span>
    <span class="na">android:layout_height=</span><span class="s">"wrap_content"</span>
    <span class="na">android:text=</span><span class="s">"Hello World"</span>
    <span class="na">android:textSize=</span><span class="s">"20sp"</span>
    <span class="na">app:layout_constraintStart_toStartOf=</span><span class="s">"parent"</span>
    <span class="na">app:layout_constraintEnd_toStartOf=</span><span class="s">"@+id/image"</span> <span class="nt">/&gt;</span>

Unusable ellipsizing

Another common issue is when the text scales or when the content is longer than planned for and it becomes ellipsized. Ellipsizing by itself is not an issue, it is a great technique to use in some scenarios. For example, if the user is looking at a preview of an article and can click through to the details to read more. However, the information can be easily lost in snackbars, titles, or error messages, especially if there is something crucial at the end.

There are various ways to fix this; one method is that the views could be set to allow multiple lines if the text can potentially expand over the limit. It is also helpful to think about whether the content needs to be fully visible to the user on their current screen (text in the article, error message) or whether it could be ellipsized and still make sense without the full text (clickable title in a list which links to detail).

How to test

There are a few ways to test and catch most of these scenarios.

Android Studio

When editing a layout in Android Studio, the layout can be previewed in different devices, which helps to catch issues with smaller screen sizes.

Android Studio also includes the Layout Validation tool which can show a preview with different font sizes.

Device testing

Manual testing on a device or an emulator helps to catch issues as well. Often, a small set of emulators is enough, as the device settings can be used to test different configurations. My approach is modifying the font size first and then the display size.

To sum up

Plan for flexible layouts and consider what happens when text expands beyond the default size.
Test with different font and display sizes to find issues with scaling.
We (mostly) don't build the apps just for ourselves: usability is important.

I hope this article gave you some tools to make your apps better. Code examples in the article have been shortened to only show the important lines of code. A Github repository containing the full sample code used for examples and generating screenshots is available here.

Nevertheless, Sigute Coded in 2020/2021!

Sigute — Mon, 08 Mar 2021 20:07:07 +0000

When I looked back at the past year, I asked myself, did anything really happen at all? It often felt and still feels like time became meaningless with days blending into each other... And, yet, I did realize that there achievements since last International Women's Day I would like to share!

In April, I gave my first public talk about one of the last projects I worked on at Microsoft. Meetup/conference talks are something I would like to do more of in the future.

// Detect dark theme var iframe = document.getElementById('tweet-1255558306745274368-398'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1255558306745274368&theme=dark" }

I left Microsoft and joined a healthcare company that summer. I was working as a senior Android engineer for the first time! It was really exciting to finally have this title.

To get to the senior engineer title, it took me Bachelors in Computing Science, Masters in Advanced Computer Science, 8 years of Android experience, Microsoft in my CV, and an internal referral!

...I often wonder which of these circumstances finally did it.

I am also aware that if it took me all this, it's something that's going to be even harder for many other women in this field who do not share the same privileges as me. My university degrees opened many doors, so did getting experience at a big company. I am an immigrant, but I am also white. I hear many disheartening stories and I hope that the resolutions towards more diverse workplaces that people and companies are making today will make a difference throughout the year.

The company I joined was not a match in the end... I did carry out my second job search later in the year and have recently started at my new job. I am happy at my new workplace and hope to stay there for a long time :)

Last year I also participated in a campaign that provides real-world case studies to help inspire girls to pursue a STEM career. I was really happy to be part of this.

// Detect dark theme var iframe = document.getElementById('tweet-1306872114050408448-342'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1306872114050408448&theme=dark" }

For the next year, I am not making any big plans. I am mainly trying to learn as much as I can in my new job, and find a balance in my work and life. If I can share with the community more, and write some blog posts about areas that are important to me, it will make me happy.

Android Accessibility - Resolving common Talkback issues

Sigute — Tue, 31 Mar 2020 07:29:28 +0000

Android Accessibility - Resolving common Talkback issues

Many Android applications suffer from similar Talkback issues and at Microsoft To Do we run into these often as well. We use multiple strategies to make our app more accessible. This article covers a few scenarios where Talkback experience is improved.

A companion Github repository containing the sample code is available here. You can check it out and try running the demo app on your device to experience the issues and try the solutions yourself.

Combining views into groups

Not everything visible on the screen is meaningful; some views are used only for decoration, some images illustrate the text without adding additional information, and sometimes multiple views convey the meaning together but do not make sense separately. In these cases, the views can be combined to allow Talkback user to quickly navigate entire view, rather than having to skip through multiple different elements.

Example

Screenshot showing Talkback navigation over ungrouped elementsTalkback reads the user element on the page as "User placeholder avatar", "Name", and then "Surname". Each element can be navigated individually. The user icon is a placeholder which does not provide additional information. It takes three swipes to navigate through the element.

Solution

Screenshot showing Talkback navigation over groupContent description is set on the entire group so Talkback reads only one label, containing all user information as "Name Surname". Now navigation is done in only one swipe.

XML layout snippet

Content description is set on LinearLayout, child views are marked as not important for accessibility individually.



<LinearLayout …

  android:contentDescription="@string/content_description_user_combined"

  <ImageView …

    android:importantForAccessibility="no"/>

  <TextView …

    android:importantForAccessibility="no" />

  <TextView …

    android:importantForAccessibility="no"/>

</LinearLayout>

Action descriptions

As Talkback navigates the elements with click actions, the announcement generated will include some information, for example "Login, Button, Double tap to activate". However, relying on default announcements is not always enough.

Example

Screenshot showing Talkback announcements for the Button without custom actionsA button with two actions generates an accessibility announcement of "Edit note, Double tap to activate, Double tap and hold to long press".

Solution

Screenshot showing Talkback announcements for the Button with custom actionsActions are modified to announce "Double tap to edit note, Double tap and hold to copy note".

Code snippet

Custom actions are added in accessibility delegate, ensuring that it's clear what happens when each action is carried out.



ViewCompat.setAccessibilityDelegate(set_actions_button, object : AccessibilityDelegateCompat() {

    override fun onInitializeAccessibilityNodeInfo(v: View, info: AccessibilityNodeInfoCompat) {

        super.onInitializeAccessibilityNodeInfo(v, info)

        info.addAction(AccessibilityActionCompat(

            AccessibilityNodeInfoCompat.ACTION_CLICK, "Edit note"))

        info.addAction(AccessibilityActionCompat(

            AccessibilityNodeInfoCompat.ACTION_LONG_CLICK, "Copy note"))

    }

})

Roles

Talkback reads the element roles, such as Button, Switch, Checkbox, etc. This gets complicated when non-standard elements are used. For example, adding a click listener will add an action to Talkback announcement, but the role will generally not change, potentially causing confusion.

Example

Screenshot showing examples of different types of buttons and Talkback announcementsThe button is announced as "Login, Button". Adding on a click listener to TextView does not include the "Button" announcement. In the last example, TextView is announced as "Button".

Code snippet

Role is added by including it in the accessibility delegate. This is not an ideal solution; best practice is to use elements as intended, so using Button when Button behaviour is needed, which avoids the need to modify roles manually, as it is easy to miss some behaviour which comes by default. However, in some cases, this will help.



ViewCompat.setAccessibilityDelegate(login_text_view_as_button_with_role,

    object : AccessibilityDelegateCompat() {

        override fun onInitializeAccessibilityNodeInfo(v: View, info: AccessibilityNodeInfoCompat) {

            super.onInitializeAccessibilityNodeInfo(v, info)

            info.roleDescription = "Button"

        }

})

Updating information after state changes

Lint warning often reminds us about adding initial content descriptions, but for the elements with states, this might not be enough. It is important to remember to update accessibility information as well.

Example

Screenshots showing Talkback announcements for Buttons where UI changes but accessibility information is not updatedThe favorite button is not updated after the user taps on it, so the Talkback announcement still reads "Not favorite item, Button, Double tap to activate" after the user already added the item to favorites and the UI is updated to reflect this.

Solution

Screenshots showing Talkback announcements with changed UI and accessibility informationFavorite button content and action descriptions are updated so Talkback reads one of two states: "Not favorite item, Button, Double tap to add to favorites" and "Favorite item, Button, Double-tap to remove from favorites".

Code snippet

When a tap event is received and the element state changes, the content and action descriptions are updated to reflect the current state of the item. This is especially important for elements which represent On/Off state, like the favorite button. Alternatively, an element which already supports On/Off states could be used in this scenario, like Switch or Checkbox. On the other hand, if more than two states are available, then custom elements make sense.



favorite_button_custom.contentDescription =  if (selected) "Favorite item" else "Not favorite item"

ViewCompat.setAccessibilityDelegate(favorite_button_custom, object : AccessibilityDelegateCompat() {

    override fun onInitializeAccessibilityNodeInfo(v: View, info: AccessibilityNodeInfoCompat) {

        super.onInitializeAccessibilityNodeInfo(v, info)

        info.addAction(AccessibilityNodeInfoCompat.AccessibilityActionCompat(

                AccessibilityNodeInfoCompat.ACTION_CLICK, 

                if (selected) "Remove from favorites" else "Add to favorites"))

    }

})

RecyclerView scrolling

If RecyclerView does not automatically scroll with Talkback navigation, it will make it very hard for Talkback users to know that there are more elements available. There is one common issue which usually causes this.

Example

GIF showing side by side comparison of Talkback navigation of scrolling and non-scrolling RecyclerViewThe first RecyclerView allows user to see the first 5 elements and then navigation skips the rest. The second RecyclerView moves to the 6th element in the list and scrolls down to make additional elements available. The focus only moves away from RecyclerView when all elements are visited.

Layout snippet

If the following line is in the RecyclerView layout, removing it will fix the issue. It will also add additional in/out of list announcements to help the users navigate.



<androidx.recyclerview.widget.RecyclerView …

    android:importantForAccessibility="no"

/>

RecyclerView focus

As is the nature of RecyclerView, it can recycle the view holders if there are changes to the data. However, this can create focus issues if some view is no longer displayed or the view holder is reused in a different position. Understanding what is happening will help with keeping the focus unchanged.

Example

GIF showing side by side Talkback navigation of RecyclerView with focus issues and a fixRecyclerViews allow the user to mark elements as deleted. In the first RecyclerView, once the delete icon is tapped and the element text is replaced with "Deleted name", the focus returns to the top of the activity, so the user needs to navigate through the entire screen again to return to the original focus position. The second RecyclerView keeps the focus on the same element, shifting it from the icon to the name.

Code snippet

After the element is marked as deleted there is a short delay to allow RecyclerView time to reuse ViewHolders, then the desired position is found and focus is returned to that position. If the underlying data set is not changed and there is no refresh of the data in RecyclerView adapter, this could potentially be solved within ViewHolder itself. As always, the best solution is the one which addresses the specific need.



recycler_view.postDelayed({

    val viewHolder = recycler_view.findViewHolderForAdapterPosition(position)

    viewHolder?.itemView?.requestFocus()

}, delay_in_ms)

Conclusions

Accessibility is important for our team at Microsoft To Do. We spend a lot of time making sure every user can stay organised and accomplish more, independent of how they use their device. Most of our Android app releases include several accessibility improvements. We also work with our design team to consider accessibility requirements from the start.

Accessibility issues we encounter range from simple to tricky - it takes time and dedication to find and resolve them all. I hope this article helps you to solve some. Code snippets in the article have been simplified for clarity, so check the sample code for full implementations.

Is there a different way you would approach some of these? Let's discuss it!

This article was first published on Android@Microsoft Medium publication here.

Improving Pull Request Process with Complexity Labels

Sigute — Thu, 12 Mar 2020 18:11:17 +0000

Does your team struggle with pull requests? Is there never enough time in the day to review others code? Do you feel like you need to keep asking your teammates for code reviews? Is the list growing everyday with no end in sight? Pull requests are hard. Our Android team at Microsoft To Do made some changes recently to improve the process. I have suggested adding labels to pull requests and this article shows my solution.

What is complexity

To start with, I thought about how we define complexity. Take a moment to consider these: What makes a pull request easier or harder to review? Is there a type of pull request which always get merged straight away and another one that sits there for a long time? What's the difference between them?

In general, the smaller the pull request, the easier and faster it should be to review. This is a good general rule, however one line change is not always straight forward in terms of impact. Fixing a typo is easy. Updating an external dependency also changes only a few characters, but might lead to the entire app breaking.

However, considering only the number of lines of code changing can be misleading if it is the only way to think about complexity. On the other side of this, large pull requests are not necessarily complex. Renaming something might affect hundreds of files but the risk is low, especially with modern tools where forgetting some files is less likely. Adding in new translations could also generate very large changeset, but is unlikely to generate new bugs.

Complexity Matrix

After considering size and difficulty, I have arrived at complexity as the measure of pull request.

Size x Difficulty = Complexity

I have created this matrix as a way to think about complexity and roughly estimate where pull request might fall into.

Easy - small size and low difficulty

These are your small and simple pull requests. This is the quickest pull request type to review and the easiest to test. Changes are unlikely to cause further issues. These pull requests tend to get merged very quickly.

Medium Low - large size and low difficulty

These are pull requests which are large, but the changes themselves are trivial. They can take longer to review because of the size, but are also less likely to introduce further bugs.

Where possible, it could be beneficial to split these pull requests into multiple smaller ones.

Medium High - small size and hard difficulty

These are pull requests which do not change many lines of code, but could have a big impact. This includes changing business logic, UI elements, updating dependencies, etc. These changes can potentially have unforeseen effects, so need to be reviewed and tested carefully.

This is the category where using strategies like A/B testing, feature flags and and staged releases could be very beneficial, so changes can be reverted easily in case of any issues, whether with code or with user impact (for example if new UI does not perform as well as expected).

Large - large size and hard difficulty

The final category is the pull requests which are large and complex. This could be things like adding a new screen to the app, changing one dependency to another, refactoring, etc. The bigger a pull request grows in this area, the harder it is to keep track of changes and carry out a good code review.

The best strategy here is to be careful about creating pull requests in this category. If the code changes are growing, could they be split across multiple code reviews? For example, for a new app feature, database changes could be reviewed separately from the UI layer. Using feature flags to hide code which is not ready for production yet helps with this, so the feature branch does not grow too much out of sync with the main branch.

How to put this into practise

We have started labelling our pull requests as part of the title and use t-shirt sizes as the complexity:

S -> M -> L -> XL -> ... -> XXXXXXL?

Some examples of pull request titles would look like this:

[S] Fixed accessibility bug in X screen

[M] Updated library Y dependency, please test

Alternative labels could include emojis!

🐇 -> 🦘 -> 🦙 -> 🦖

😀 -> 🙂 -> 😐 -> 😭

Be aware that emojis appear differently on other devices, dependent on platform, OS, and many other factors, so make sure the selected ones look good on all your teammates computers!

If you want to use animal emojis, I have categorised some of them by size!

// Detect dark theme var iframe = document.getElementById('tweet-1234832806544625665-676'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1234832806544625665&theme=dark" }

As well as using the label as part of the title, you could make use of labels in your code review tools.

If you are using Github, you can create custom labels and then add them to pull requests. Emojis and colours are supported and you will be able to filter by specific label.

Impact of changes

It has been a few weeks since our team started adding a complexity label when making new pull requests. In general, the feedback has been great! This approach encourages us to think about how complex the changes are when we add new code to Android Microsoft To Do app.

The benefits of this approach so far include:

Telling at glance how much time it might take to review the changes. This helps to plan which pull requests might need a longer time to review and what can be quickly reviewed in the spare 10 minutes between other tasks.
Thinking about complexity when creating pull requests and strategies to mitigate risk.
The pull request list becomes more manageable.

We did not experience any big issues, but a few things we discovered:

It is hard to get used to any new approach, so remembering to add a label is not automatic yet.
Our release notes made use of pull request titles for the draft version, so we had to add an additional script to strip the labels out as part of our continuous integration process.

As a closing thought, I would encourage you to be forgiving about the labels. They are rough indicators intended to help with the process. If you are getting lost in conversations over whether a pull request is XL or XXL, you are missing the point! 😀

Android Accessibility - Where to start?

Sigute — Tue, 11 Feb 2020 20:11:52 +0000

Making sure as many people as possible can use an app you are developing is so important for many of us. If you are just starting to think about accessibility in your Android app, it can be hard to understand what the requirements are and how to get started. This article will allow you to start exploring common accessibility issues in Android apps; making these small improvements will help many users of your app.

Tools

The main tools used for Android accessibility testing are offered by Google and many come pre-installed on every device. The main ones you need to start with are:

Talkback

Most devices have either Talkback or a similar screen reader already pre-installed. Once enabled, a tutorial is provided so you can learn how to navigate. With Talkback, captions can be enabled in the settings and are helpful to verify the announcements, and if you need to take a screenshot to share with other members of the team this is a useful feature.

Enable Talkback and captions:

Settings -> Accessibility -> Talkback -> Settings -> Developer Settings -> Display speech output

Accessibility Scanner

Accessibility Scanner is a tool made by Google specifically for finding common accessibility issues and is very easy to use. It can be downloaded and installed from the Play store. Once installed, any screen in any app can be scanned for issues.

Contrast checker

After finding issues, sometimes tweaking colours is enough to resolve them. There are many contrast checkers available, I like the WebAIM one as it checks both text and other elements.

5 places to start

My advice is to start with these areas to address the most common issues found in many apps. When we think about accessibility in apps, we often think about vision impairments, including vision loss. Another area to think about is mobility impairments which can make it difficult to use controls and navigation.

Labels and content descriptions

Launch Talkback and start checking what announcements are made as you focus on various views in the app. Some questions to keep in mind while testing:

Do buttons have labels?
Do images have content descriptions?
Do labels match what is actually shown on the screen?
When the element state changes, is the content description updated? (for example, ticked and unticked radio button)
Are there some elements which are only decorative and should not be announced?

Fixing issues in this category is usually straightforward. Content description can be added and updated. Decorative elements can be labelled as not important for accessibility and will be skipped. Android Lint provides some warnings for missing accessibility features, and addressing these will help.

The aforementioned Accessibility Scanner will catch a lot of these issues too.

Navigation

Talkback is the tool to use for this category. Keyboard navigation follows similar paths, so it could be used for testing as well.

As you navigate through the app, does focus jump around or is the order followed logical?
Do you lose focus and need to start at the top of the page again?
Can all areas be accessed without tapping on the screen directly?
Does Talkback focus on each element separately or can some elements be grouped? (for example, user name could be navigated as "Name", "Surname" or as one "Name Surname" element)

Fixing navigation can be challenging, so deciding on the strategy early rather than trying to retrofit the solution later is often the best approach. Some things to look into for this category include the accessibility traversal order, setting content descriptions on groups rather than individual items and requesting focus manually on specific elements in some scenarios.

Font sizes

Changing font to a larger size in device settings will help to check for issues in this area. Display size can be changed as well and should be tested. Things to look for include:

Does all the text in the app respond to device setting font size?
Do any elements overlap each other?
Is any text cut off and cannot be read anymore?

To fix issues in this area, look for any usages of dp instead of sp for text sizing. Make sure elements scale to match the text sizes and prefer scrollable screens which can accommodate additional height if needed. For the individual views, it is best to avoid fixed height and width. Setting the view height and width to wrap_content and using minWidth and minHeight attributes will help with the scaling.

Contrast

Contrast can be checked using Accessibility Scanner and other contrast checker tools. It might be hard to determine contrast ratio just by looking. Some questions you might ask are:

Are any colours very similar to each other?
Can tappable elements be easily distinguished?
Is there a rule for what colours of background and text could be used in the app, to make the contrast ratio more predictable?

General requirement is minimum 4.5:1 contrast ratio of text to background, and 3:1 for controls. Outlines can help to distinguish tappable elements in some cases.

Tap target sizes

If you ever tried tapping a button multiple times without success, you have ran into this issue. Accessibility Scanner will highlight the areas which are too small to tap accurately. Some things to keep in mind include:

Is there enough padding to tappable elements?
Are there a lot of small elements right next to each other, so it's easy to mis-tap?
Can the entire element be tapped or is the tap area limited to a small portion of it?
Can the tap area be expanded?

Android recommendation is a minimum 48x48dp for tappable areas. Some margins between elements, where possible, can also make for a nicer experience.

Watch out for…

Custom views

If you define your own custom views, be careful. Default Android framework elements come with a lot of built-in accessibility support. Where possible, extending the framework class, like Button, might help to reduce some work vs extending a more generic class, such as FrameLayout, and having to build various states and announcements from scratch.

Continue with…

Checking for these common issues will help to improve accessibility in your app. However, there are more things to consider to provide a great experience for users with accessibility needs. WCAG guidelines are a great place to go for understanding additional requirements and exploring common solutions.

This article was first published on Android@Microsoft Medium publication here.