Forem: Eevis

About Invisibility, Propaganda, and Assumptions of Incompetence

Eevis — Sat, 07 Mar 2026 09:17:39 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

It’s the time of the year when I feel most conflicted. Tomorrow’s International Women’s Day, and as I’ve witnessed in the past years, it’s usually the time when men start asking about when International Men’s Day is, and telling how equality has gone too far. Of course, not all men, but usually a man.

In Finland, we also have Minna Canth’s day and the day of equality on the 19th of March, and in the days between these dates, all kinds of weird anti-equality stuff and trolls pop up. As someone who cares deeply about equality and human rights, this time is a bit stressful.

By the way, Minna Canth was a Finnish writer, businesswoman, and social influencer, best known for her work on women’s rights. If you’re interested in knowing more about her, here’s a link to Wikipedia: Minna Canth.

Anyway, I also enjoy this time of year a lot. Especially Dev’s We Coded has a special place in my heart - reading posts from other people who are from underrepresented genders in tech, and seeing how the community comes together to defend those who get some nasty or uncalled-for comments to their posts.

This is my sixth time participating in We Coded, and over the years, I’ve shared my experiences as a nonbinary woman in tech. I’ve also shared some tips for allies, but last year, I decided to just share my experiences because so many people keep telling me there are no problems and that tech is equal for all, so I’m using my efforts to show otherwise. And I’m going to continue it this year as well, with a couple of tips included.

Naturally, these examples are not everything I’ve witnessed and experienced since March 2025, but some selected examples. Let’s start with some invisibleness.

Non-Binary Woman, an Invisible Creature

This has been the first year I’ve fully embraced myself as a non-binary person. I’m still figuring out the details, so I’ve been introducing myself as a non-binary woman because I still feel a connection to womanhood. I’ve lived as a woman for most of my life, but at the same time, deep down, I’ve known that I’m not a woman. Or, just a woman.

Anyway, one of the things I’ve started doing is referring to myself with “they” pronoun. Generally, I go by they/she, because I’ve decided not to use too much energy correcting people, so “she” is okay for me for now. But when I refer to myself, like in a bio or something that requires third person, I use “they”.

I was filling out a CV for a freelancer agency last spring. The person from the agency asked me to fill out the CV details, and they would edit it to make it more selling. I was ok with that. I’m not the best at coming up with hype words to sell my experience.

I wrote my bio using “they”. A bit later, I wanted to check something in the edited CV, so I opened the file and noticed the bio had been updated. Yes, there were some sentences that were better to sell my experience. But they had also changed the “they” pronouns to “she”.

I felt so freaking invisible.

I mean, it’s one thing when someone makes assumptions about me. I can understand that. But editing my own words, that hurts. And yes, they probably didn’t mean it. Heck, they probably didn’t even notice what they were doing.

So, a tip: Respect the pronouns someone asks you to use, and especially the pronouns they use of themselves. If someone writes their bio with some pronouns, they know what they’re doing. There is a reason for that.

What if Your Existence is Propaganda

Last year, I gave many talks about creative coding with Kotlin. The talks contained some live coding, and here’s a video of what I ended up building on stage:

Isn’t the ghost cute? If you’re interested in hearing the whole story, I’ve given this talk, for example, in Droidcon London (it was two weeks after the talk I’m sharing about): Creative Coding in Kotlin - talk.

Anyway, in the talk, the main idea behind the animation I created was that people are generally happier when they can be themselves. And that it’s partly based on my own story. I shared these things from the stage, as well.

At least two people who sat through it all and decided to give feedback via an anonymous channel, to which there was a QR code at the very end of the talk. So, I repeat, they sat through the entire talk, listening, and then gave some feedback. One was just numeric, but the other also gave some written feedback:

I saw this some time after the talk, still at the venue. I’m so glad I had other speakers around me who called the organizer in. They took it seriously as a Code of Conduct violation. Of course, this was an anonymous channel, so it wasn’t possible to reach out to the individual, but they addressed it in public.

Oh, by the way, the London talk went well. I gave a content warning (shouldn’t have to), and one person left the room, so no one got traumatized from my non-binary propaganda (/s).

Another tip: Anonymous feedback might sound like a great way to gather feedback for your speakers, but it really needs some moderation. After this incident, I would rather not take it, even if I risk missing some valuable feedback.

The Bad Ol’ Arguments

The year wouldn’t be complete without some ancient arguments. You know, those that the 1990´s want back. Like “I’ve never seen anyone discriminated”, coming from someone in a very privileged position.

To my surprise, my last year’s We Coded post didn't get many negative comments. This time, no one told me that the sole reason for my being in tech is that I’m just looking for a romantic partner, or that I’d get a promotion only if someone had “other motives” towards me. Or that I was showing my sexuality down everyone’s throats (when I was telling about my experiences, not touching the topic of sexuality, not one time).

However, there was one conversation in the comments where the commenter asked:

Should we lower our standards in the name of equality? Hire incompetent people because we need to check boxes?

And I just pointed out that it’s interesting that there’s an assumption of other genders being incompetent. Of course, there was another commenter telling me that no, that was not the case, and explaining to me “many employers” have hired less competent people in the name of equality, and when I asked if it was the person’s gut feeling, or if there was actual evidence of this happening, they never responded. So, I’m guessing it was the gut feeling.

I’m just so tired of this argument. Yes, before, even mediocre men got hired, but now that hiring standards are changing and competent people from other genders are being hired, it might feel ok to say they’re not competent because they threaten your place. And it might feel intimidating if you’re in the bracket that won’t get hired because there are other people who are more competent than you, who would not have been hired before because of the biases that exist. It might feel unfair, even. But you know, isn’t the idea that the most competent people get hired, regardless of their gender?

Wrapping Up

Okay, time to wrap up this year’s post before it turns into a novel. These were some experiences from a year as a non-binary woman in tech, who is sick and tired of the inequality we still face. The current world situation doesn’t help, and we need to be even more visible now that there’s a joint effort by people with far-right views, anti-gender movement, and those who use Christianity as an excuse, who are trying to erase us.

Of course, at the same time, it’s not always safe to be visible. And it’s important to take care of yourself and your loved ones. So, if you can, shine your light and be visible. I’m trying to do it for myself, and for those, who can’t.

If you’re someone from a gender minority in tech: I see you, and I celebrate you. You are enough, and you are skilled. When you’re doubting yourself, remember: You’ve come this far, and you’ve got this. And that it’s ok to rest as well, you don’t have to always fight.

Adding Navigation support to Large Content Viewer with Compose

Eevis — Sat, 28 Feb 2026 12:36:00 +0000

In my previous blog post, Beyond Font Scaling: Large Content Viewer with Compose, I explained how to build a large content viewer from iOS using Jetpack Compose. The implementation did not include support for keyboard or other assistive tech navigation, so this blog post tackles those topics.

A disclaimer: The way I'm presenting the support for assistive tech navigation in this blog post is one approach, and my goal is to provide examples and context, but as always, this is a demo project. In your production app, things might get a bit more complicated, and you might need to handle more variables. So always remember to test the solution, ideally with your users who use assistive technologies. And I hope it goes without saying: Before releasing to production.

In this blog post, I’m presenting code for keyboard and screen reader navigation, then sharing some considerations for voice access support. The code relies heavily on the code presented in the previous blog post, so if you have questions about it, please check that post. A link for the full code is also provided at the end of the blog post.

Keyboard Navigation Support

The pointer input implementation presented in the previous blog post relies on long-press, but keyboard navigation doesn’t support that kind of interaction, so we need another tactic to display the item preview. With a keyboard, focusing on an item is a natural choice, so we’re going to use that.

The idea is that when a user who navigates with a keyboard or a keyboard-emulating device focuses on a bottom bar item for the same duration as a long press, we will show the item preview. We can do this with the following code:


NavigationBarItem(
    modifier = Modifier
        .onFocusChanged {
            if (it.isFocused) {
                scope.launch {
                    delay(
                        viewConfiguration.longPressTimeoutMillis
                    )
                    previewedItem = item
                }
            } else {
                previewedItem = null
            }
        },

    ...

}

We use the onFocusChanged-modifier. Its state indicates whether the current element is focused via it.isFocused. If it is, we launch the coroutine scope, delay for the same amount of time as with long-press interaction, and then set previewedItem to the currently focused item. If the element is not focused, meaning the focus leaves the navigation bar item, we set the previewedItem to null.

Now, when the user navigates with a keyboard and stays focused for the long-press time, we show the item preview:

Alright, we now have keyboard navigation support. Let’s talk about screen reader navigation next.

Screen Reader Navigation Support

You might ask, “Why are we implementing something like this for screen reader users, as they can’t see?” The thing is, not every screen reader user is blind, and even blindness is a spectrum. So, some screen reader users might still benefit from seeing the icon preview.

Okay, back to the code. For screen reader navigation, we’re going to go with custom accessibility actions. The code could look like this:


NavigationBarItem(
    modifier = Modifier
        ...
        .semantics {
            customActions = listOf(
                CustomAccessibilityAction(
                    label = "Preview item",
                    action = {
                        scope.launch {
                            previewedItem = item
                        }
                        true
                    }
                )
            )
        },

    ...

}

We add a custom accessibility action via semantics and set its label to “Preview item”. In the action block, we set the previewed item as the current item. Then we return true from the action to indicate that it was successfully handled.

You might ask, why don’t we use the long-press duration here? Well, if the user has already gone through all the trouble to trigger the accessibility action, they know what they’re doing and want to see the preview, so no point in making them wait. In touch and keyboard navigation, we don’t show it right away, as it might not be the desired behavior.

After these changes, the navigation could look like the following. The video doesn’t have sound, but you can see the TalkBack input at the bottom of the screen.

Considerations for Voice Access

One assistive technology available to users is Voice Access, which allows users to navigate with voice commands. For users who use it with the item preview, we actually don’t need anything new - everything’s already in place.

One of the commands available for Voice Access is to long-press an interactive element, and as this implementation already supports it (check the previous blog post), we don’t need to do anything to support it.

Wrapping Up

In this blog post, we’ve continued with the icon preview, making it more accessible for assistive technology users. We first looked into improving keyboard navigation, then screen reader access, and finally Voice Access.

There’s one consideration for the overall discoverability of the item previewer: it isn't a common pattern on Android, so you might want to consider how to let your users know about this cool new feature.

The complete code is available as a Github Gist.

Links in the Blog Post

Beyond Font Scaling: Large Content Viewer with Compose

Eevis — Sat, 17 Jan 2026 11:34:00 +0000

If you’ve worked with accessibility issues and have a bottom bar with multiple items, you’ve probably come across a problem with larger font sizes, where it’s impossible to scale the bottom navigation bar texts properly with larger font sizes. You might have wondered whether there are any alternative ways to support larger font sizes beyond just, well, font scaling.

That’s what happened to me. There was a bottom bar with five items with long texts. The developer who implemented the bottom bar had restricted font scaling because larger font sizes made the bottom bar’s items essentially unreadable. I started investigating options and came across one solution: a large content viewer from iOS. As Compose doesn’t support this out of the box, I had to build it.

This blog post explains what a Large Content Viewer is and how to build similar functionality with Compose. I call it the item previewer in this blog post. But before diving into that, let’s discuss the large content viewer on iOS.

Large Content Viewer on iOS

Large content viewer is an accessibility tool for iOS that helps, for example, low-vision users display non-scaling elements, such as bottom-bar items, as previews with a larger font size. It’s enabled only when the Large text (an accessibility setting) is enabled.

Here’s an example of what it looks like on the Files app:

Accessibility Considerations

There are accessibility considerations for this solution. First of all, yes, it can be WCAG-compliant. WCAG, which stands for Web Content Accessibility Guidelines, is the standard used, for example, in legislation. It applies to mobile apps as well. It states in success criteria 1.1.4 Resize text that

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

If the mechanism is not the default font size setting, then another supported mechanism would suffice to pass the success criteria. With this solution, users can resize text without assistive technology up to 200 percent.

However, this solution isn't very discoverable because it’s not a standard way to display fixed-size text. Also, the solution I’m presenting in this blog post is only for pointer-based interaction, as it relies on the long-press action. I will later write a blog post on how to support this for different assistive technologies.

Now that these considerations have been discussed, let’s talk about the actual implementation.

Building Navigation Bar Item Preview

I’ve built a small example to demonstrate how to build the item previewer for Compose. It consists of a Scaffold with a bottom bar, and fixed font size for the bottom bar’s text labels. You can find the full code on GitHub Gist.

The example looks like this with font size set to 200%:

When the user long-presses a navigation item, it is displayed at the top of the screen. Once they release the long press, the tab changes. Also, if they just tap the item, nothing is shown.

There are three things we need to implement to match the large content viewer behavior:

Detect when the user long-presses instead of tapping.
Show the preview of the selected item.
Enable the preview only when the font size is bigger than the default.

Let’s start from the top.

Detect the Long Press

To detect a long press, we’re going to use InteractionSource. There are other options out there, but they don’t work in our case. As we’re using Material 3’s NavigationBarItem, it doesn’t allow long clicks by default, and using combinedClickable modifier doesn’t work, and neither does the pointerInput with detectLongPress because of the order of modifiers in the internal NavigationBarItem component. With that, I mean that the modifier chain inside the NavigationBarItem first includes the user-defined modifiers, and after them, the selectable modifier, which overrides the behavior of those aforementioned modifiers.

One thing to note is that the previewed item is stored as a state variable. NavItem is a custom-defined data class.

var previewedItem by remember { mutableStateOf<NavItem?>(null) }

Back to InteractionSource. Luckily, we can use it with NavigationBarItem, and utilize its methods to detect long presses. Let’s define an interaction source for each navbar item inside the map:


items.map { item ->
    val interactionSource = remember { MutableInteractionSource() }
    ...
}

We also need to know the duration of a long press. We can get it from LocalViewConfiguration:


val viewConfiguration = LocalViewConfiguration.current

// Long press duration

viewConfiguration.longPressTimeoutMillis

Next, we need to collect the interactions, specifically those of type PressInteraction. We do it inside LaunchedEffect:


LaunchedEffect(interactionSource) {
    interactionSource.interactions.collectLatest { interaction ->
        when (interaction) {
            is PressInteraction.Press -> {
                delay(viewConfiguration.longPressTimeoutMillis)
                    previewedItem = item
                }
                is PressInteraction.Cancel -> {
                    previewedItem = null
                }
                is PressInteraction.Release -> {
                    selectedItem = item
                    previewedItem = null
                }
            }
        }
    }
}

So, we listen to changes in interactionSource, and collect the interactions. When the interaction is a press-interaction, we first delay the amount of viewConfiguration.longPressTimeoutMillis to only set the previewed item when the user has held the press for a long enough time for it to count as a long press.

If the interaction is cancelled, for example, if the user moves their pointer input out of the bottom bar item without actually releasing it (and it would otherwise count as a long press or click), we set the previewedItem to null. And if the user releases the press (so, doesn’t cancel it but either lifts their finger or otherwise releases the pointer input), then it counts as either a press or a long press. We set the selected item to the current item, and previewedItem to null. This way, the click works as it should, and if the interaction is counted as a long click, the tab changes and the preview disappears.

Display the Preview

Next, we want to display the item the user is previewing. We first define the preview component:


@Composable
private fun PreviewItem(
    item: NavItem,
    modifier: Modifier = Modifier
) {
    Column(
        modifier = modifier
            .clip(
                RoundedCornerShape(8.dp)
            )
            .background(NavigationBarDefaults.containerColor)
            .padding(16.dp),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Icon(
            painter = painterResource(item.selectedIcon),
            contentDescription = null,
        )
        Text(
            text = item.label
        )
    }
}

It displays the selected item’s icon and the text without preventing text scaling.

Then, in the parent component, but outside of the bottom bar code, we display the PreviewItem component, if the previewItem is not null:


previewedItem?.let { item ->
    Box(modifier = Modifier.fillMaxSize()) {
        PreviewItem(
            modifier = Modifier
                .align(Alignment.Center),
            item = item
        )       
    }
}

The Box is a wrapper that centers the preview the same way the large content viewer does with its preview item. We pass in a modifier to align the PreviewItem to the center of the Box.

Enabling the Preview

The final step is to enable the item preview only when the font size is bigger than the fixed text size. One way is to utilize the font scale and enable the preview when the font size is bigger than 100%:


val fontScale = LocalDensity.current.fontScale
val previewEnabled by remember(fontScale) {
    mutableStateOf(fontScale > 1f)
}

And finally, wrap the item preview with this boolean:


if (previewEnabled) {
    previewedItem?.let { item ->
        ...
    }
}

And that’s how we’ve created behaviour similar to iOS’s large content viewer with Jetpack Compose. You can find The full code on GitHub Gist.

Links in the Blog Post

Year in Review - 2025 Edition

Eevis — Wed, 31 Dec 2025 11:34:00 +0000

It’s that time of the year again! Looking back, I’m so glad I started writing these yearly reflections back in 2021. Now that this is the fifth yearly reflection, it’s great to read those previous ones, and see what has changed - and what has not.

If you want to read about my previous yearly reflections, here they are:

Let’s see what 2025 was about.

Accomplishments

Looking back at 2025, the biggest accomplishment I want to share is that, in the spring, after being on burnout sickness leave for a month, I gave my two weeks' notice at my old job. At that point, I had no plan; I just knew I needed to get out. After that, things came together quickly, and two weeks after my last day at Oura, I started my own company, helping with mobile app accessibility. If your organization needs workshops, coaching, coding, or other mobile app accessibility-related services, send me a message and let’s talk!

Another thing I’m super proud and happy about is that in December, I sent the first issue of Inclusive Android Apps -newsletter. I’ve been contemplating starting a newsletter for a while, and in November, I finally decided to give it a go. I already have some upcoming issues scheduled, and I can’t wait to send them out! You can subscribe to it behind the link: Inclusive Android Apps.

On the coding front, I’ve learned a ton this year. One big theme has been Wear OS-apps, and I published my first Wear OS-application in August. It’s a simple stitch counter for knitting, and building it taught me a lot. I wish I had some time to continue developing it at some point, but so far my fall has been busier than I expected.

The final accomplishment I want to share is that I was asked to serve as a judge for Grand One, a Finnish award for digital agencies and marketing. The category I’m judging for is the most accessible digital service, and it was an honor to be asked.

Speaking

In 2025, I gave talks at both meetups and conferences and participated in a couple of roundtables. Here’s the full list:

Conference talks
- Future Frontend
- Droidcon Berlin
- DevFest Czech
- Droidcon London
Roundtables
- GDE Summit
- Droidcon Berlin
Meetups
- GDG Helsinki: Mobile Tech Spotlight
- Aurajoki Overflow

In addition, I’ve given a couple of internal talks at the companies I’ve worked at this year. This year's topics included accessibility, Android, and creative coding with Kotlin.

From a numbers point of view, my 2025 speaker year was pretty close to 2024, just with roundtables in addition to talks. But what’s different is that last year at this time, I had one event confirmed in my calendar for the next year - right now, I already have three.

Writing

On the writing front, I was not as productive as in 2024. I wrote a total of 20 posts (this being the 21st). I wrote one guest post in Selko Digital’s blog in Finnish (Vieraskynä: Verkkokauppojen mobiilisovellusten saavutettavuudessa on parantamisen varaa)

My blog posts were shared in multiple newsletters, and, according to analytics, the top three sharers were Android Weekly, JetC, and Accessible Mobile Apps. Thank you all for sharing my posts!

As always, I’m sharing some of my favorite posts from the past year.

Eevis

Feb 13 '25

Be Mine and Add Interaction with Compose and Canvas

#android #kotlin #tutorial #creativecoding

Comments

7 min read

This blog post was so much fun to write! And when I say write, I mean code. In the post, I explain how to add interaction (in this case, touch exploration) for Compose Canvas. The example used is a collection of Valentine’s day hearts with a queer twist.

Eevis

Mar 7 '25

Echoes of the Past - Tech is Still Not Equal for All

#wecoded #devchallenge #dei #career

Comments 11

8 min read

This blog post is part of Dev’s WeCoded-challenge, which started as a #SheCoded-campaing, turned into #WeCoded, and is now a writing challenge, happening around International Women’s Day. In the post, I share some comments and situations I’ve faced this year, mostly related to talking about diversity and inclusion.

It’s a hard post to write, but the feedback has proven that it’s an important one. So, I will continue writing these posts every year.

Eevis

Sep 6 '25

Wear OS Accessibility Considerations

#android #wearos #a11y #programming

Comments 2

7 min read

The final post I’m sharing is about accessibility considerations for Wear OS. I got into Wear OS development this year, and as an accessibility specialist, I naturally dove into the platform's accessibility features as well.

The Bingo

At the beginning of 2025, Dev had a writing challenge about 2025 predictions, and in my submission, 2025, Please, Be Gentle, I created a bingo card or two for this year's predictions. Let’s see how it turned out.

The Good Stuff

First, as a picture:

And then as a table:

B	I	N	G	O
Talk accepted to Kotlin Conf	I get invited to be a guest in a podcast	My research article gets published	Happened: Learn a new skill	Happened: More non-binary representation in conferences
Happened:Man speaks up against biased behaviour	New elections in Finland	Night outside, in a hammock	Get into a Doctorate program	Start mentoring again
A project is launched without a last-minute crunch	More women and non-binary in staff+ positions	Free space (Dream big!)	Happened: Blog post gets boosted or selected to Dev's top 7	Happened: #WeCoded without jerks commenting
Happened: Conference swag socks in my size	Happened: Someone says my work inspired them	Happened: A new tattoo	A genuine apology from someone after being a jerk	Get a book deal
Get promoted to Tech Lead position	Happened: 100K views in Dev	Not burning out during the year	Build a new, useful feature for Neule.art-app	Finish building a keyboard

Many of these things were things I hoped to accomplish, but I didn’t do much to achieve them. So it kind of makes sense that, with this card, I didn't get a bingo.

The More Realistic One

First, as a picture:

And then as a table:

B	I	N	G	O
Happened: Being addressed as a guy	Happened: Someone gaslights me	Happened: Biased AI-generated content	Happened: Man speaks over me	Called "intimidating" for being assertive.
Someone interrupts when I'm presenting	Happened:"Gender doesn't matter, just talent"	Man takes credit for what I said	Happened: Being left out of an important meeting	Happened: "You'd be heard better, if you weren't so angry"
Someone assumes I can't handle my tech setup	Meeting a new person who assumes I'm not a developer	Happened: "I've never seen anyone being discriminated"	Happened: "Intent over impact"	Happened: Man needs to repeat what I've said
Happened: Invalidation of lived experience	Happened: "Women just don't want to code"	Someone else credited for my work	Happened:"But they clearly didn't mean it"	Happened: Sexist comment in a blog post or talk
"You were hired just for diversity quotas"	Happened: Everyone's surprised after something I warned happens	Happened: Man splaining my expertise to me	Happened: "Equality has gone too far"	Happened: Hypothetical developer is referred to as "he" or other gendered noun

So, there it is - a realistic bingo. Unfortunately, I was right to predict these things, but hey, let’s hope next year is better in terms of the things I’ve listed in the bingo cards.

Other Things

Last year, I wrote a wish for 2025:

I wish that a year from now, I wouldn't have to think or write about burnout so much.

And this time, my wish came true. It wasn’t the easiest year, but today things are much, much better than they were this time last year. One major contributor was that I resigned from my old job and started pursuing things I’m truly interested in - and a better work culture.

What About 2026?

From where I stand, 2026 looks pretty good, and I can’t wait to get there and see what it actually holds. I already have some speaking engagements confirmed for the first half of the year. I also have some cool ideas and projects I’m working on and can’t wait to share them.

And hey, if your company needs expertise in mobile app accessibility, please do contact me! Let’s discuss how I can help you.

Links in the Blog Post

The Problem of Rows Breaking with Large Text

Eevis — Tue, 16 Dec 2025 10:45:00 +0000

This was originally sent as Issue #1 of my newsletter. Subscribe here to get future issues in your inbox first.

I was fixing an Android app and found buttons in a row getting cut off when I increased the font size. After diving into the code, the problem became clear: it was using Row when FlowRow was needed.

The Problem of Rows Breaking with Large Text

Let’s say we have this code:

Row(
  modifier = Modifier.fillMaxWidth(),
  verticalAlignment = Alignment.CenterVertically,
  horizontalArrangement = Arrangement.spacedBy(
    space = 16.dp,
    alignment = Alignment.CenterHorizontally
  )
) {
  Button(onClick = {}) {
    Icon(
      painter = painterResource(R.drawable.ic_arrow_back), 
      contentDescription = null
    )
    Text("Previous year")
  }
  Button(onClick = {}) {
    Text("Next year")
    Icon(
      painter = painterResource(R.drawable.ic_arrow), 
      contentDescription = null
    )
  }
}

Which, in turn, looks like this with the default font size:

However, when we turn the font size up to 200%, things start breaking:

Who This Hurts

People with low vision who need larger text to read comfortably
Elderly users (a huge and growing demographic)
Anyone using large system font sizes—whether for accessibility or personal preference
Users on smaller screens, where even default text can cause issues

Why Developers Do This

Developers often test on their own devices with default settings, and everything looks fine. They don't realize that Row treats its children as a non-wrapping container, so if the content doesn't fit, it just overflows or gets cut off. There's no automatic wrapping behavior. It's not a bug in Row. It's just not designed to handle dynamic content that might change size.

The Solution

The most straightforward solution would be to use FlowRow:

FlowRow( // Changed from Row
  modifier = Modifier.fillMaxWidth(),
  itemVerticalAlignment = Alignment.CenterVertically, // Changed from verticalAlignment
  verticalArrangement = Arrangement.spacedBy(8.dp), // NEW: spacing between wrapped rows
  horizontalArrangement = Arrangement.spacedBy(
    space = 16.dp,
    alignment = Alignment.CenterHorizontally
  )
) {
  Button(onClick = {}) {
    Icon(
      painter = painterResource(R.drawable.ic_arrow_back), 
      contentDescription = null
    )
    Text("Previous year")
  }
  Button(onClick = {}) {
    Text("Next year")
    Icon(
      painter = painterResource(R.drawable.ic_arrow), 
      contentDescription = null
    )
  }
}

Which fixes the issues:

FlowRow allows content to wrap on multiple rows if it doesn’t fit the horizontal space. Just remember not to set a fixed or maximum height for the FlowRow component!

When you use FlowRow, there are a couple of things to keep in mind:

Use itemVerticalAlignment instead of verticalAlignment (different API)
Don't set maxHeight or a fixed height, because if you do so, you'll defeat the wrapping
If you need certain buttons to stay together, you can nest them in their own Row within the FlowRow

FlowRow handles wrapping, but there’s one thing you’ll need to remember: each button still needs enough space to be readable. Test with large text and small screens to ensure everything works as expected for every user.

Note: FlowRow was added in Compose 1.4.0. If you're on an older version, consider updating or using a custom wrapping layout.

Flow layouts in Compose

Android Developers documentation has a whole page dedicated to flow layouts and how to use them. The page explains the features of flow layouts (FlowRow and FlowColumn), as well as how items can be arranged on the main and cross axes, aligned, and more. I recommend checking it out to learn more about flow layouts and how to use them.

Accessibility Scanner

Accessibility Scanner is a great tool for testing the accessibility of your app. It tests for four categories: content labeling, implementation, touch target size, and low contrast. While it does not reveal all possible accessibility problems, it can help with catching many low-hanging fruit.

Google has also provided a video about using the Accessibility scanner: Accessibility scanner - Accessibility on Android by Android Developers.

Wrapping Up

This was the first issue of the Inclusive Android Apps newsletter. What topics should I cover in the next issues?

Want to get future issues of Inclusive Android Apps delivered to your inbox? Subscribe here. Next issue covers building inclusive gender forms.

Why I'm Starting a Newsletter About Inclusive Android Apps

Eevis — Tue, 02 Dec 2025 16:03:00 +0000

One thing I'm super excited about at the end of this year is a newsletter I'm launching: Inclusive Android Apps. It's a monthly newsletter about making Android apps more inclusive, and it covers accessibility, LGBTQ+ inclusion, support for different cultures and languages, privacy and safety for marginalized users, and more.

In this post, I'm explaining why I'm starting it and what you can expect.

Why Inclusive Android Apps?

The short answer is that I'm starting the newsletter because I'd love to read it, and there's nothing like it around.

The longer answer is that these topics matter to me. Accessibility is a big part of my life, as you might know if you've read my blog posts, seen me speak at events, or followed me on social media. I'm also queer, and many of the issues I'm discussing are from what I've either experienced or witnessed. However, I'm not an expert on everything, and this is also me learning in public.

And I think that now, more than ever, it's important to raise these issues and talk about them. In this time when marginalized communities are under increasing political, social, and digital attack, building inclusive technology is an act of resistance. And you know, every accessible button, every inclusive form, every thoughtful design choice says: you belong here. This newsletter is about making that concrete.

What to Expect from Inclusive Android Apps?

Inclusive Android Apps will cover one inclusion problem each month. The structure of each issue is the following:

The Problem

The first section explains the problem the newsletter issue covers, giving examples of what happens and describing why it's a problem. Depending on the problem, it might be more about code or about a design pattern.

Who the Problem Hurts

Next, each issue has a list of user groups affected by the problem. For example, when buttons break at large text sizes, it affects people with low vision, elderly users, and anyone who has customized their text settings.

Some of these might be obvious, but not always - when I've been writing these issues and doing research, even I've been surprised by the number of different user groups affected by some of the problems.

Why Developers Do It

One of the most interesting parts of writing the issues has been exploring and documenting the reasons why the problem described in the newsletter occurs. Sometimes it's about not knowing specific solutions because there isn't much material out there, and sometimes it's about the biases we humans have.

I wanted to spell these things out, not to blame anyone, but to illustrate why something happens. The first step to combating biases and knowledge gaps is to recognize them; only then can they be addressed.

The Solution

Each issue provides actionable solutions: code examples, design patterns, or practical changes you can implement immediately.

Of course, because of the format (newsletter), it won't cover all possible solutions, just provide one (or a couple) suggestions to solve the problem. But as the newsletter explains the problem in detail, it will also give you some ideas to consider when solving the issue if the provided solution doesn't work for you.

Learn More

Finally, the newsletter will include links to learn more about the topic or about something recent related to the newsletter's subject. Each link is curated, and I will write an explanation of why I selected it.

Subscribe to Inclusive Android Apps

If you want to subscribe to the newsletter, here's the link:

Subscribe to Inclusive Android Apps

The first issue will appear in your inbox on December 9th, 2025! It will cover Rows breaking with larger texts, and a solution for how to fix that problem. The newsletter issues after that will discuss problems with forms that ask for gender and how using color alone to communicate information can be a serious accessibility issue.

Does AI Generate Accessible Android Apps?

Eevis — Tue, 25 Nov 2025 11:27:00 +0000

Over the past six months or so, I've been writing a series of blog posts in which I've generated an app using the same prompt with different AI tools, and then tested the outcome with various assistive technologies and accessibility settings.

The tools I've tested are: Gemini, Junie, Cursor, and Claude. You can find the list of the blog posts above.

Now it's time to wrap up and write a summary of my learnings. Something worth noting is that I started these tests in spring, which is like decades ago in the current pace of technical advancements. Unfortunately, when it comes to accessibility, not everything moves forward. So, even if the first findings are from the end of spring, they're still relevant for learning purposes.

Redundant Content Descriptions

Every tool I tested added redundant content descriptions. And with redundant content descriptions, I mean, for example, buttons that already had a text "Add yarn", and the content description was "Add new yarn", which adds zero new value. And in some cases, the implementation was such that the screen reader read both the text ("Add yarn") and the content description ("Add new yarn"), which added redundant listening for the user.

Claude took this even further, as it added sometimes actions to the content descriptions, meaning that after the redundant content description, there was a "Tap for details" text appended. The card where this was added already had a role of button set, so it led to the screen reader user getting something like: "Bla bla bla. Tap for details. Tap to activate". And if you're using your screen by listening, you probably want to skip redundant information.

From a technical point of view, it's understandable why it happens - accessibility documentation and blog posts often focus on screen reader accessibility, and content descriptions are probably the easiest way to add something and assume it makes the UI accessible. And AI has been trained with the documentation (among other things), so it's repeating these patterns.

Non-Scrollable Screen(s)

Another major problem these tests revealed was that, except for Claude, none of the tested tools added scrollability to the screens. The screens didn't contain that much information, so they didn't need scrollability at default text sizes. But the problems started when the font size was bigger.

If the screen doesn't support scrollability, and the content takes more vertical space than available on the phone screen, the content that goes beyond the visible screen is unusable.

As developers often test with the default font sizes, not all available apps support scrollability, so, again, from a technical point of view, it's understandable why this happens - the material the tools are trained with contains these issues.

Redundant Focusable Modifier

The first app I created with Gemini had this one unique problem from others - it added focusable modifier to a component with clickable modifier. What it means is that when a user who uses e.g. a keyboard or D-pad for navigation encounters this component, they would:

Focus on a button
Focus disappears
Focus on the next focusable item

I've seen this out in the wild - developers adding a focusable modifier because they think, with good intentions, that it improves the accessibility of the app. So, no wonder it was added.

Extra Tab Stops

Junie, on the other hand, created an interesting problem on the second run. When testing with a keyboard, an invisible component was added to the tab order. After some investigation, it turned out to be an invisible floating action button.

Incorrect Semantics

Junie and Claude both added some incorrect semantics to the components. On the second test run with Junie, as I asked it to improve accessibility, it added incorrect roles to some components and redundant state descriptions.

Claude went a bit further - it started hallucinating semantics. For a custom modifier called accessibleTextField, it added a role of Role.TextField, which doesn't actually exist.

Button Navigation not Supported

Finally, the last issue found on the tests was that Claude did not support button navigation. In practice, it means there isn't enough padding at the bottom of the screen for the button navigation not to hide the last content on the screen.

As a button navigation user myself, I see this happening way too often. I suspect most developers use gesture navigation, so they don't test with button navigation, which is why this pattern is widespread.

Summary

Here you can also find the findings in a table format.

Legend: In the table below, "YES" means that it's a problem.

Issue	Gemini	Junie	Cursor	Claude
Redundant content descriptions, which override the text	❌ YES	❌ YES	❌ YES	❌ YES
Redundant actions in content descriptions	No	No	No	❌ YES
Screen(s) not scrollable	❌ YES	❌ YES	❌ YES	No
Redundant focusable modifier	❌ YES	No	No	No
Large font sizes not supported	No	❌ YES	❌ YES	No
Extra tab stops	No	❌ YES	No	No
Incorrect semantics	No	❌ YES	No	❌ YES
Doesn’t support button navigation	No	No	No	❌ YES

Wrapping Up

This blog post concludes my journey into testing AI-generated Android apps. The testing results were pretty much what I expected - the apps contained similar issues that I see out there in the wild, with apps that humans have developed. So I don't believe code generation with AI will solve issues with the inaccessibility of Android apps anytime soon.

You might argue that the issues I've discussed are not that big. But it's worth noting that the app built from the prompt itself isn't that complicated, so a more complex app would probably have resulted in more accessibility issues.

So, all in all, I'm not convinced just yet. Different AI-tools can be helpful, but they're not yet ready to replace developers, as many non-developers would like to believe.

Writing Tests for Larger Font Sizes with Compose: Scrolling and Text Truncation

Eevis — Fri, 31 Oct 2025 08:14:00 +0000

While testing Android apps for accessibility, one of the biggest problems I’ve encountered are with larger font sizes. They’re usually not properly supported: content overlaps when font sizes increase, scrolling isn't enabled to accommodate growing text, or text is truncated without a way for the user to expand it.

I’m often asked tips on writing accessibility tests for Android, and I decided to write this post to demonstrate how to test some of those larger font size issues with UI tests. In this blog post, we’re looking into writing tests to verify that scrolling is enabled when needed and that truncated text can be expanded.

Let’s first discuss the screen I wrote to test these issues.

The Screen We’re Testing

I created an example screen with Compose to demonstrate tests in this blog post. It’s a Scaffold that wraps a LGBTQ+ Glossary of different gender identities and sexual and romantic orientations. If this were an actual app, there would be a separate screen for each of these categories, listing all the data. On this screen, only the first four are displayed, except for romantic orientation, which shows only the first two.

This is what the screen looks like with 100% font size (so, the default one):

Note that with the default font size, all content fits the screen, and no scrolling is needed. However, when the font size increases and text takes up more space, the content should be scrollable to accommodate that.

The content of the screen, explaining Non-binary, agender, genderqueer, transgender, asexual, bisexual, queer, lesbian, aromantic, and biromantic terms, is copied from the LGBTQIA+ Wiki 🏳️‍🌈🏳️‍⚧️. If you’re interested in learning more, you’ll find much more information on the link.

Testing Setup

Before we can start writing the tests, we need to do a bit of setup.

As the default UI tests are run against the default font size (100%), we need a way to specify the font size as 200% for the tests. There are several ways to do it. In this blog post, we’re going to use something rather straightforward: Composition local.

In our test class, let’s first get the Compose test rule:


class LargeFontSizeTests {
    @get:Rule val composeTestRule = createComposeRule()

}

And then create a function we can call in both of our tests to set content for testing:


fun setupScreen() {
    composeTestRule.setContent {
        AccessibilityTestsTheme {
            LargeFontScreen()
        }
    }
}

LocalDensity is a composition local which provides information about the screen’s density and font scale. Using it to change the tests’ font scale is a good strategy because it keeps the tests isolated and doesn’t require additional dependencies.

Let’s wrap our screen with CompositionLocalProvider, providing a new fontScalevalue for LocalDensity:


CompositionLocalProvider(
    LocalDensity provides Density(
        fontScale = 2f,
        density = LocalDensity.current.density
    ) 
) {
    LGBTQGlossaryScreen()
}

Now that we have the tests set up for larger font sizes, let’s move on to the actual tests and start by testing if the content is scrolling.

Scrolling Content

When a screen doesn’t have much content, it might be built in a way that it can’t be scrolled. Developers often develop with font size set to default (or even smaller), with phones that have big screens, so it might feel natural not to add scrolling to the screen.

However, when users increase the font size and/or screen size in accessibility settings, the content takes up more vertical space. So, for users, the ability to scroll is often needed to see all the content on the screen.

To write a UI test for this scenario, we’ll need to do three things on the screen: first, check that the last item is not visible to assert that scrolling is needed; then, swipe up; and finally, check that the last item is visible. In code, it would look like this:


@Test
fun contentIsScrolling() {
    setupScreen()

    composeTestRule
        .onNodeWithText("Biromantic")
        .assertIsNotDisplayed()

    composeTestRule.onNodeWithTag("screen-content")
        .assertIsDisplayed()
        .performTouchInput { swipeUp() }

    composeTestRule
        .onNodeWithText("Biromantic")
        .assertIsDisplayed()
}

In the test, we first call the setupScreen helper we defined in the previous section, and then assert that the last item (the card with the title “Biromantic”) is not visible. Then, we get the screen content node, check that it’s visible, and perform a swipe-up action. The final block checks that the card with the “Biromantic” title is now displayed.

The other scenario we’re going to test in this blog post is about text truncation. Let’s discuss it next.

Truncated Text

The other problem I see a lot with larger font sizes is that when the text doesn’t fit its container, it's truncated with an ellipsis, and there is no way to see the rest of the text. If this truncation strategy is used, there should always be a way to expand the text. I’ve written a blog post on the topic, so if you’re interested in reading more about the problems text truncation can create, here’s a link: The Problem of Trun...

In the example I created for this blog post, card texts are truncated with an ellipsis, and when the user clicks the card, the full text is displayed. So, for example, with genderqueer, the truncated version looks like this:

and the full version looks like this:

Helper Methods

Alright, and then the tests. We’ll want to write a couple of helper methods to make the code more readable.

`SemanticsNode.isTruncatedWithEllipsis()`

Let’s start with a check for a semantics node for if it is truncated with ellipsis:


fun SemanticsNode.isTruncatedWithEllipsis(): Boolean {
    val textLayoutResult = mutableListOf<TextLayoutResult>()
    this.config
        .getOrNull(SemanticsActions.GetTextLayoutResult)
        ?.action
        ?.invoke(textLayoutResult)

    return textLayoutResult.firstOrNull { layout ->
        (0 until layout.lineCount).any {
            layout.isLineEllipsized(it)
        }

    } != null
}

In the code snippet above, we first define a mutable list of TextLayoutResults, and then get the node’s TextLayoutResult semantics action, which returns a function that’s called for a text node when its text layout is measured. If the node has this action, we call its action-property, so the action that’s called when the function is invoked. And if it exists, we invoke that action on the mutable list we created, and then have the text layout result(s) of the node available for us.

After that, we map over the first text layout result’s lines (if available), and check if any of these lines are ellipsized. If any of them is, then we know that the text is truncated with ellipses. And if at any point of the check we get null, we can assume the node is not ellipsized, so the final != null check completes the function and returns a boolean.

`isEllipsized()`

Another helper function we need is a SemanticsMatcher for filtering out ellipsized nodes. Let’s define it:


fun isEllipsized(): SemanticsMatcher = SemanticsMatcher(
    "Truncated with Ellipsis"
) { node →
  node.isTruncatedWithEllipsis()
}

This function creates a SemanticsMatcher which checks if the SemanticsNode is truncated with ellipsis, so it calls the method we defined in the previous step.

`SemanticsNodeInteractionCollection.performClick()`

The final helper method we need to create is one to click all nodes in a collection. Compose testing libraries don’t provide this method out of the box, so let’s create it:


fun SemanticsNodeInteractionCollection.performClick() {
    this.fetchSemanticsNodes().forEachIndexed { index, _ ->
        this[index].performClick()
    }
}

We define the extension function for SemanticsNodeInteractionCollection. This collection doesn’t provide methods for iteration, so we need to get a little creative: We fetch the list of semantic nodes, which is the same size as the collection, and then call forEachIndexed on it. This way, we get the index and can retrieve the SemanticsNodeInteraction from that index, then call its performClick() function.

The Actual Test

Now we have everything for writing the actual test:


@Test
fun textIsNotTruncatedWithEllipsis() {
    setupScreen()

    composeTestRule
        .onAllNodes(isEllipsized())
        .performClick()

    composeTestRule
        .onAllNodes(isEllipsized())
        .assertCountEquals(0)
}

In the test, we first find all nodes that are truncated with an ellipsis and click all of them. After that, using the same matcher, we get all nodes that are ellipsised, and then assert that their count is 0 —meaning that all texts that were truncated are now expanded.

Wrapping Up

In this blog post, we’ve looked into how to write tests for two cases that often cause problems with larger font sizes: the screen is scrollable, and if there is text that is truncated, there’s a method to expand the text so that it’s readable.

These tests, especially the text truncation one, are simple ones and serve as an example. Your UI might be more complex and require a different kind of testing - for example, if your strategy is that you have cards with truncated text on your UI, and when the user clicks the card, a modal opens, the tests would require a bit more to assert that the whole text can be viewed.

Links in the Blog Post

Wear OS Accessibility Considerations

Eevis — Sat, 06 Sep 2025 10:39:00 +0000

Lately, I've been learning about Wear OS development. As I'm also an accessibility specialist, I've naturally also been looking into the accessibility aspects of Wear OS. The small form factor impacts many things typically associated with accessibility. Not everything can work, or is working, the same as with, for example, phones and tablets.

It's been fascinating to dive into the topic and learn more about it. In this blog post, I'll give pointers on Wear OS accessibility and share some of the learnings I've had. For transparency, I must note that my perspective is very Pixel-y, as I have a Pixel Watch 3.

Let's dive in!

Screen Reader Seems to Be on the Main Stage

Most of the available documentation about Wear OS accessibility focuses on making apps accessible for screen reader users. The Accessibility on Wear OS-page first mentions font size and rotary input (which we'll discuss later in this blog post), and then proceeds to optimizing apps for TalkBack (the built-in screen reader), which takes up most of the page.

And I'm not surprised - that's the case with most of the accessibility documentation for any platform. And don't get me wrong, screen reader accessibility is important, but there's often this misconception that that's all accessibility is. However, it's not just screen readers - there are many other sides to it.

In Wear OS's case, however, I think that it might even be warranted to keep the screen reader accessibility on the main stage of the accessibility documentation. The reason for that is that many other things work out of the box. I mean, of course, there are ways to make them not work, but unless you're misusing components, most of the things work.

The "Optimize your app for Talkback" section in the forementioned documentation comes down to basics:

Use built-in components, as they already have the semantics, accessibility actions, focus handling, etc. included.
Add content descriptions to tiles and complications.
- Tip! If you're wondering what to write in a content description field, or if the element even needs one, I've written a guide: How to Add Content Descriptions in Compose - A Guide for Android Devs
Understand list behaviours, so that you can build the app in a way that supports Talkback.

I recommend checking out the further details from the Accessibility on Wear OS-page!

Small Screen Size

As mentioned, small screen size brings its own accessibility (and usability) concerns. There's not much space for elements on the screen, so many of the usual design patterns for, e.g., phone apps don't work.

One cognitive accessibility-related concern is the use of icon buttons. And more specifically, icon buttons without labels. When the screen estate gets smaller, the number of labelless icon buttons usually increases.

Why is it a problem? Well, icons are not universal. It's not always easy to understand what each icon communicates and what action the button performs if there is no label attached to explain it. And if you have, for example, some cognitive disability, or are just stressed, it might even make things worse.

I personally hate icon buttons, because I rarely know what each of them does. I don't learn them, and I also hate the idea that I need to test what they do to know what they do. What if I accidentally delete some important data? Or call someone? The latter is probably my worst nightmare.

And yet, at the same time, I do understand that the small screen size requires some compromises on this front.

Font Size Considerations

Then there are the font size considerations - your app needs to support user's preferred font size. This support may require you to adjust the design of your app to accommodate the larger font sizes better.

The Wear OS accessibility page also mentions the following:

Use an ellipsis to show that text overflows its container.

I disagree with this to some extent. Truncating texts can be a huge accessibility (and usability) barrier. If you're interested in why, I've written a blog post about it: The Problem of Trun... So, my suggestion would be to think about whether the design could be changed to allow text to reflow if it doesn't fit the container.

Minimum Touch Target Size

Continuing from the previous section, as the watch screen is small, the importance of conforming to minimum touch target sizes with clickable items is even more important. And at the same time, it's tempting to reduce the clickable size to save screen space.

The minimum touch target size requirement, as per Android Material Design, is 48 x 48 dp. However, for Wear OS and small screen sizes, some situations allow a 40 x 40 dp size. The accessibility documentation does not specify these situations.

If you're using the built-in Material components, then you should be fine on this requirement. They have enough padding for clickable items to fill the touch target size needs.

Different Input types

Of course, as a medium, and due to its small screen size, a watch differs in input compared to, for example, a phone. I'll discuss two input types next: The text and rotary input.

Text Input

Inputting text on a small device presents some challenges. Luckily, Wear OS supports multiple ways of inputting text (and other data) to your app. Remote Input is the technical solution for this, and as Create input method editors on Wear lists, these options include:

Dictation
Emoji
Canned responses
Smart Reply
Default IME

The default keyboard has tiny characters (because of, you guessed it, the space constraints), so I personally like to use dictation way more. It's surprisingly good with Finnish, but with English, I apparently pronounce words in a way that it takes several attempts to get them right.

From an accessibility perspective, it's important to support different ways of inputting text. Someone might not be able to hit the keys on the keyboard, and someone might not be able to dictate, so supporting both makes the app more inclusive for users.

Rotary Input

The Wear OS Accessibility documentation explains the rotary input:

Most Wear OS devices contain a physical rotating side button (RSB), rotating bezel or touch bezel. This is called a rotary input. You can use the rotary input to adjust the volume of media apps, scroll content up or down, and more.

Wear OS devices are smaller than mobile devices, which presents additional challenges. Users with dexterity challenges may find accuracy on a small screen difficult. Screen reader users may also find it difficult to use two-finger interactions for scrolling. Using rotary input assists users with these challenges by providing a more convenient way to scroll rather than using the two-finger interaction.

In short, from the accessibility perspective, supporting Rotary input is essential. The Rotary input with Compose page explains how you can do that, so I'm not covering it here.

Reduce Animations

You know, the first thing I do when I get a new device is check for the reduce/remove animations or reduce motion setting, as I severely need it. I was happy to find it on my watch and turned it on. And after a while, I was surprised - I don't really need this setting on a watch as the animations that size don't trigger my symptoms.

But others benefit from this setting, so you want to support it. Luckily, if you're using the built-in components and animation APIs, then they take care of supporting the Reduce animations setting as well.

However, if you're building something customized, or get a bug ticket from someone saying your app doesn't respect the setting, here's how you can read the value of the setting and then adjust your code according to it:

val isReduceMotionOn = LocalReduceMotion.current

And that's it. I wish it were as simple on phones, and this Composition Local would also be available for larger Android devices (than watches).

Curious why the reduce motion (or, remove animations) setting is important for someone? A couple of years back, I wrote a blog post about motion sensitivity and how to support the remove animations setting on Android: Android, Animations and Reduced Motion

Magnification

Wear OS also provides a pretty neat magnification tool. While it's not something you'd probably need to support in your app code, it's useful to know it exists. You can turn it on from the accessibility settings of the watch.

With it, the same considerations apply as with the magnification on larger devices. These concerns mean, for example, having good enough color contrasts, not relying on touch-input only, keeping text field and other interactive element labels close to each other, and using graphics that don't pixelate too much when zoomed in.

Wrapping Up

So, in this blog post I've discussed different accessibility considerations for Wear OS apps. I've discussed screen reader support, small screen sizes, font size considerations, minimum touch target size, supporting different input types, the reduce animations setting, and magnification.

Were these all familiar to you, or did you learn something new?

Links in the Blog Post

Does Claude Generate Accessible Apps

Eevis — Fri, 22 Aug 2025 12:13:00 +0000

During the spring and summer, I've been testing different AI tools for their ability to generate accessible Android user interfaces. This post is the final testing post in the series. I will then write a recap post to summarize all my findings.

The drill is the same for this test as well - I generated an Android app with Claude and then tested it with various accessibility tools, settings, and assistive technologies. Let's first talk about the app I generated.

The App

This time, too, I did only one round of tests. The reason is similar to that of the previous tests with Cursor - the setup. I didn't want to pay $20 for this one blog post, so I'm using the free version, which means I'll need to operate within Claude's app and use the chat feature. Not optimal, but it gets the job done within the limits of my tests.

So, in short, I generated the code in the chat, then created an Android project in Android Studio, added the necessary files, and copy-pasted the code into them.

Prompt

The prompt I gave to Claude was:

Can you generate UI screens for an Android app with Jetpack Compose, in which user can keep track of their yarn stash and knitting needles per size and type? It should contain the following screens: Home screen, where user can add both yarn and needles, a list screen for yarn, a details screen for individual yarn, a list screen for knitting needles, a details screen for knitting needles.

The information to store about yarn consists of following: Brand name, yarn name, colorway, yarage in meters, weight of skein, amount of skeins, picture. Information for knitting needles consists of the following: Brand name, knitting needles size in mm, type (single pointed, double pointed, circular). The type should be a dropdown.

The app screens should be accessible for users with alternative navigation (switch device, keyboard, voice navigation), as well as screen readers, and it should work well in both vertical and landscape orientations, as well as with larger font sizes.

It should follow all Material3 best practices.

It listed the accessibility aspects considered. Here's that list:

Semantic descriptions for all interactive elements

Proper role assignments (Button, Switch, etc.)

Content descriptions for screen readers

Focus management with keyboard navigation support

Support for large text scaling

High contrast mode option

Voice announcement controls

Logical tab order in forms

Accessible dropdown menus

Proper heading hierarchy

Alternative text for images/icons

Screen orientation support

Touch target size compliance (48dp minimum)

Color contrast compliance with Material 3

Support for switch navigation devices

A funny thing is that even though Claude generated a AccessibilityExtensions.kt-file, it's not used anywhere. And oh my, how many redundancies does it contain. I could write a separate blog post about it.

So, while this list has many good points, in the context of this app, it's mostly just a list without the actual implementation of the relevant points.

The UI

Here's a short video of how the app turned out:

I must say I like it more than the other generated apps, which looked like copies of each other.

Testing Process

After building the app, I ran a limited set of manual accessibility tests on the app. I used my Pixel Fold, as I have everything for testing set up on it. The tools, assistive technologies, and accessibility settings I tested the app with were:

Accessibility Scanner
TalkBack
Switch Access
Physical keyboard
Voice Access
Large font sizes

The Problems I Found

As I expected, the app wasn't without any accessibility problems. Most notably, the familiar problem with redundant content descriptions was present, and it also hallucinated some semantic roles.

Let's look at the problems more closely.

Redundant Content Descriptions Are Here to Stay, Unfortunately

As with all the other apps, Claude's app also had redundant content descriptions. Here's one example (I've omitted the irrelevant parts)

FloatingActionButton(
    ...
    modifier = Modifier
        ...
        .semantics {
            contentDescription = "Add new yarn to collection"
        }
) {
    Row(...) {
          ...
        Text("Add New Yarn")
    }
}

In this case, the "to collection" part doesn't add any relevant information. When the FloatingActionButton has the contentDescription attribute and the text within, the accessibility text for this component is "Add new yarn to collection. Add new yarn." The solution would be to omit the semantics modifier with contentDescription.

Claude's code takes the redundancy even further: for some contentDescriptions, it adds redundant action text as well. Here's one example, a card for displaying needle list items with texts within the Card:

Card(
    modifier = Modifier
        .semantics {
            role = Role.Button
            contentDescription = 
                "${needle.brandName} ${needle.type.displayName} " +
                "needles, ${needle.sizeMillimeters} millimeters. " + 
                "Tap for details."
        },
    ...
) { ... }

The content description now contains all the same information as the contents of this card. It's already exposed to accessibility services, so it's redundant to add it here. However, it also adds the "Tap for details" text, which is redundant.

The card, being a clickable element, already contains the semantics to convey that it is clickable, so there's no need to indicate it in the content description. In addition, as it's an item on a list, so together with list semantics and clickability, there's no need to indicate that tapping it would open the details. That's a pattern in many apps, so it's likely familiar to users.

And now that we're on the topic of contentDescriptions, it's interesting how Claude adds contentDescription for IconButtons with semantics, and not with, well, the contentDescription-attribute:

IconButton(
    onClick = { /* TODO: Edit yarn */ },
    modifier = Modifier.semantics {
        contentDescription = "Edit yarn details"
    }
) {
    Icon(
        painter = Icons.Default.Edit, 
        contentDescription = null
    )
}

While the contentDescription is not redundant in this case, the more straightforward solution to set it would be the following:

IconButton(
    onClick = { /* TODO: Edit yarn */ }
) {
    Icon(
        painter = Icons.Default.Edit, 
        contentDescription = "Edit yarn details"
    )
}

Missing Grouping in Details Screen

The details, both yarn and needle, would need to be grouped with the labels and values so that they can be read together. Now, for example, reading the row with the label "Brand" and its brand name requires the user to navigate through both to obtain the information. With mergeDecendants = true for the semantics modifier, the user would hear both of them together.

In code, it would look like:

// DetailRow.kt

@Composable
fun DetailRow(...) {
    Row(
        modifier = Modifier
            .semantics(mergeDescendants = true) {}, <-- Adding this
        ...
    ) {
        Text(
            text = label,
            ...
        )
        Text(
            text = value,
            ...
        )
    }
}

Hallucinated Semantics

Out of all the AI tools I've tested this way, Claude has been the first to hallucinate something that prevented me from building the app. As I mentioned, it generated a whole AccessibilityExtensions.kt file, the contents of which are not in use. It had this one accessibleTextField modifier with Role.TextField:

fun Modifier.accessibleTextField(
    label: String,
    value: String,
    isRequired: Boolean = false
) = this.semantics {
    contentDescription = if (isRequired) 
        "$label, required field" 
    else 
        label
    text = AnnotatedString(value)
    role = Role.TextField <-- This role doesn't exist
}

When looking at the documentation of the Role, it doesn't have the TextField role. Additionally, all the semantics here are somewhat redundant, as the TextField composable already provides them.

No Proper Support for Button Navigation

The final problem I'm going to discuss is that the app doesn't support button navigation well. You know, the navigation mode, where there are those buttons at the bottom of the screen - see the video above in the the UI-section.

When increasing the font and display sizes, the app doesn't leave space for the navigation bar, and some of the content is hidden behind the system navigation bar, as seen in the picture below:

I personally use the button navigation (so, not the gesture navigation), and surprisingly many apps have this same problem.

In Summary

As mentioned before, I liked Claude's app the most from the UI perspective. From an accessibility perspective, the generated app wasn't too bad - it did have accessibility issues, but not as many as, for example, Gemini's first attempt.

However, this was the first time in my tests when I got some hallucinations. The hallucinated code wasn't actually used by the app, but it could have been.

The results didn't surprise me. I've reached the point of saturation, so it's time to write the summary post for all the tests I've been running over the last few months. So, stay tuned, that's coming next.

Links in Blog Post

10 Tips to Make Your Blog Posts More Accessible

Eevis — Fri, 18 Jul 2025 14:47:00 +0000

Sometimes I encounter this weird idea that developers don't need accessibility at all. Some people seem to believe that our development tools and resources don't need to be accessible, because accessibility is just something to do with the end users of our services.

If you're one of those people, you know, disabled software developers exist. You're reading text from one right now, and I know many developers with disabilities. Yes, even blind developers.

I've been writing a blog since 2019, and as an accessibility specialist, I've tried to make my blog posts as accessible as possible. In this blog post, I decided to share some of the things I've learned over the years. So, without further ado, let's get started.

Share Code as Text, not as Images

If you're writing a technical blog post and sharing some code, always write it as text, never share it as an image. Why? There are multiple reasons.

First of all, it's super annoying to copy the code from a blog post if it's an image. The reader would need to type it out, instead of just copying and pasting. At least for me, when I'm sharing code in a blog post, it's meant to be used, and the fastest way is to use copy and paste.

Images of code are also an accessibility problem. With an image, there is no way to make the text bigger, change colors for better contrast, or modify the text row length. All of these are things people might need to make the web content more accessible for them.

And then there's the text alternative part - if you're sharing an image of text, you should always include the text as text alternative (alt text) for the image. However, even if you include code, the way screen readers interact with alt texts makes it more challenging to use. E.g., navigating within the code is harder because screen readers read the text from the beginning, and it's not really possible to jump from one row to another.

So, always put code into a code block as text. Most blogging platforms allow this, and if you have your own website, semantic HTML also has these tags (hint: <code>) for including code without running it.

I mentioned alt text or text alternatives - if you're unfamiliar with the concept, I'll explain it in the next section.

Write Text Alternatives for Graphics

The next tip I'm going to give is to write text alternatives for images. Usually, blogging platforms allow this, and if you're using markdown, you can write it in the first brackets of the image. So,

![Alt text goes here](image url)

And if you're writing in pure HTML, the <img> element has the alt property:

<img src="..." alt="Text alternative goes here" />

Why? Text alternatives are there for people who can't see the picture. And that might include you, even if you're a sighted person. Most importantly, it's for assistive technology, such as screen readers, users. They need the same content as a sighted person can see as text.

It's also useful in cases where the image doesn't load. Slow internet? Yup, been there. If the image has a text alternative, I can still read the article. And all those crawlers that crawl websites can use everything that's in text format, so it's good for SEO and AI search.

And what should you write as the text alternative? WebAIM's Alt text page has excellent resources, explaining how, e.g., context affects the decision, and what decorative images are.

Use Readability Score to Guide Your Writing

When you're writing a blog post, I wholeheartedly recommend using tools like Hemingway or Grammarly for grammar. Additionally, they're great for getting a readability score for your text. I'll share about it in a bit.

I'm not a native English speaker, and I've relied on Grammarly for writing and checking my grammar for the whole time I've been writing blog posts. Nowadays, it complains less (I guess I've learned something, yay!), and it's been extremely helpful in producing better text. And no, I'm not using the generative AI features. I want to write my own text.

The readability score is a fantastic feature. It gives a score on how easy the text is to read, which helps to tailor the content for better, you guessed it, readability.

There are different scoring methods. The idea for all of them is to give a score indicating the education level the reader should have to understand the text easily. If you want to know more about the different methods, Flesch-Kincaid Grade Level and Flesch Reading Ease score are good search terms to start your explorations.

And okay, now you might think that for technical content, the education level should be university-level, as everyone in this field has at least a bachelor's degree. Okay, I really do hope you don't think that, because not everyone does.

We're reading texts in different situations. If the text is written in a way that it's readable for an eighth-grader, it also helps anyone who's, e.g., under stress to understand the text better. And I don't know about any of you, but for me, being stressed has been a large part of being a software developer.

Oh, and if you're wondering, the readability score of this text is 69 on Grammarly. It translates roughly to 8th grade, as Grammarly uses Flesch reading ease scoring.

List Links at The End

My next tip is to list all the links included within the text at the end of either a section or the blog post. For some people, it might be hard to see links inside a paragraph. This is especially true if the link styles don't differ that much from the text styles, e.g. the link is annotated only with a (slight) color change and lacks underlining.

And when you do list the links, use the same link text as in the original link (so, inside the text). Links leading to the same destination should always have the same text.

As an example, you can find links in this blog post in the Links in the Blog Post section.

Add Table of Contents

Adding a table of contents at the beginning of a blog post is also a way to make the post more accessible. This way, the reader can get a better picture of what the blog post contains. If the table of contents also includes links to each section, they can also navigate to relevant sections more easily.

I have a table of contents in each blog post in the original post that I publish on my website. It's automatically generated from the top-level headings. I've been thinking about copying it to the articles I'm cross-posting, but haven't done so yet.

Write Clearly and Simply

Writing clearly makes the blog post's content more understandable. It's also connected to the readability score, but it's more than just the length of the sentences and the words used - the factors used in the reading algorithms.

WebAIM provides a good resource on the topic, and I used the title of the page as the title of this section. The resource is available in WebAIM: Writing Clearly and Simply. I'll list the points from WebAIM below; you can read more about each step from the link to WebAIM's page:

Organize your ideas into a logical outline—before and during the writing process.

Introduce, explain, summarize.

Stay on point.

Make it interesting.

Write for your audience.

Assume that your readers are intelligent, but do not assume that they know the subject matter as well as you.

Write cohesive paragraphs constructed around a single major idea.

Avoid slang and jargon.

Use familiar words and combinations of words.

Use active voice… 10a. …but not necessarily always.

Use forceful verbs.

Use parallel sentence construction.

Use positive terms.

Give direct instructions.

Use positive or single-negative phrasing.

Explain acronyms and abbreviations; avoid them if possible.

Check spelling.

Write short sentences.

Ensure that every word and paragraph is necessary.

When you're finished, stop.

I have to admit that this is something I'm still learning myself. Using tools like Grammarly or Hemingway for writing helps, as they have checks for many of these points. However, I still struggle with some of them regularly. If you feel overwhelmed by the number of things to consider, I recommend using one of the writing tools mentioned and learning one thing at a time.

Explain Code Examples

If you share examples of code, in addition to giving them in text format, explain them as well. Even if you know what the code does just by looking at it, not everyone knows. Unless you know every single reader of your post and can be sure that they're never, for example, stressed or tired, explaining the code improves cognitive accessibility for readers.

Use Semantic HTML

This tip is relevant if you have access to the source code, such as when publishing articles on your website.

First of all, use semantic HTML on your website. Seriously, using divs for everything is not accessible. Semantic elements provide a lot of functionality and information for accessibility services and different navigation APIs by default, so you don't need to add that information or functionality yourself.

If you want to learn more about semantic HTML, I've written a blog post waaaay back: Ode to Semantic HTML. MDN's Curriculum has also a section about Semantic HTML.

Display Estimated Reading Time

Another tip for sites where you can customise the presentation of the article beyond just the text is to consider adding estimated reading time for the article. Having it at the beginning of the article can help users decide if now is the time to read the article, or if they should return to it later. It also helps to manage expectations - roughly, how long should I expect to spend reading it?

Depending on the technology you're using for building the site, there are tools or plugins for that. For example, my site is built with Eleventy, and I use
eleventy-plugin-time-to-read for calculating the time to read. It's not perfect, but it gives a good enough number for the purposes.

Consider Adding a Summary

The last tip I'm going to share is to consider adding a short "Too Long, Didn't Read" (TL;DR) type of summary at the beginning of the blog post. This summary provides the reader with an idea of what's in the blog post, whether it's relevant for them, and helps to understand the content better.

I have been planning to add this for a long time, but haven't gotten to it yet, as it has felt hard to summarize the essential points. Like, what's the most important thing in the post? But I intend to explore how well different AI tools would do this, meaning I'll just need to find the right prompt and then check the result to see if it's correct.

Wrapping Up

In this blog post, I've shared some advice on how to make blog posts more accessible for all. The tips have ranged from the text and content itself to modifying the site itself to make it accessible, if you have access to the website's source code.

Do you have any additional advice? Did you learn something new?

Links in the Blog Post

It's All About (Accessibility) Focus And Compose

Eevis — Mon, 07 Jul 2025 12:41:00 +0000

I've seen multiple questions in various Slack communities, Stack Overflow, and other places related to focus on Android and how it doesn't behave as expected. The question typically concerns the use of focusRequester and then inquires why Talkback or other assistive technologies fail to set focus correctly.

The simple answer is that these APIs are different, and focus behaves differently with accessibility focus and keyboard focus.

In this blog post, I'll discuss the differences and what you can do in different cases. Let's first look at what I mean when I talk about accessibility focus and keyboard focus.

Accessibility Focus

In this blog post, accessibility focus refers to the focus related to screen readers, such as TalkBack. It could include focus for switch access as well, but I'm leaving it out of the scope of this blog post.

When using a screen reader, accessibility focus can be set to any element relevant to the user, such as interactive elements, text, images with text alternatives (content descriptions), and other meaningful elements. The focus indicator can look different on different phones, but here's an example from my phone:

It's set by the system, so the app developer can't edit it, and there shouldn't be any need to do that either.

Keyboard Focus

Keyboard focus, on the other hand, is the focus that interactive elements receive when a user uses a keyboard, D-pad, or other keyboard-emulating device for navigation.

Only interactive elements should be focusable; never, for example, headings or other text. The default focus indicator is the ripple, so it's not that visible:

Later, I will write a blog post about customising and making the focus indicator pass the accessibility legal requirements with color contrast and other requirements.

Making a Component Focusable

So you're creating a custom component, and wondering if it's the kind that should be focusable. The short and simple answer is that every component that the user can interact with via touch input should most likely be focusable. The actual interaction should be handled with accessibility actions and key events, depending on the component.

To put it even more clearly: every button, checkbox, editable text, swipeable element, and graph that has touch input for either/both scrolling or/and data point exploration, should usually be focusable.

However, note that when using Material components, such as buttons and other interactive elements, they are already focusable, so you don't need to add it manually. Adding, for example, a focusable modifier makes the element appear twice in the focus order.

There are several ways to make a custom interactive element focusable for both screen readers and keyboard navigation.

Using clickable, toggleable, or selectable modifiers. If you're creating a component that the user should be able to either click, toggle, or select, use the respective modifiers. They make the component focusable as well.

Using focusable-modifier. Sometimes a component needs to be focusable, but it's not clickable, toggleable, or selectable. It might, for example, require custom keyboard shortcuts, such as a chart with touch input that reveals more data with touch gestures. In these cases, using the focusable modifier is the right choice for making the component focusable.

Moving Focus Programmatically to a Component

The next thing we need to discuss is moving the focus programmatically based on the user's actions. For keyboard and keyboard-emulating navigation methods, this is relatively straightforward. For screen readers, it requires a little bit more. Let's first discuss the keyboard focus and then the accessibility focus.

Keyboard Focus

If you want to move keyboard focus from an element when a new screen appears, or on, let's say, a button click, FocusRequester is your friend.

Here's what using it looks like in code:

@Composable
fun Component() {
  val focusRequester = remember { FocusRequester() }

  Button(
    onClick = { focusRequester.requestFocus() }
  ) { 
    Text("Move focus") 
  }

  CustomComponentWereFocusing(
    modifier = Modifier
      .focusRequester(focusRequester)
      .toggleable(...)
    )
}

In this example, when the user clicks the Button, focus moves to the CustomComponentWereFocusing. We first define the focusRequester by remembering FocusRequester(), then set it to the focusRequester modifier for the CustomComponentWereFocusing. Finally, we call FocusRequester's requestFocus() method on button click.

One important thing to remember here, as with other modifiers, is that the order of modifiers matters. So, when setting the focusRequester modifier, it must be placed before the modifier that adds focusability to the component. Otherwise, it doesn't work at all.

Accessibility Focus

Moving the accessibility focus for screen readers needs a little bit more work. The focusRequester doesn't work here, so we need to resort to workarounds to accomplish it. I'll share some ideas; the final implementation, naturally, depends on the actual use case.

The first suggestion is that, in some cases, changing the traversal order may be the solution. The following section discusses this topic, so keep reading for tips on how to do that.

Then there's a solution for changing the focused property on the semantics modifier. I found this solution from Kotlinlang Slack's Compose channel.

The example from the keyboard navigation section with the ability to focus with a screen reader would look like this:

@Composable
fun Component() {
  val isFocused by remember { mutableStateOf(false) }

  LaunchedEffect(isFocused) {
    if (isFocused) isFocused = false
  }

  Button(
    onClick = { isFocused = true }
  ) { 
    Text("Move focus") 
  }

  CustomComponentWereFocusing(
    modifier = Modifier
      .semantics { focused = isFocused }
      .toggleable(...)
  )
}

So, here we first define a boolean variable isFocused, which we remember. Then, we set the focused property of the semantics modifier to isFocused for CustomComponentWereFocusing. On the button click, we set the isFocused to true to move the focus to CustomComponentWereFocusing.

And finally, we have a LaunchedEffect listening for changes to isFocused, and if it's true, we set it back to false. It doesn't clear the focus from CustomComponentWereFocusing, but lets us refocus with a new button click if needed.

Here, again, the order of the modifiers matters - semantics needs to be before the focusability-applying modifier, which is toggleable in the example.

Changing Traversal Order

The final topic for this blog post is changing traversal order. Let's say we have a layout with two rows and two columns. The layout looks like this:

The default focus order would be as follows: first top row, then bottom row - meaning First, Third, Second, Fourth. And we want it to be in numerical order.

The solutions for accessibility and keyboard focus are different, so let's discuss them separately, starting with accessibility focus.

Accessibility Focus

For accessibility focus, using the semantics modifier, isTraversalGroup, and traversalIndex is the way to customise the focus order.

First, let's set the isTraversalGroup property to true for the parent component wrapping the two rows. Why? It's to create a border for our changes in traversal order. You see, if we don't set it, and set the traversalIndex to the buttons, they'd be last in the screen's focus order, because their traversal index is greater than 0. Zero is the default traversal index for elements that don't have the traversal index explicitly set. However, if we set the border with isTraversalGroup, then the changes will only affect the focus order within the traversal group, not the screen's focus order.

So, in code it would look like the following:

Column(
  modifier = Modifier
    .semantics {
      isTraversalGroup = true
    }
) {
    ...
}

And then we set the traversalIndex for each of the buttons to match the focus order we want to create:

Row(...) {
    Button(
        modifier = Modifier.semantics { 
            traversalIndex = 1f
        },
        ... 
    ) { Text("First") }
    Button(
        modifier = Modifier.semantics { 
            traversalIndex = 3f
        },
        ... 
    ) { Text("Third") }
 }

I've omitted the other row, which contains the "Second" and "Fourth" buttons, from the example, but the idea remains the same.

And that's it. With these changes, the focus order for accessibility focus changes. Let's talk about keyboard focus-related changes next.

Keyboard Focus

For keyboard focus, we first need to create FocusRequesters for each button with FocusRequester.createRefs(), and then attach them with focusRequester modifier, and finally, set the focus order with focusProperties modifier.

Creating the FocusRequesters looks like the following code:

val (first, second, third, fourth) = remember { 
  FocusRequester.createRefs() 
}

Next, we set the FocusRequesters with focusRequester modifier and the next element to focus on with focusProperties modifier:

Row(...) {
  Button(
    modifier = Modifier
      .focusRequester(first)
      .focusProperties { next = second},
    ... 
  ) { Text("First") }
  Button(
    modifier = Modifier
      .focusRequester(third)
      .focusProperties { next = fourth},
    ... 
  ) { Text("Third") }
}

I've omitted the second row from the example, but it would be similar.

This way, keyboard and keyboard-emulating device navigating users would first get to the "First" button, then "Second", then "Third", and finally, "Fourth".

Wrapping Up

In this blog post, I've discussed the differences between focusing with screen readers (e.g., TalkBack) and navigating with the keyboard. I've also demonstrated the differences between the two in changing the currently focused element and altering the traversal/focus order.

If you want to read the docs, Modify traversal order is the page to check for accessibility focus, and Focus in Compose summarizes the information about keyboard focus.

Forem: Eevis

About Invisibility, Propaganda, and Assumptions of Incompetence

Non-Binary Woman, an Invisible Creature

What if Your Existence is Propaganda

The Bad Ol’ Arguments

Wrapping Up

Adding Navigation support to Large Content Viewer with Compose

Keyboard Navigation Support

Screen Reader Navigation Support

Considerations for Voice Access

Wrapping Up

Links in the Blog Post

Beyond Font Scaling: Large Content Viewer with Compose

Large Content Viewer on iOS

Accessibility Considerations

Building Navigation Bar Item Preview

Detect the Long Press

Display the Preview

Enabling the Preview

Links in the Blog Post

Year in Review - 2025 Edition

Accomplishments

Speaking

Writing

Be Mine and Add Interaction with Compose and Canvas

Echoes of the Past - Tech is Still Not Equal for All

Wear OS Accessibility Considerations

Other Content Creation

The Bingo

The Good Stuff

The More Realistic One

Other Things

What About 2026?

Links in the Blog Post

The Problem of Rows Breaking with Large Text

The Problem of Rows Breaking with Large Text

Who This Hurts

Why Developers Do This

The Solution

Read More

Flow layouts in Compose

Accessibility Scanner

Wrapping Up

Why I'm Starting a Newsletter About Inclusive Android Apps

Why Inclusive Android Apps?

What to Expect from Inclusive Android Apps?

The Problem

Who the Problem Hurts

Why Developers Do It

The Solution

Learn More

Subscribe to Inclusive Android Apps

Does AI Generate Accessible Android Apps?

Redundant Content Descriptions

Non-Scrollable Screen(s)

Redundant Focusable Modifier

Extra Tab Stops

Incorrect Semantics

Button Navigation not Supported

Summary

Wrapping Up

Writing Tests for Larger Font Sizes with Compose: Scrolling and Text Truncation

The Screen We’re Testing

Testing Setup

Scrolling Content

Truncated Text

Helper Methods

SemanticsNode.isTruncatedWithEllipsis()

isEllipsized()

SemanticsNodeInteractionCollection.performClick()

The Actual Test

Wrapping Up

Links in the Blog Post

Wear OS Accessibility Considerations

Screen Reader Seems to Be on the Main Stage

Small Screen Size

Font Size Considerations

Minimum Touch Target Size

Different Input types

Text Input

`SemanticsNode.isTruncatedWithEllipsis()`

`isEllipsized()`

`SemanticsNodeInteractionCollection.performClick()`