As Android developers, we’re look for ways to streamline our workflow and increase productivity. While we were not constantly always aware of every new tool or shortcut. Minding this I'm here to share some shortcuts I've recently learned from an online presenting in my workplace, and others that I already knew.

Integrating tools like Github Copilot into Android Studio can significantly speed up coding. However, certain situations can reduce this efficiency or be frustrating. This article will walk you through some essential commands.

The Shortcuts

Here are the keyboard shortcuts you need to know to take control of Github Copilot in Android Studio:

Accept an inline suggestion

Let's begin with the basic shortcut for quickly accepting a full, completed suggestion from Copilot.

Mac & Windows: Tab

Accept next word of an inline suggestion

Next one I've recently found, sometimes I don't want to accept the whole suggestion, just the first words and adapt the rest. When Copilot suggests multiple words, using this shortcut you're able to accept only the next word at time, giving you more control over the final code.

Mac: Command + →

Windows: Ctrl + →

Show next and previus inline suggestion

Sometimes Copilot offers multiple suggestions. Use this shortcut to cycle through them until you find the one that best fits your needs.

Mac: Option (⌥) + ] (next suggestion) and Option (⌥) + [ (previous suggestion)

Windows: Alt + ] (next suggestion) and Alt + [ (previous suggestion)

Trigger inline suggestion

Sometimes Copilot doesn't provide a suggestion, but you want to explicitly ask for one. This shortcut manually triggers the suggestion, even if you haven’t started typing.

Mac: Option (⌥) + \

Windows: Alt + \

Dismiss an inline suggestion

The last one is simple but really helpful, because suggestions can be annoying, specially if Copilot is giving all wrong suggestions and you want do develop your own code. This command quickly gets it out of your way .

Mac & Windows: Esc

Conclusion

Mastering these shortcuts will allow you to navigate through Copilot’s suggestions effortlessly, making it a seamless extension of your development process.

If Compose and Accessibility are interesting themes to you, take a look at the following articles:

• Text Scaling for a Better User Experience in Jetpack Compose
• 4 Common TalkBack Issues in Android Compose
• Accessible Contrast in Apps with Jetpack Compose

While studying accessibility in Jetpack Compose, I encountered some issues while making my app more supportive of Talkback. In this article, we'll explore strategies to improve accessibilty in your app.

This article does not cover all possible scenarios and assume you already have a basic understanding of Talkback.

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

1. Grouping composables

Often, the system automatically merges certain composables, such as the contents of a list item or any clickable container, treating them as a single element for accessibility purposes. However, there are cases where we need to manually merge composables to improve selection behavior and make navigation smoother for TalkBack users.

Example

The examples above show the difference between merged and unmerged composables. Proper grouping improves the listening experience and enhances the app’s overall accessibility.

In this example, all Text elements are wrapped in a parent composable. To merge them into a single accessibility node, we use the mergeDescendants property in the parent’s Modifier. You can see this on line 12. Now, when selected, the elements are read as a single unit instead of individually.

2. Making TextFields More Informative

This is more of an accessibility best practice than a direct issue. When using TextField, always provide a label because TalkBack will read your label when the user touches the input field.

However, in forms with multiple TextFields, each field serves a different purpose, requiring users to enter specific data. While the title above the field helps, it’s far more informative if users can instantly identify the field they are interacting with through TalkBack.

A great way to enhance accessibility is by setting a contentDescription for the label, not the TextField itself. If you apply the contentDescription directly to the TextField, TalkBack will read both the label and the description, creating redundancy.

Example

1. Define a contentDescription (line 4) — Instead of just saying “Type here”, TalkBack will read “Enter your first name”, making it more meaningful.
2. Add the semantics in the label (line 25–27) — We use semantics {} to define the new description.

3. Update state changes

Sometimes, simply adding a contentDescription isn't enough. If your elements have a state, it's important to ensure that TalkBack users can understand which state they are in.

Example

In the image above, the favorite button changes when selected, but TalkBack users won’t know whether it’s currently selected or unselected — they will only hear “Favorite. Button”, without any indication of state.

Solution

To fix this, we need to explicitly communicate the state to TalkBack. Instead of using IconButton, we should use IconToggleButton, which automatically provides the state (checked or not checked) to accessibility services.

4. Custom Actions

In many apps, a single component may have multiple actions. For example, a list item could have a favorite button, swipe to delete and/or archive and potentially even more actions.

Problem

When TalkBack is enabled, execute all this actions can be difficult. Adding them through custom touch gestures isn’t always effective, and if you include all actions in the TalkBack description, it becomes too long and confusing.

Solution

To improve accessibility, TalkBack provides a built-in menu where you can define Custom Actions. Instead of overloading the user with long descriptions, these actions appear in the TalkBack Actions Menu, making them easier to access.

How This Works:

1. Define the action label (Line 4–8) — The label changes dynamically depending on whether the item is favorited or not.
2. Add a semantics modifier (Line 16–27) — We use customActions inside semantics {} to define the custom TalkBack action.
3. Clear semantics from the favorite button (Line 33) – Since we want the action only in the TalkBack menu, we use .clearAndSetSemantics().

Conclusion

Improving accessibility in Jetpack Compose is not just about adding contentDescription to UI elements—it’s about ensuring that all users, including those relying on TalkBack, have a smooth and intuitive experience.

Accessibility isn't just an optional feature—it’s a fundamental part of building high-quality apps. Start small, test with TalkBack, and keep refining your app’s accessibility to ensure everyone can use it with ease.

If you found this guide helpful, share it with other developers and let me know in the comments if you’ve encountered other accessibility challenges in Jetpack Compose!

Connect with me on LinkedIn!

If you liked this article, Clap it to reach more people.

References

• Accessibility in Compose | Jetpack Compose | Android Developers
• Android Accessibility — Resolving common Talkback issues

What is color contrast?

According to Google, a “contrast ratio” is a measure of the difference in luminance — or intensity of light emitted — between two adjacent colors displayed on a screen. This ratio ranges from 1 to 21 (often written as 1:1 to 21:1), with higher numbers indicating greater contrast.

The Web Content Accessibility Guidelines (WCAG) recommend the following minimum and enhanced contrast ratios:

According to Google, “contrast ratio” is a computation of the difference in luminance, or intensity of light emitted, between two neighboring colors when shown on a display. This ratio ranges from 1 to 21 (often written as 1:1 to 21:1), where increasing numbers mean higher contrast.

The Web Content Accessibility Guidelines (WCAG) recommend the following minimum and enhanced contrast ratios:

Minimum Contrast (WCAG Level AA):

• At least 4.5:1 for small text (below 18 point regular or 14 point bold)
• At least 3.0:1 for large text (18 point and above regular or 14 point and above bold)

Enhanced Contrast (WCAG Level AAA):

• 7.1:1 for small text (below 18 point regular or 14 point bold)
• 4.5:1 for large text (18 point and above regular or 14 point and above bold)

Who Benefits from Proper Color Contrast?

People with color-vision deficiency, commonly referred to as “color blindness”, is the inability to distinguish certain shades of color. Around 12% of men and a smaller percentage of women have some form of color vision deficiency.

Approximately 4% of the population has low vision, whereas 0.6% are blind. Low-vision conditions that increase with age, because age-related eye diseases, such as age-related macular degeneration , glaucoma and diabetic retinopathy , most often cause it. At the age of 45, less than 1%of people are likely to have low vision, but by the age of 75, that jumps to almost 5%, and then to 15% by the age of 85.

Let's see some examples

Above are some color contrast examples. To exemplify the theme I'll use a screen of my recipe app, I’ve exaggerated the contrasts to highlight the issue:

Above we can see the same screen with different contrast the first one is the level AAA, the second is the level AA and the last is with low contrast. Just these images exemplify the point of this article.

Below I get the same image and applied a filter to simulate lowered vision in aged people.

The eye problems with contrast are huge, but I focused in the common one, the aged degeneration of the vision. The intension here is try to give a visual parameter to help you to imagine yourself in these situations.

How to test

Jetpack Compose provides an easy way to test the accessibility of your screens using the Compose UI Check feature in the screen preview. The UI Check automatically audits your Compose UI for accessibility issues. Android Studio flags issues such as stretched text on large screens or low color contrast in the Problems panel.

Jetpack Compose provides an easy way to test the accessibility of your screens using the Compose UI Check in your screen preview. The UI Check automatically audits your Compose UI for accessibility issues. Android Studio checks that your UI works across different screen sizes by highlighting issues such as text stretched on large screens or low color contrast in the problems panel.

How to improve your contrast

If your UI fails the contrast check or if you’re prototyping and unsure about color combinations, tools like Adobe Color can help. On their website, you can input your text and background colors to:

• Determine the contrast ratio.
• Check if the colors pass or fail accessibility standards.
• Get suggestions for better color combinations to improve contrast.

Final Thoughts

Designing with accessibility in mind ensures your app is usable by a broader audience, including those with visual impairments. Test your UI, adjust your colors, and make your app inclusive for everyone.

Leave a comment, give a like and connect with me on LinkedIn!

If you liked this article, Clap it to reach more people.

References

• Color Contrast And Why You Should Rethink It - Smashing Magazine
• Accessibility Is So Much More Than Contrast

https://color.adobe.com/pt/create/color-contrast-analyzer

While studying responsive design with Jetpack Compose, I came across a new feature recommended by Google to assist in designing, developing, and testing adaptable layouts: Window Size Classes. This feature, detailed in the Android Documentation, helps organize layout elements across different screen sizes for a more consistent and accessible UI. Here’s how Android describes it:

Window size classes categorize the display area available to your app as compact, medium, or expanded. Available width and height are classified separately, so at any point in time, your app has two window size classes — one for width, one for height. Available width is usually more important than available height due to the ubiquity of vertical scrolling, so the width window size class is likely more relevant to your app’s UI.

Explaining the problem

When trying to preview composables with Window Size Classes, I faced an issue: every preview was treated as a compact screen, regardless of its width or height setting. Here’s an example:

import androidx.compose.foundation.background
import androidx.compose.foundation.layout.Box
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.material3.adaptive.currentWindowAdaptiveInfo
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.tooling.preview.PreviewScreenSizes
import androidx.window.core.layout.WindowHeightSizeClass
import androidx.window.core.layout.WindowSizeClass

@Composable
fun BackgroundExample(windowSizeClass: WindowSizeClass = currentWindowAdaptiveInfo().windowSizeClass) {
    val backgroundColor =
        when (windowSizeClass.windowHeightSizeClass) {
            WindowHeightSizeClass.COMPACT -> Color.Red
            WindowHeightSizeClass.MEDIUM -> Color.Green
            else -> Color.Blue
        }

    Box(modifier = Modifier
        .fillMaxSize()
        .background(backgroundColor)
    )
}

@Composable
@PreviewScreenSizes
fun PreviewExample() {
    BackgroundExample()
}

Despite @PreviewScreenSizesspecify different screen sizes — Desktop, Phone, Landscape Phone, Tablet, and Foldable — the Window Size Classes still registered everything as compact. This bug means you can’t test accurately across screen types.

To address this issue, I found out a workaround. However, before implementing it, be sure to test without this solution, as Android may have resolved this bug in newer versions. If the issue persists, here’s the fix.

Exploring Solution

@Composable
fun BackgroundExample(windowSizeClass: WindowSizeClass = currentWindowAdaptiveInfo().windowSizeClass) {
    ...
}

@Composable
@PreviewScreenSizes
fun PreviewExample() {
    val configuration = LocalConfiguration.current
    val windowSizeClass = WindowSizeClass.compute(
        dpHeight = configuration.screenHeightDp.toFloat(),
        dpWidth = configuration.screenWidthDp.toFloat(),
    )

    BackgroundExample(windowSizeClass)
}

This approach uses LocalConfiguration to fetch the screen's width and height, which are then used to compute the WindowSizeClass. By directly passing these parameters, you can test how your composables behave across various screen types and improve responsiveness.

Leave a comment, give a like and connect with me on LinkedIn.

If you liked this article, Clap it to reach more people.

Font scale accessibility in mobile phones allows users to adjust the size of text displayed on their screens, making it easier for them to read content comfortably, regardless of their vision abilities. This feature is especially important for those with visual impairments, older adults, or anyone who prefers a larger text size for better readability.

In fact, a survey was made in the Netherlands revealed that almost half of mobile phone users take advantage of accessibility features, with 24% of iOS and Android users opting to increase their font size.

In this article, I’ll walk you through some of the common challenges developers face when it comes to text scaling. But before diving into those issues, let’s see how to preview text scale in your code.

How to preview

In Jetpack Compose, you can do this easily by using the @PreviewFontScale annotation, available with the androidx.compose.ui:ui-tooling-preview-android library version 1.7.4 or newer.

@PreviewFontScale
@Composable
fun ScalableTextPreview() {
    ...
}

Alternatively, you can directly adjust the fontScale parameter within the @Previewannotation.

@Preview(fontScale = 0.85f, name = "Scale 85%", group = "Font Scaling")
@Preview(fontScale = 1f, name = "Scale 100%", group = "Font Scaling")
@Preview(fontScale = 1.15f, name = "Scale 115%", group = "Font Scaling")
@Preview(fontScale = 1.3f, name = "Scale 130%", group = "Font Scaling")
@Preview(fontScale = 1.5f, name = "Scale 150%", group = "Font Scaling")
@Preview(fontScale = 1.8f, name = "Scale 180%", group = "Font Scaling")
@Preview(fontScale = 2f, name = "Scale 200%", group = "Font Scaling")
fun ScalableTextPreview() {
    ...
}

Problem 1: Text Overflow or Clipping

One of the most common issues when dealing with font scaling is text overflow or clipping, which can degrade the user experience. Let’s look at an example in Jetpack Compose:

What’s wrong?

In this example, the Box has a fixed width of 100.dp and a height of 50.dp, while the Text component inside it contains a long string that overflow beyond the boundaries of the Box, leading to clipping and making the content unreadable.

Solution:

Here, we make adjustments to handle text scaling properly by removing Modifier.height and allowing the Box to resize dynamically.

Problem 2: Hidden Content in Grid View

When building a grid layout, it’s common to use fixed sizes to achieve a perfect form, often inspired by a particular design. While this can work well with some font scales, it may fail with others, leading to hidden content. This is especially problematic in Grid Views that display important information or provide access to essential features. Let’s look at an example:

What’s wrong?

In this example, the fixed size of 120.dp for each grid tile works well when the font size is at 100% scale, but as the user increases the font size, content may get cut off or overlap, making some text unreadable. This can lead to a poor user experience, especially if the grid is meant to display critical information like emergency contacts.

Solution: Using Modifier.sizeIn()

To keep the square format of the grid tiles in 100% scale while ensuring that text remains readable, we can use Modifier.sizeIn(). This property is useful to constrain the width of the content to be between minWidth dp and maxWidth dp and the height of the content to be between minHeight dp and maxHeight dp, constraining it to a minimum width and height while adapting when the text needs more space.

By specifying just minWidth and minHeight, we maintain the tile's shape at standard scales, and when the text grows larger, the Surface adjusts automatically, preventing clipping. Here’s the adjusted code:

Problem 3: Secondary Texts Taking Up Much Space

The third common problem when handling font scaling is not text overlapping but rather text taking up more space than intended. In this case, the text adapts correctly to larger font sizes, but secondary texts, such as subtitles, can start consuming a lot of screen space — especially in list views. Since these texts are not primary content, it’s often better to limit how much of them is displayed. Let’s look at an example of this issue:

What’s wrong?

In this example, everything looks fine when the system font scale is at 100%, but as soon as it increases to 150%, the subtitle text starts to take up more space, making each list item much larger than it needs to be. This can result in a cluttered and inefficient use of screen space.

Solution: Using Modifier.heightIn

To address this issue, we can use Modifier.heightIn() to set a maximum height for each list item, ensuring that even with larger text sizes, the list item doesn't expand excessively. This works similarly to Modifier.sizeIn(), but focuses only on height:

By defining a maximum height, we prevent the list item from growing too large. However, this alone can lead to text being clipped if it exceeds the space available.

Adding maxLines and TextOverflow.Ellipsis

To ensure that text remains readable without overlapping or clipping, we can use the maxLines property along with TextOverflow.Ellipsis for the Text component. This allows us to limit the number of displayed lines and automatically add an ellipsis (...) if the text is too long. Here’s the complete solution:

This approach is especially useful when dealing with dynamic text, where the length of the content is unpredictable. By limiting the number of lines and applying an ellipsis, you can ensure a consistent and user-friendly design, even when the text size of the list items varies.

Conclusion

Building accessible and responsive mobile apps requires careful attention to how text scales across different devices and user settings. While a 200% font scale might not always preserve the original design aesthetics, what truly matters is maintaining the usability and readability of the interface.

The inspiration for this post came from a LinkedIn story where a daughter noticed her father struggling to use a banking app with an interface that had become nearly impossible to understand due to larger font settings. You might think such situations are rare, but I’ve taken two of the situations in a banking app from one of the largest private banks in Brazil, a bank with over 2 trillion in assets. Despite its resources, the app’s interface became completely broken when the font size was increased.

So, here’s a challenge for you: grab your parents’ phone, set the font size to its maximum in the settings, and see if they can still navigate and use their apps effectively. It’s a simple test that can reveal a lot about the real-world accessibility of our designs. Making these adjustments might seem small, but they can significantly improve the experience for users who rely on these features every day.

Connect with me on LinkedIn
If you liked this article, Clap it to reach more people.

Bianca Correia on LinkedIn: Vocês já se colocaram no lugar de uma pessoa idosa? Esse é o print de um... | 239 comments