Eevis Blog

Why Playing Team Sports Makes Me a Better Developer

2023-01-03T08:57:51.135Z

I've played team sports since I was something like ten. First, it was floorball - this fantastic indoor sport, where you have a stick, a ball, and goals. Something similar to hockey, but less violent. And after all, completely different.

Then I moved to another city and soon realized that it's not as fun as it used to be with the team I had played with for 10 years. I switched to ultimate frisbee, which is something I still play. I also did a tour in the roller derby world, loved the sport but got a brain injury. I realized that if I want to be able to do my job, I need to let this awesome thing go. I'm sometimes still sad about it.

So, I have a history (and hopefully future) with team sports. I've done some coaching during the years and participated in different boards - be it a club or national level organization. So I could say I've gotten a lot from this and also learned a ton.

One day, while I was doing some ladder drills (they're for agility on the field), I started thinking if there has been anything I've used from my sports background in my day-to-day job. After pondering for a while, I realized that yes, there is. In this blog post, I will share some of those thoughts.

Many other activities may provide just the same benefits. However, my background is in team sports, so that's why my angle is from the perspective of team sports.

Team Spirit (of the Game)

If you're not familiar with ultimate frisbee, you might wonder what the heck the title of this section means. Let me explain. In ultimate frisbee, there is this thing called "Spirit of the Game," which has to do with, for example, fairness of the game and sportsmanship. It's something that makes the sport possible to play without any referees (yup, you read it right!).

During the years, being part of a team has indeed taught me to be a better team member. Especially being part of teams that comply with such philosophy as the Spirit of the Game. I know how to work in a group, and also that different people have distinct strengths. Also, I've learned to get along with a very diverse set of characters - not all of them "click" with me, but still, we are a team, and we need to work together.

Team sports are never about one individual. There are 5-7-ish people on the field (depending on the sport), and everyone is needed to score. This makes me try to do my best and never let the team down.

Perseverance

As the season approaches, there is usually some kind of goal. Some years, for my team, it has been the national championships. That goal has been the guide for every practice and game. It's a long time from the pre-season to the final match, and perseverance is needed.

The same has been true with every development project I've been in. Development projects tend to be long, and there are always moments when I want to give up. Learning perseverance from sports helps me to put those moments in context. It also gets me through that valley of whatever it is that makes me feel like giving up.

Willingness to Do Voluntary Work

I grew up in an environment where doing voluntary work for the club was expected. So I've spent countless days raising money, officiating games, cleaning up places, and so forth. Whenever there is a new "working together day" with my club, my first thoughts are, "ok, this is mandatory." (I'm not sure of the correct translation of the word; for those who understand Finnish, I mean "talkoot.")

I've come to realize that this is not the case for everyone. Of course, not everyone can give their time, because sometimes life gets in the way, but I'm talking more about attitude here.

I've been reflecting on the topic a lot during the past couple of weeks. On Friday 23rd of April, I received the first-ever Mimmit Koodaa-award for my work for the Mimmit Koodaa-community. This community (translates roughly "Women code") is helping to bring more women into tech.

The justification for me getting the award was all the hard work I've done for the community. I've gotten so many praises, and "yeah, it was definitely the right person who got the award"s. However, every time I hear, "you've worked so hard!" I instantly think, "Umm... but isn't that something that every single one would do?". Apparently not.

So that's the attitude and position where I am because of my background. This is not to brag or anything. I'm just trying to reflect on some thoughts and how my experience affects the work I do - at my day job and outside of it.

Getting Away from Work Thoughts

While the previous ones are something that I'm going to carry with me for the rest of my life, the next ones are about the direct consequences of doing sports.

After a long, intensive day at work, it is sometimes hard to let go of those work-related thoughts. They just keep going around and around and make me anxious because I know I shouldn't be thinking about them and because I can't do anything to them at that point. Going into practice, where I need to give 100% of my concentration to the drills and game, definitely helps me let go of those thoughts.

You could argue that any sporting activity would do. Well, for me, going for a run alone would mean that the thoughts are still there, and I would go even deeper into them because I'd be alone with those thoughts. However, being around people who have nothing to do with my work and doing something completely different helps me forget.

Keeping My Brain Functional

For developers, our brain is the most crucial tool for doing our jobs. I've faced the situation where I needed to give something up to keep the risk of losing anything more from the brain capacity I have. So I could say I've given some thought to this.

This point, however, is not just about protecting our heads from injuries. I'm talking about the effects actively moving has on our brain. As Heidi Godman writes:

Exercise changes the brain in ways that protect memory and thinking skills.

To be precise, the effects were visible from regular aerobic exercises. For example, muscle training didn't have the same results in the study. If you want to learn more, I highly recommend checking the article linked.

So, being part of a sports team also requires me to continuously be active, whether in-season or off-season. Luckily this is good for my brain health too. And, as said in the previous point, another part is that I have some mechanisms to let go of those work-related thoughts, so that's really good for my brain too.

Wrapping Up

So, I get numerous benefits from team sports - both from my long history with them and from actively being part of a team. Some of them are skills that can be directly used in the teams and projects at work, and some of them help me to be healthy enough to do my job.

Coming back to the title of this blog post, you might wonder how this makes me a better developer while I haven't really touched coding at all. Well, the most important aspect of the development is not coding. I think being a good developer is more about communication and team skills.

Recovering after the day at work is essential. I've worked with many people on the edge of burnout. They're usually not the nicest members of the team to work with because of the stress and other symptoms they have. Heck, I've been one too, and I wouldn't want to work with me from those times. So taking care of yourself is not only for you, it is for your team too. And I believe that makes a better developer.

Do you play any sports? Or have you noticed benefits or learnings you get from leisure activities that are usable in your day-to-day job?

Photo by Isaiah Rustad on Unsplash

Let's Talk About Accessibility

2023-01-03T08:57:50.254Z

Yesterday (20th of May 2021) marked the 10th Global Accessibility Awareness Day, celebrated on the third Thursday of each May. It started from a single blog post from Joe Devon and has grown into a global event since then.

One example of what Global Accessibility Awareness Day, or GAAD, has achieved is GAAD Pledge. The first company to take the pledge was Facebook, committing to make the React Native framework fully accessible.

Why is GAAD Important?

I believe raising awareness about accessibility is essential. I mean, if we, who are creating the web, aren't aware of these things, how in the heck can we assume the sites and apps will be built in a way that everyone, whether they have a disability or not, can use them?

But it is not just that. The importance of raising awareness is not that only developers would know; it's about the other roles too. If designers ignore accessibility, some things (say, color choices) are hard to fix on the developers' end. If the product owner cares more about IE6 users than accessibility, well, those bugs get prioritized. If the people who decide on the budget see other things as more important, developers can't fix that.

WebAIM has conducted its yearly analysis on the top million sites on the internet. In February 2021, 97.4% of these sites had detectable accessibility errors. And as they've used an automated tool for the analysis, it doesn't even catch all the failures. (Automated testing tools catch only about 15-40% of the accessibility failures.) So this means that sites like Google, Twitter, Youtube, Facebook, and others on the top million sites list have many accessibility barriers.

About 1 billion people worldwide need websites to be designed and developed with accessibility in mind in order to be able to use those sites. If we don't do that, we are excluding a hell of a number of people. You know, actual people, and not just numbers.

But it's Not Only About the Websites

Okay, I've been writing from a perspective of a (web) developer and touched on a couple of other roles that are part of creating sites and apps. How about the others? Don't they need to know about accessibility? Well, yes, they do.

Let's think about, for example, social media for a while. Even if the app or site is developed to be accessible, the content creators may make it inaccessible. Adding alternative texts or image captions is the content creators' responsibility, as are adding captions, transcripts, and audio descriptions for videos and audios.

If you are now wondering what the heck am I writing here, let me explain— a person who can't see the picture benefits from a descriptive image caption. You know, all the information they would get from that image if they saw it.

In the same way, if a person can't hear, due to being deaf or, as in my case, just browsing the Instagram stories without sound, having captions for those videos is crucial. Audio descriptions of a video are essential for those who can't see. And for those, who are, for example, deafblind, transcripts are a must.

And oh, why I'm using phrases like "those who can't see/hear" instead of, for example, a person who is blind or deaf, is because this goes further than that. As with all the accessibility improvements, we all could benefit. As mentioned, I rarely watch Instagram stories with a volume on, so when people add captions, that means I get the gist of the story. And then I might watch it, not just skip it.

It's About the Language

Another thing is the language we use. This topic is two-sided: First, I want to talk about plain language, and then a bit about ableism.

Plain Language

International Plain Language Federation defines the plain language with the following words:

A communication is in plain language if its wording, structure, and design are so clear that the intended readers can easily find what they need, understand what they find, and use that information.

So, this basically means avoiding jargon and getting to the point as fast as possible. If you're interested in learning more about writing clearly and simply, WebAIM has got you covered..

Ableism

Another point about the language I wanted to raise is ableism, especially in the language we use. There are certain phrases that are part of the language that we use without thinking. Like, have you ever said that "This week has been crazy!" or "I'm feeling autistic right now" or similar? Well, you know, that's not okay.

You might feel offended right now because you feel like I'm blaming you for something, but that's not the case. We all use language unconsciously, and if we've learned the phrases, they come naturally. So I'm not assuming that you're doing this on purpose, just out of not knowing. And that is fine because now you know and can do something about it. Changing the language we use is a long process (heck, I still make mistakes almost every day), but it is worth it.

Here is an excellent article from Rakshitha Arni Ravishankar explaining more on the reasons why such language is harmful and what we can do about that.

So What Can I Do?

Okay, I got you there, right? And now you know that something needs to be done. It might feel like a lot and overwhelming, but let's take one step at a time. I could give a long list of things to do, but let's start with two.

Educate Yourself

First, educate yourself. If you're someone in charge of creating sites or apps, learn how to make them accessible. Learn about people with disabilities and their needs. Listen to their stories.

I'm sharing some of my favorite resources here, both from the technical and more general perspective:

13 Letters Podcast - A podcast about accessibility with super interesting topics and guests
The A11y Project Resources - A huge collection of resources about accessibility.
A11y Talks - Virtual meetup about accessibility. Topics covered have been broad, from marketing to development.
WebAIM Articles - A collection of resources about disabilities, digital accessibility, laws, and other relevant things

Check Your Content and Language

So, another thing that you could do is to check the content you create. It's possible to add alternative text to images. Here are links to the instructions in some significant social media sites: Facebook, Instagram, LinkedIn, Twitter.

If you have videos or audio-only content (podcasts are a good example), make sure that everyone can use that content. Add captions, transcripts, and audio descriptions, whichever are needed for that particular content.

Also, be conscious of your language. If you find yourself using ableist phrases, start making an effort to change those phrases. There are always alternatives.

Wrapping Up

I hope that this blog post has raised awareness about accessibility for you and that you've learned something new. It would be awesome to hear if that has happened, so please share your learnings!

Cover photo by James Sutton on Unsplash

Don't Develop Just for Yourself - A Developer's Checklist to Accessibility

2023-01-03T08:57:24.476Z

We, as developers, tend to develop sites unconsciously for people like ourselves. If we don't actively pay attention, the sites are often accessible only for certain types of people: Sighted mouse-users, who have good fine motor skills and are good at using computers.

It leads to moments where no one who navigates the web with only a keyboard (or keyboard simulating device) can access and interact with the site. It is a pretty big group of people!

We have a responsibility to make sites that work for all of our users. In some cases, it is required by law, but it is not the only reason we should care.

This blog post is aimed for those at the beginning of their accessibility journey. You might know some things, like "always provide an alt-text for an image," but are unsure what to write there. Or you don't have any idea how to know if your site is accessible at all.

Following this blog post won't make your site 100% accessible! The goal of this post is to provide some information about some things to check manually after using some automated testing.

First of all, abandon your mouse for a second. Don't use it. Try to navigate through the website using only the keyboard. Try to complete every task user needs to be able to complete on the website. Can you do it? Can you see where you are at the moment? Is the focus indicator (yes, that thing many designers and developers like to remove) visible enough?

If you can't use the whole website with only a keyboard, that is an accessibility and usability problem. However, one thing to note here is that keyboard interaction is not necessarily accomplished with just tab and enter, as it has been at some point. The general pattern goes, as WAI-ARIA Authoring Practices state:

A primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements.

Another thing to consider in this point is focus indicators. They should be visible, and even if the default focus indicator on the browser is sufficient to pass the WCAG-requirements, it might be hard to see. So I would recommend enhancing the focus indicator to be more visible. Just remember that the color of the indicator should have a sufficient contrast ratio with the adjacent background.

Using only your keyboard, navigate through your site. Pay attention to navigation menus and other custom widgets that might lose focus because some elements are hidden incorrectly.

Is everything reachable and operable without a mouse? Can you see the focus every time?

Alt-Texts

Another thing to check manually is alternative texts for the pictures. You might wonder, isn't it a thing automated testing catches? Well, yes. Automated testing tools crawl through the markup, and when they find an img-element, they check if the alt-attribute is present. They don't (and can't) check the quality of the alternative texts.

Not all images need alternative texts; however, they do need the alt-attribute. So for a purely decorative image, you need to provide an empty alt-attribute. This "hides" the image from the screen reader so that it won't get read at all.

You might ask, shouldn't screen reader users know about everything on the page? A person, who consumes the web by listening, might want to reduce the amount of information.

Action Item for Alt-Texts

Go through every image on the page. You can use, for example, Web Developer-extension or the developer tools and check the image's alt attribute.

Is the text descriptive? Or is the picture decorative? You can find more information on how you should write the alt-text for every type of image from WebAIM: Alternative Text.

Page Language

Another thing that automated tests catch, if it's missing, is the page language. Some of the project starters, such as create-react-app, have the lang-attribute set automatically, but some (I'm looking at you, NextJS) don't.

If the site's language is English, you're pretty much okay with the automatic language (if it exists). However, if it is not, then you need to change it. The reason is that the language screen readers use for the page comes from that lang-attribute. So if you have a page with content in Finnish, and there is that en-attribute, a screen reader would pronounce every word with an English accent. That's not beautiful. Here's an example with another way around. It's almost as bad:

Action Item for Page Language

Check the language of the page in the page's html-attribute. You can do this from developer tools' Elements-tab. Is the language code the same as the primary language on the page?

Text Resizing

Some people increase the text size of the webpage with, for example, browser settings. It means that the content takes more space and might flow differently. Developers should test if the site is working when text size has been increased to at least 200%.

Action Item for Text Resizing

Have the webpage on two browsers open, preferably side by side. In the first browser, use browser's built-in zooming for testing by using CMD++ if you're using a Mac, and CTRL++ if you're using Windows or Linux. Increase the size to the maximum, which should be 200%. Compare the zoomed site and the one without a zoom.

Does your site still work? Is the text flowing okay? Does increasing the text size add horizontal scrolling? Is all the information still there?

Color Alone

If color alone conveys meaning, there are lots of users who miss out on that information. For example, suppose there is a list of different activities, and their level of advancement is communicated only with a colored box. In that case, there are some groups of people who can't access that information.

For example, a person who is color blind can't separate certain color combinations, and thus the information, when it's conveyed only with color, is not understandable. Also, for screen reader users, the color does not say anything; screen readers don't say anything about the web page's styles.

Action Item for Color Alone

One thing that could be used as help for testing if the color alone is used to convey a meaning is to change the site into grayscale.

How to turn a page grayscale?

You can turn a page grayscale from the developer tools in Chrome and Edge from the "Rendering"-tab. You can find it with the same instructions as for the [`prefers-reduced-motion`-simulation][3]. There is a header "Emulate vision deficiencies" on that tab, and you can choose Achromatopsia from the select.

Can you still understand all the information on the page?

Mobile Zooming

I remember, that at some point it was customary to add this <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" /> to disable the pinch-zoom on webpages. Nobody ever explained why it was, but it was everywhere I copied code to my projects. I didn't know then that it would make zooming on touch devices harder.

Some people need to use zoom to see the elements on the page. Also, many people want to, for example, zoom in on pictures to see how they look in that picture or some other detail. And sometimes, the website is unusable without zooming. That is a thing that would need fixing from the developers' side, but things don't always happen too fast, so meanwhile, users would need to use the zoom.

Action Item for Mobile Zooming

Open your site or app on a mobile device. Try zooming in with your fingers. Can you do it?

Captions and Transcripts

Captions

Imagine if you couldn't hear the words said in the video. How would you then understand what is going on in that video? It can happen for numerous reasons. You could have a hearing-related disability or be in a crowded place where you don't want to turn the sound on.

For these situations, captions are essential. Captions are a bit different from subtitles. They also contain information about important sounds on the video, and they identify the speaker if they're not easy to identify from the video. Captions can be either closed, meaning they can be turned on, or open, meaning they are always present.

And a word about auto-captions: Please, no. The speech recognition algorithms aren't that good yet, and they produce lousy quality. Some even call them "auto-craptions." Suppose you don't have a hearing-related disability and haven't encountered this in your life. In that case, I have another example that could maybe give some context: Services like Netflix and subtitles (when the subtitle language is not English). I mean, at least for Finnish, the subtitles are often just crap. The reason is either using automated translations or not paying enough for professionals to do the translations.

Transcripts

Transcripts are a way for DeafBlind users to understand what's going on in videos or audio content (say, podcasts). Also, for audio-only content, transcripts are the only way for Deaf people to get the message.

If you're interested to learn more about captions, transcripts, and audio descriptions (which I'm not covering here), WebAIM: Captions, Transcripts, and Audio Descriptions is a good resource on that.

Action Item for Captions and Transcripts

Go through every piece of multimedia on your website. Are the captions and transcripts in place (depending on the media type)?

Wrapping Up

In this blog post, I have introduced seven checks any developer can do to ensure that their website is a bit more accessible. Some of them take more time than others, but they're worth it!

Do you have any tips for simple checks for accessibility problems that aren't easy to catch with automated tests?

Resources

Cover photo by Glenn Carstens-Peters on Unsplash

Why I'm Not One of the Guys

2023-01-03T08:57:49.014Z

Spanish translation by Ibidem: Por qué no soy “uno de los chicos”

"Hey, guys" is a phrase I often hear. It usually continues with words like "what do you think about this?" And if the context is within a mixed-gender group, I feel left out. I feel like they're talking to everyone else (or, at least, all who identify as a man) but me.

I know many native English speakers use the phrase as gender-neutral. But it is not, and in this blog post, I will discuss the problems of using that expression. I will also address some other aspects of the "man-default." One of the things it means is, for example, that if we are talking about a developer, that developer is often referred to as "he" (so, "A developer found a bug. He started fixing it").

This is a very personal topic for me, as I've had to fight for my spot as a developer, and I'm still facing these assumptions that I'm less of a professional because of my gender. So if you don't recognize the problem, please just believe me and don't start mansplaining how, for example, "you guys" is a gender-neutral term, and I should just suck it up. Please just don't.

The Problem of Man-Default

When you refer to a hypothetical person whose gender is unknown, what is the pronoun you use? If the answer is "he," then congrats, you've found the man-default. It means that you default to man when talking about someone whose gender you don't know.

Man-default can also be found in expressions such as "manning the station," "man-hours," or "chairman." It is visible in other languages as well. For example, in Finnish, despite having only one personal pronoun for all genders, we have words such as "lakimies" (=lawyer, literal translation would be "law man"), "palomies" (fireman), or "miehittää" (same as in "manning the station").

Another example of man-default comes from sports. Often men's league is referred to as "the league," and then there is the women's league with the word "women" in it. For example, we have the NBA (National Basketball Association) and WNBA (Women's National Basketball Association). It displays men as default and women as "other," something that needs an explanation.

But you know, the language we use shapes the reality around us. If we always speak about men doing something and especially default to men when talking about fields where men are the majority, we maintain those structures and keep the image up.

Ok, this might sound a bit abstract, but let me try to explain it a bit further: If we always refer to software developers as "he," we (unconsciously) build an image where all software developers are men. It leads to situations where men are seen as better developers, because hey, of course. And then women are seen as less of professionals because they aren't men who are the default. And this is how unconscious bias, which leads to discrimination, builds.

It is also a topic that has become visible with translation algorithms. Nicolas Kayser-Bril wrote a piece for Algorithm Watch about how Google Translate systematically changes the gender for translations when the initial gender doesn't fit the stereotypes.

There was also an interesting Twitter-thread about Google Translate and pronouns during the International Women's Day in 2021:

https://twitter.com/vuokko/status/1369185483683733505?s=20

These examples provide some fascinating insight into how language shapes reality. These translations are a direct consequence of the data used to train these algorithms. We, humans, are the same - if the data we get defaults always to, for example, men being the developers, we tend to believe that being a developer is meant only for men.

Guys is Not Gender Neutral

Back to the term "guys." Some argue that it is a gender-neutral term. Well, it is not. It originates from the word "guy," which is singular and means a man. Yes, I know, you might have learned it and been using it believing it is gender-neutral. That is ok - you didn't know. You are not a bad person. But could you please remember from now on that there are people who feel excluded when someone uses the word? Thank you!

Sara Bent from Hotjar writes about how they had a "Guys Jar"-challenge, a version of a swear jar. In their version, every time someone participating used the word 'guys' to refer to a group of mixed (or only-women) people, they had to pay.

I like how Sara puts the idea of using "guys" (from the blog post linked above):

Even though most people who use the term don't do so with the intent of it being sexist or exclusive of women, it can and often does cause women to feel left out of the conversation. Imagine you used 'gals' to refer to a room full of men and women—do you think the men would respond?

I've had and read many conversations with people (often with cis-men) about why they think "guys" is a gender-neutral term. One of the "best" arguments I've heard so far is that "we can't change the way soccer-moms in suburbs in the States use this term, so using it is ok for us as well." Well yeah, one thing is correct; we probably can't change that.

But you know, the conversation where they said this wasn't anywhere near those soccer moms - it was in Finland, in a professional context where English is the language used. And in a group where someone had just said they feel excluded when others use the word "guys" when referring to them. It was about the language used in the said setting. That felt... absurd.

Well, Why Don't I Just Speak Up?

I don't know about you, but when I'm in the minority, and I've seen that raising these issues sometimes gets even aggressive responses, it is hard to speak up.

Another thing that makes speaking up hard is that when I do, people usually assume I'm criticizing them, not their actions. These people tend to feel insulted, and you know how people are when they feel humiliated. The focus shifts to their feelings and me trying to tell them that no, I'm not assuming you're a terrible person. I'm only trying to bring to the attention things that you probably unconsciously are doing.

I've had good examples of when people have listened when I've brought this issue to attention. Still, more often, it ends up in an endless conversation about soccer moms and other non-relevant arguments. It gets tiring very soon.

And you know... It shouldn't be the responsibility of the minority to try to fix these issues alone. If it's something that has been brought up in a community before, the majority has the responsibility to act.

What Can I Use, Then?

So, you've decided to change your vocabulary. Thank you! I really appreciate that! You might be wondering what to use then. Here are some alternatives and considerations.

Alternatives for Guys

There are multiple alternatives you can use instead of "hey guys." Here are some examples with Kim Rees' tweet about some options:

https://twitter.com/krees/status/1106617681116045312?s=20

Using They Instead of He (or She for That Matter)

When talking about a person whose gender you don't know - wheater a real person, or a hypothetical person (such as a hypothetical developer), default to "they"-pronoun.

It might feel a bit weird at first, but I promise you, you'll get used to it. I speak from experience :)

Being Aware of Man-Default

One more thing I want to point out is being aware of the man-default. Start paying attention to the words you use; do they keep up the picture of a man being the default? Yes, it's a challenging task to do because we use language unconsciously and automatically. But you can try anyway.

There are usually gender-neutral words to use instead of the ones defaulting to man. Here are some examples:

Fireman -> Firefighter
Chairman -> Chairperson
Freshman -> First-year student

And so on. The internet is full of examples, so go and educate yourself!

Wrapping Up

So, TLDR; "Hey guys" is not a gender-neutral expression, and there are lots of people who feel excluded when someone uses it to refer to a group where they belong. I'm one of them.

There are better alternatives for the expression, and we should use them. Also, using "he" as a default pronoun is problematic, so let's use "they." And let's be aware of the fact that man is seen as a default in many places, so let's pay attention to the words we use.

You can find more examples of non-sexist language in Geek Feminism Wiki's guide on non-sexist language.

Cover photo by Etienne Girardet on Unsplash.

The Dark Side of Blogging

2023-01-03T08:57:48.447Z

Lately, I've seen multiple excellent posts about why developers should blog. They list very good reasons, and I wholeheartedly agree with them. Blogging is good for many things, it's fun, and you learn a lot during the process.

However, there are downsides to blogging as well, especially if you write about controversial topics. This blog post will discuss some of these downsides, tell my own experiences, and share tips on conquering those not-so-great things. I'm writing the tips for myself as advice I would have needed to hear, so they might not all apply to you, but I hope you'll get at least something out of this post!

Some Background

I started actively blogging about a year ago. My motivator was, at first, to write blog posts 16 weeks in a row to get the 16-weeks badge from Dev.to. I earned the badge, and if you're interested, I wrote a blog post about what I learned from that journey.

Blogging is something I like a lot. It has given me a way to construct my thoughts through writing and learn in the process. I already have a good archive of articles I've written. It hasn't been once or twice that I've had the opportunity to refer to one of my blog posts in a conversation.

However, as much I like this, there have been downsides as well. And during the past year, I've been struggling with stuff - as I would imagine most of us have because of Covid and all the isolation it causes. I'm also recovering from a brain injury, which makes me prone to fatigue. So these things have significantly slowed my speed of writing, especially in 2021.

So, let's have a look at the downsides and some advice!

Writing Quality Content Takes Time

If you want to write some quality content, it takes time. Suppose you're creating a tutorial of some sort, building the end result, testing it, and writing the blog post. It can take a long time from the start to publishing it.

In Dev, I've come across multiple posts that are basically just (short) lists of links. There is time and place for those lists, but at least I like to read longer posts with some actual content, and from the discussions I've seen in Dev, I'm not the only one. And writing longer posts takes more time.

Editing is another part of the writing process that requires time. Of course, it is possible to just write and then publish. But parts of writing quality content are editing, proofreading, and all those moments when you might need to delete half of your blog post and start over.

So, my advice for this would be to give yourself time. In life, all kinds of things can happen. It is okay if you don't write every week, especially if you're writing for yourself and not, for example, as a job. And when you do have time and energy, purposely book time for writing, editing, and all that.

The Pressure

You also might feel pressured to write and publish. For some, this is not an issue, but at least for me, it has been. When I was blogging for 16 weeks, publishing a blog post a week, I often felt pressure in the back of my mind.

Okay, it was me wanting to keep the streak going, and nobody else was asking me to do anything. Nevertheless, it really stressed me out sometimes. After the 16 weeks passed and I got my Dev-badge, the publishing pace slowed significantly down until, in the summer, I've published maybe a couple of posts. Well, depending on how you define "summer."

It's also possible that the pressure comes from outside; if you write for a company or a commissioned piece, then it's not just you anymore. There are deadlines, and someone else is depending on you.

As mentioned, there was no one else pressuring me on this, at least on purpose. I'm the one who makes me feel like I need to write. Sometimes I don't even know why; there is just that nagging feeling that I haven't published anything in ages.

There is another kind of pressure as well: writing about specific topics. I mean, my blog posts have been mostly about accessibility topics, but there have been some other themes as well. Still, sometimes I feel like I need to "stay in my lane." Now that I think of it, I've actually been told that when writing about equality-related topics. But I think there's richness in being able to explore different themes.

So what kind of advice would I give to combat the pressure of writing? First of all, be merciful and compassionate to yourself. No one's life is depending on your writing, and it is okay to take your time. And it is also okay to branch out and write about other topics as well. These might feel like a bit obvious pieces of advice, but at least I need to hear them once in a while.

Responses to Controversial Topics

As I mentioned, I've been mostly writing about accessibility and front-end development. Once in a while, I've thrown in some posts related to controversial topics. Good examples of these are language and being a woman in an industry where women haven't had space for a long time.

Recently I wrote about why I don't want to be referred to with the phrase "you guys." First, I shared it on LinkedIn, and the response I got was pretty much supportive, with a couple of not-so-supportive comments. I thought, okay, "let's publish this on Dev." I wasn't prepared for the flood of comments it received.

In the comments, there were some encouraging comments, and then some comments with good critique and conversation. But then the negative comments started coming, and I felt paralyzed. I wanted to answer the ones with encouragement and good commentary, but the negativity just drained me. So I want to apologize to anyone who was waiting for my answer and never got it! I had to draw a line to protect my mental health.

Some of the negative comments were clear trolls; some of them clearly tried, but it felt like they hadn't read anything more but the title of the blog post. And the mansplaining. Oh, the mansplaining! For those who are offended by the word, I do not mean that all opposing views were mansplaining. As said, some good comments challenged my points, and they definitely don't fall under the term mansplaining. But then again, some comments definitely were mansplaining.

As said, those comments drained me. I was contemplating removing the whole post from Dev, but in the end, two things kept me from deleting it. First was all the encouraging comments I received in the post, and the second was the support I got from the Dev's team (Thank you again, Michael, for reaching out! It meant a lot!).

So what I learned from this, and what tips could I give? First, suppose you write about controversial topics and receive a similar reception. In that case, it is totally okay not to answer the comments. You and your health come first. And it's okay to draw lines and keep them. You don't owe anything to anyone. This is especially true for people from a minority, as they tend to get more trolling and negative comments just because of their background.

Summing Up The Tips

So, to sum up, what I've been discussing, here are the tips from the previous sections:

Give yourself time.
Book time for the writing process.
Be merciful to yourself.
It's okay not to answer all comments.
Draw lines, and keep them.

Cover photo by Marco Bianchetti on Unsplash

Making Better Pull Requests

2023-01-03T08:57:48.048Z

Hactoberfest is here! Time to find those issues and participating repositories, write some code, and create pull requests! I've been eagerly waiting for October, mostly because of Hacktoberfest.

Last year, I participated in Hacktoberfest by being a contributor and a maintainer. If you're interested, you can read about my blog post about last year's experiences: Eevis Panula - Story of an accidental open source maintainer

This year, I decided to take it a bit easier. I mean, as mentioned in the blog post, last year we bought a house and were moving during October. Another challenging thing from last year was the maintainer part. I loved it, but it really, really stressed me out. So I'm not going to do it this year. And there's another piece to the puzzle this year as well: I'm switching jobs, so that's another reason to take it easy during this Hacktoberfest.

One big part of Hacktoberfest is creating pull requests. I remember the first time I made a PR in an open-source repository. I didn't know the repository's maintainers, and it didn't have any guidelines for pull requests, such as a pull request template. I had no idea what the maintainer expected from a PR. I felt super anxious.

If I had known back then what I know now, it would've been easier for me. So that's why in this blog post, I'm sharing some tips on how to make better PRs. These are the best practices I've picked up along the way. However, note that there might be some other conventions in the project you're contributing. Be sure to check them. There might be a pull request template or contribution guidelines.

The tips I'm going to give are the following:

Keep the Pull Request in Scope

One reason for keeping the PR in scope is that smaller PRs are always easier to review than those with lots of changes. Sometimes, of course, the feature you are working on is a big one, and thus the PR gets enormous. However, keeping in the scope in those cases means that if you find things to fix or improve, I would suggest creating a separate PR if they're not part of the feature.

Sometimes it would be good to separate the feature into smaller PRs. The scope gets smaller, and thus there will be less code to review. In these cases, I would advise splitting the PR into logical parts. For example, if you are building an app for period tracking, and the feature you're implementing is a calendar view where the user adds their data, there are multiple ways to split that.

Maybe the first part would be creating the endpoint to the backend and then adding a simple way to input the data with just input fields (so, no calendar yet). Maybe you could combine these all into a feature branch in the end.

Whatever you decide to do, be sure to check what the conventions are in the project you're working on. If you're working with a team, you can reach out and talk with them. There might also be a document about contributing, where there might be something about this topic.

Give Context to the Reviewer

When I'm reviewing a pull request, I love seeing some context about the changes. It might be a link to an issue (with more info than a vague title), or it might be a text explaining the context in the PR description. Anyway, having that context helps me get into reviewing mode and know what I'm reviewing.

Continuing from the example from the previous section, I would briefly write about the calendar view as a goal or link to the issue and then explain what I did in the pull request. I would also add some notes about the decision to split the feature and maybe some words about what's not yet included.

Add a Picture of the Changes

When the pull request is about changing something in the UI, I love seeing a picture of the changes. It's part of the context, and I know what to look for when I pull the branch and test it.

Continuing with the example, after moving on to making changes to the UI, I would add screenshots of those changes to the pull request. I might consider adding a before picture when finally implementing the calendar view to see how the feature evolves. That, however, would depend on the situation.

Pull Request is a Place for Discussion

One piece of advice I want to give here is that pull requests are places for discussion. It's ok to submit a pull request with questions (you could use a draft pull request in Github for that). On the other hand, you'll likely get questions and comments. Maybe even request to change something. When you do, and if they're not clear, it's always ok to ask for clarification or the reasons for change requests.

Why am I pointing this out? Well, at the beginning of my career, I felt like all the things said were God's truth, and I, as a newbie developer, didn't have any place to ask or question anything. That was even if the reviewers were friendly and tried to facilitate an atmosphere where that would've been ok. I would've needed to hear this advice many more times back then for it to sink in.

Summing Up

In this blog post, I've discussed pull requests and how to make them better. The advice is subjective, and it's based on my own experiences, and you might have other opinions. That's ok.

I pointed out that it would be good to keep the pull request in scope and try not to do everything in one pull request. If you want to make some additional changes, I'd suggest opening a separate PR for that. Also, in the pull request description, give context about the pull request for the reviewer. Additionally, if there are changes in the UI, I suggest adding a screenshot of those changes. The last thing I pointed out is that pull requests are places for discussion.

Links

Cover photo by ThisisEngineering RAEng on Unsplash

Thoughts From Reading Demystifying Disability by Emily Ladau

2023-01-03T08:57:47.277Z

I finished reading Demystifying Disability by Emily Ladau last week. It's a fantastic book discussing disability, ableism, accessibility, disability etiquette, and many more things. I highly recommend buying and reading or listening to it!

I have so many thoughts from reading the book, and I want to share some of them with you. And I know many more will come, as I often process new things over the course of a longer time.

Person-First Language vs. Identity-First Language

So, for those unfamiliar with the terms, person-first language (PFL) means using phrases where the person comes first. So, for example, people with disabilities. On the other hand, identity-first language (IFL) recognizes that disability is part of the person's identity, such as Autistic people.

Emily Ladau writes about her experiences with these approaches:

Truth to be told, I went kind of overboard with my IFL evangelism at first. I could not understand why anyone would prefer PFL and pushed against it whenever I had the chance.

I could say I was the opposite. At some point, it was difficult for me to understand why someone would like to go with the identity-first approach. Okay, I knew the reasons, but I could say I did not truly understand it. But now I do, and even better because of reading Demystifying Disability.

The book also got me thinking about why I've been feeling this way. For those of you who don't know, I had a concussion a few years back. I'm still recovering from it, and I know that things won't go back to what they were before that hit.

I was 26 when that happened, so I had a pretty strong sense of who I was before that. One thing was that I had an extraordinary memory. I could recall details so well that people around me found it strange sometimes.

And that was a big part of my identity. After the concussion, I realized I have problems with my memory, and I've had to come a long way to actually accept that this is my life now and I'm not the same person as I used to be back then.

But I'm guessing that this is one of the reasons I prefer to refer myself with the person-first language. I am still working with my identity because of the significant changes (memory is not the only one), and I assume I still will be for a long time. And that is okay.

As a final thought to this part, I want to remind you that it's a personal choice, and if someone prefers either one of these approaches, please do respect that.

Ableism

Okay, let's start again with some definitions. How Emily Ladau defines ableism:

Ableism is attitudes, actions, and circumstances that devalue people because they are disabled or perceived as having a disability.

Ableism is well-woven into our society, and we all echo these ableist biases and beliefs. And as with any type of systemic discrimination, it's hard to see if you're not part of the group that society discriminates.

I want to discuss two things related to ableism; systemic ableism and that people with disabilities can be ableist as well.

Systemic Ableism

Emily Ladau brings up the fact that ableism is a self-perpetuating cycle. I can fully agree with this and give an example from conversations I've had with people.

I often hear that the reason for not having accessible offices or using accessible apps and services in work environments is that "we don't have any people with disabilities working in our company." First, you wouldn't know, as people don't always want to disclose their disability statuses.

And then there's this: If your workplace is not accessible, how can a disabled person even come to an interview? If the applications or interviewing techniques you use for interviewing aren't accessible, how do you think you will be even able to hire someone who has barriers already before starting?

Again, Emily Ladau writes it well, saying that ableist assumptions lead to systemic ableism, which in turn leads to discrimination, despite being unintentional.

People with Disabilities Can Be Ableist Too

I love how Emily Ladau points out that there is "no magical force field preventing disabled people being ableist." That is so true. Being a person with a disability doesn't mean I couldn't be ableist as well.

Even though I'm an accessibility specialist and disabled person myself, I still catch myself having these ableist thoughts. And I've definitely done some ableist things. But the thing is, we all do. From now on, we need to recognize these thoughts and actions. We need to try to be better and apologize if it's possible in that situation.

Inspiration Porn

Emily Ladau defines inspiration porn with the following words:

[Inspiration porn] is an accurate way to describe the concept of how disabled people and their stories are objectified by the media to make observers feel warm and fuzzy or better about themselves.

Late Stella Young popularized this term, and below, you can find her TEDx talk "I'm not your inspiration, thank you very much." Here's also a link to the transcript of the talk.

https://www.youtube.com/watch?v=8K9Gg164Bsw

I think that talk is so on the point of the problems of inspiration porn. Why are disabled people seen as inspirational just because they get up in the morning and get on with their days? Would you say someone without a disability is inspirational because of that?

I often pass as a nondisabled person because my disability is invisible. And truth to be told, one reason for hiding it's that I'm a bit afraid that I would be seen as inspirational for doing something that anyone else would do despite having a disability.

In her axe-con-talk, Haben Girma speaks about using the word "inspired" in the sense that what you are inspired to do when someone is inspiring. That's totally something I can get on board with.

So, when we feel like someone is inspiring us, let's think about why that is. Is it because seeing someone with a disability makes us feel better about ourselves, in a way that we believe that we are better than them? Or does it make us work towards an accessible world for all?

Wrapping Up

I love Demystifying Disability and highly recommend it to everyone. It's an excellent overview of disability, ableism, accessibility, and many other themes.

In this blog post, I touched on only a couple of different themes in the book. As mentioned in the beginning, it gave me a lot to think about, and I believe there will be new realizations as I keep thinking about these themes.

First Month as an Accessibility Specialist at Oura

2023-01-03T08:57:46.082Z

So, I joined Oura Health in October, and it's been a little bit over a month now. My role is an accessibility specialist, and I'm the first person to be hired in the company in such a role.

During the past month, we've had busy times. We launched the new Gen3 ring, and it has brought a bustle. On the other hand, it's been super cool to join the company during such a time.

From an accessibility perspective, I know that we aren't there yet. We have a long road to go to change things, but one thing I'm excited about is that there is a will to do that.

In this blog post, I'll share some initial thoughts and feelings from the past month. I'm super thrilled about what is coming, and I'm feeling happy that I made this change.

I Don't Have to Sell Myself or Accessibility

One of the best things has been realizing that I don't need to sell myself to do accessibility-related work anymore. It has been given due to my role. It might sound obvious, but it is not for me.

You see, I've been in a position before where I've expressed that I want to do more accessibility-related work. I've been very vocal about that. In the end, I've still been the front-end dev first and foremost, who doesn't have time to look into making the results of my work accessible. If accessibility didn't take too much time, it was ok to think about, but there were never actual resources for that.

Those situations happened when I was working in a consultancy. I was sold as a front-end developer, and that was what the customer was paying for. They didn't have accessibility in their roadmaps, so they didn't want to spend money on that. And myself being a consultant, well, I cost money.

So I've been super happy that whenever I'm talking about changing things due to accessibility reasons, just saying that is enough. I don't have to justify to people how they benefit from it.

That means a lot. It has allowed me to use my skills and energy to actually do something without having to spend a long time selling the idea.

I'm Expected to Concentrate on Accessibility

Continuing from the previous point, I'm super happy that I can concentrate on accessibility. It's actually expected of me. I kind of knew that from day one, but after a couple of weeks, I had this moment when it really hit me. I'm not the front-end developer anymore, but the one who does accessibility.

That also means that I don't need to agree to complete something first, and then, if there is still time, I can look into accessibility-specific matters. No, I get to do it right away. That's expected of me.

One example is that right now, I'm doing an audit of one of our services. I even got my own epic to do that. And it feels good. Maybe you might think that hey, that's nothing special. Well, for me, it is. Coming from a situation where I didn't get to do what I wanted, this feels amazing.

I'm not alone

Another thing that's great at Oura is that I'm not alone in my accessibility mission. There are people across the company who understand the value of accessible services and that we need to do better. Yes, as mentioned, there's still a lot to do, but I feel that I'm not alone in this.

Heck, we even have this part in our values:

Humanity is present in all that we do—connecting with kindness and empathy. We build products and culture that celebrate and support uniqueness, inclusivity, and diversity, where everyone belongs. We meet people where they are, as they are, and prioritize accessibility.

I've had so many great conversations with people during the past weeks. And what has surprised me the most was that people were waiting for me to start. In multiple different conversations, I've heard that "Oh, I've been waiting for you to join! I have so many questions for you!" That feels just amazing.

Wrapping Up

So, as you might have guessed, I'm excited. There's certainly so much to do, but I get to work with talented people who care about their users. I believe that in the future, we can really say that our data is accessible, if not for all, then at least for a wider range of people.

Aria-Label is Not Always the Answer

2023-01-03T08:57:46.482Z

Okay, you've learned about accessibility and that there is sometimes a need to make, for example, the link text more descriptive for screen reader users. You've learned about the aria-label-attribute, and its powers. It's the answer to everything!

I'm afraid I have to say that it is not. It doesn't work with all HTML elements. In this blog post, I'll dig a bit deeper into the aria-label-attribute, and its usage and limitations, and options.

What Is `aria-label`?

So, let's first talk about the specification and where to use it. W3C Recommendation for Accessible Rich Internet Applications (WAI-ARIA)-document defines aria-label as "a string value that labels the current element." You can use it to provide a recognizable name of the object if there is no visible text on the screen that could be used as the label. If there was, aria-labelledby should be used.

The most important thing, and the reason I'm writing this article, is that developers should use it only with the following elements:

interactive elements (such as links, buttons, inputs et cetera)
Elements that have a landmark role
Elements that have an ARIA-widget role
img or iframe-elements

Source: Short note about aria-label, aria-labelledby and aria-describedby by Léonie Watson.

aria-label on these elements works consistently with assistive technologies. The support is inconsistent if you use it with any other tag, such as div or span. More about that in Aria-label and non-supported elements.

Let's look into each one of these elements a bit more.

Interactive Elements

Interactive elements are tags intended for user interaction. It means, for example, button, a (when href-attribute is present), input , details and others. The main idea is that users can interact with them.

Elements with Landmark Role

Elements can have landmark roles either implicitly or explicitly. Having an implicit role means that some of the HTML elements have roles set to them natively. The explicit role, on the other hand, is set with role-attribute.

I'll list the different roles and elements that already have those roles:

Landmark-roles with HTML-elements having those roles
Role	HTML-element
banner	(document) `<header>`
complementary	`<aside>`
contentinfo	(document) `<footer>`
form	<form> (if provided an accessible name via `aria-label` or `aria-labelledby`)
main	`<main>`
navigation	`<nav>`
region	`<section>`

Source: MDN's list of landmark roles

In addition to the roles listed, there's a search-role, which is only an explicit role, so, set with role-attribute.

ARIA-widget roles define typical interactive patterns. These patterns usually need JavaScript to implement their intended behavior. There are multiple ARIA-widget roles, and I'm going to list a couple of them:

tab
tablist
searchbox
treeitem
switch

You can find more from MDN's list of ARIA-widget roles.

`img` and `iframe`

Image and iframe are two elements where aria-label works as well. For img, there are rare cases when you might need aria-label. In general, you should use the alt-attribute to provide an accessible name for the image.

How does `aria-label` work?

aria-label overrides the visible text in elements, where the accessible name would come from the child element. For example:

<button aria-label="Something else">
  click me
</button>

The above button would be exposed as "Something else" to screen reader users.

`aria-label` and non-supported elements

So, as mentioned, the support for aria-label is inconsistent with, for example, div and span. If the div or span doesn't have any role, aria-label is ignored. The same goes for other non-interactive elements, such as p, ul, li, or legend as well.

If they have a landmark role, support is still inconsistent. Per Notes on ARIA Use in HTML, some widget roles work better than others:

Its fine to use aria-label or aria-labelledby on div elements with role=navigation, role=search, role=main, JAWS doesn't support them on role=banner, role=complementary, role=contentinfo. NVDA, VoiceOver, and Talkback are OK.

Options for `aria-label`

If aria-label is not the answer, then what is? Well, it depends. In general, I would recommend adding visible text. Usually, when you're adding text for screen-reader users, it would be helpful for sighted users as well.

However, if a non-visible text is needed, you could add visually hidden text with CSS. You can read more and find a CSS-snippet from The A11Y Project's article Hide Content.

Wrapping Up

aria-label is a helpful tool in cases when you need to add an accessible name for an element, and there is no already visible text to be used. However, you can't use it with every HTML tag. In general, those tags that don't work are non-interactive elements.

There are exceptions: If, for example, div has one of the roles listed above, then screen readers read it. But there are inconsistencies with some roles: for example, roles banner, complementary, and contentinfo are something that JAWS ignores, while VoiceOver, TalkBack, and NVDA support them.

I listed two options for cases when aria-label doesn't work. You could add a visible text, as it usually would be helpful for all users. Another option is to add visually hidden text.

How Not to Create a Button

2023-01-03T08:57:45.129Z

I have a habit of testing websites with a keyboard. I often encounter buttons that don't work as expected. It's frustrating, and I usually start digging into the source code to understand why the button isn't working. These reasons vary - some of them could be described as "normalized" patterns (I disagree), and some are really imaginative.

I'll share some ways to not create a button in this blog post. I'll also explain why those patterns aren't a good idea. You can find instructions on creating a button the right way in the last section, The Right Way to Create a Button.

Div as a Button

This div as a button pattern is by far the most common. Here's a code snippet to demonstrate it:

<div onClick="...">
  I pretend to be a button
</div>

Sometimes these elements even have tabindex="0" to make them focusable with a keyboard. But they never, ever seem to have the keyboard event listeners for space and enter. This means that even if the user can focus on the so-called button, they can't activate it with a keyboard.

Another thing that is often missing is the role attribute to communicate that there is a button. When it's missing, non-sighted screen reader users won't even know any button exists. For them, that particular element is a focusable text they might encounter if they're browsing the page's content.

So, while this pattern works for mouse users, it's excluding most of the other user groups out there. It's possible to make a div work as a button for all these groups, but it's lots of work and makes the code harder to maintain. And you know, by using the button element, you'd get all that for free.

Link as a Button

Another HTML element I often see used as a button is the anchor-element, so, link. In these cases, it's styled to look like a button. However, underneath it all, it's a link:

<a href="...">
  I, too, pretend to be a button
</a>

"But call to actions are a thing, right?" you might ask. Yeah, I know, they're a pattern that is widely used. And it's a bit confusing pattern - they often look like a button but then lead to another part of the website. And they don't initiate an action, such as opening a modal.

From the usage point of view, it doesn't make much difference for a sighted mouse user, whether it's a link or button under the hood. I mean, it works when clicking, be it a button or a link.

However, for non-mouse users, it does. For example, keyboard users have certain ways to interact with an element. They can activate a button with space and enter, and link only with enter. This means, that the so-called button is not actionable with space.

And why it is a problem? Well, have you ever pressed space on a site when it's not focused anywhere? It scrolls the page down. And that's what happens when you're focused on a link and press space. It's frustrating as user needs to scroll back up where they were. It might be even painful for some users in cases where every extra keystroke causes pain.

And then there's this: When users don't know that there is a link underneath the button, they don't have the control to use it as they would with a link. This means that they might, for example, want to open the link to a new tab or window.

Link with a Role of Button

<a role="button" tabindex="0" onClick={…}>
  I'm a link, I'm a button. Who am I?
</a>

This one is my new favorite. I mean, it's a creative way of making a button even more confusing for many. For screen reader users, it indeed seems like a button. It even works if they try to activate it with screen reader commands, as they trigger the click-handler. However, this type of button doesn't work with keyboard navigation.

Why, you ask? Isn't it a link, so it works with enter, right? The answer is no. That element is not a link because it no longer has the href-attribute. Removing the href-attribute strips away the semantics and keyboard interaction. This way, even the enter-key doesn't work with the element.

I think the most common reason for using this solution is libraries and frameworks hiding away the semantics of an element. My guess for this particular case is that there is some kind of CSS-in-JS-library in use, and the developer has needed the link's styles for a button. Then they have extended the link component and added all the attributes.

Button Element Wrapping a Link

Okay, the previous two examples are relatively common ones. The following two are (hopefully) not that popular.

First, I present to you a button element wrapping a link:

<button>
  <a href="...">
    I'm a link wrapped in a button. And I don't really work
  </a>
</button>

First, let's start with the fact that this is incorrect HTML. A link can't be inside a button, as the HTML specification defines the button's content model:

Phrasing content, but there must be no interactive content descendant and no descendant with the tabindex attribute specified.

The button-element in HTML-specification

Even though anchor-tag is phrasing content, it's also interactive, so this rules it out.

This pattern also does not work well for screen reader or keyboard users. Because the link is wrapped with a button, there's an extra tab stop before the user reaches the actual link. And as the button doesn't have a click-handler, trying to activate it doesn't do anything. So, the user feels like they're on a control, but it doesn't work, as the button still gets focused.

That is really frustrating and confusing for the user. If they try to go forward and tab to the link element and then press enter, they'll get the "button" to work. However, it is not clear that there is a next tab stop. And with the link, all the same problems presented in the previous section remain.

For screen reader users, it presents even more problems. I tested this pattern with VoiceOver and couldn't get it to work at all. I'm not sure about the other screen readers, but I'd guess they also have problems.

Checkbox Label as a Button

This pattern has been the wildest of them all. And at the same time, I understand how a developer has ended up with this pattern. So, in this case, we have a checkbox-input, which is visually hidden, and then the label is styled to look like a button. The code:

<label htmlFor="checkbox">
  I also want to be a button
</label>
<input 
  id="checkbox" 
  type="checkbox" 
  checked />

As mentioned, I understand how the developer ended up with this. There's this idea of changing something based on two states. The data that this particular checkbox represents can either be on or off. And based on that state, there are changes in the UI.

However, the checkbox serves another role in the UI. As Heydon Pickering mentions in Inclusive Components, users might suspect that they're also choosing a value for submission. This, however, is true only for screen reader users, as they hear that the underlying component is a checkbox.

The problem for sighted users is that as the label is styled to look like a button, they expect it's a button. But if they try to interact with it using a keyboard, it gets confusing. You see, the key that toggles a checkbox is space. So it doesn't work with enter at all.

So, after all these not-so-great ways of creating a button, let's look into making it the right way.

The Right Way to Create a Button

It's pretty simple. Use the <button>-element. It has everything out of the box: the role of a button to convey its semantics, tab index to put it into tab order, and easiness of giving it a click handler that handles the keyboard interaction as well.

<button onClick={...}>
  I am actual button
</button>

This helps your and your colleagues' lives, as the code is easier to maintain. Also, using semantic elements helps the users - not everyone uses a mouse, so having the expected keyboard interaction is required. You don't want to exclude anyone, right?

Year in Review - 2021 Edition

2023-01-03T08:57:44.768Z

It's that time of the year again: time to look back and summarize what has happened last year. And when I started listing different things, oh boy, what a year has it been!

This blog post will look into some of the highs and lows of 2021 in my life. I also checked what I've added to Polywork and made a collection of 2021 highlights. There are some additional things there, so if you want to have a look, here's the link:

2021 Highlights in Polywork

Let's dive in.

Blogging

So, I started blogging a little over a year ago. First, I was publishing my posts in Dev.to. In the fall, I finally put together my own blog, and since then, I've published the posts first there and then cross-posted to Dev.to.

In addition to that, I've published a couple of other blog posts, one in Mimmit Koodaa (a Finnish organization working towards equality in tech) and in my previous workplace's blog.

I want to mention a couple of my favorites:

Don't Develop Just for Yourself - A Developer's Checklist to Accessibility

Published at May 28

Read the post Don't Develop Just for Yourself - A Developer's Checklist to Accessibility

This blog post has been part of my talk with the same name, and I've shared it when speaking at conferences. I've also been able to use it at work; I've been constructing checklists for PR templates, and this blog post has been really helpful.

Why I'm Not One of the Guys

Published at Jul 24

Read the post Why I'm Not One of the Guys

This blog post has been one of the hardest to write and publish. When I cross-posted it to Dev, I got tons of comments - many telling me how wrong I am to feel excluded. Some of them were really rude, and I noticed I'm still reluctant to publish posts in Dev after that.

In addition to rude comments, I got supportive comments, and I am super happy about them. So thank you all who wrote them!

I guess one of the reasons I feel so bad after the comments is that this was the first time I faced this much hatred towards my opinions on the internet. And I'm sad to see that in the developer community, there are so many people who want to ignore the feelings of those in minorities.

Although this was the hardest to write and publish, I'm proud that I did it.

5 Things I've Learned as a Female Developer

Published at Jan 24

Read the post 5 Things I've Learned as a Female Developer

The points I list in this blog post are something I've come back to throughout the year. I've been either reminding myself about them or the others in different instances. The most important point has been that nobody knows everything. And yet, we often feel bad and talk ourselves down because we think we should know everything.

Oh, and one more accomplishment in blogging: I've started recording my blog posts. That means they will be available in both written and audio formats and thus serve more people.

Speaking

Last year I was also speaking a lot compared to the previous year. There was a total of 11 different events, plus some internal talks. Of these 11, seven were conferences, one was a vodcast, and the rest were meetups or other speaking engagements.

The talk for the year was definitely "Don't Develop Just for Yourself - A Developer's Checklist to Accessibility." I gave it in six events. I also talked about the theme of "Reduced motion" and equality in tech.

I'll list three of my favorite events and say a couple of words about them.

Euruko 2021

Euruko was so much fun! It was organized remotely, and they streamed some things from an actual studio. Most of the speakers gave their talks remotely, but I got to go to the studio to speak.

Even though we had some minor technical difficulties, the experience was incredible. I mean, I got to meet some real people Also the production was good.

However, the community was the key to making the event fantastic. Even though I don't use Ruby or Rails, I was already talking with someone that I was already telling people that I will mark Euruko 2022 in my calendar right away because of the community. So, see you then!

Mimmit Koodaa This is Not a Webinar

Okay, this is something I just need to mention. It was the event where I received the Mimmit Koodaa-award (more on that later). But that was not all - I also gave a talk at the event with my (former) colleague.

We spoke about the importance of role models and representation and how to encourage representatives of minorities to be those role models.

It was my first talk where I collaborated with somebody. As the Covid-situation did not let us practice in person (and the talk was streamed live from a studio, so we were at the same place), I was super nervous. But it went well!

And it actually led to an opportunity to be a guest in a radio program for the Finnish Broadcasting Company (YLE). So, I also made my first visit to the radio in 2021.

Inclusive Design 24

Speaking at Inclusive Design 24 was definitely one of the year's highlights. Even though I've decided my strategy in speaking about accessibility is to get to the conferences that are not about accessibility, ID24 was something I have dreamed of for some time. And when the email came that they accepted my talk, I was thrilled.

I spoke about reduced motion, a theme dear to me. The response was great, and I also got to meet one of my role models in the accessibility world, Sarah Higley, as she was hosting the session.

Also, the other talks were so good. I've been watching the recordings and got some ideas from them. For example, the talk about Auditorial gave me the idea to start recording my blog posts and adding a possibility to listen to them.

Accomplishments

When looking back last year, it's been a year of accomplishments. I'll name a few.

Mimmit Koodaa-award

First, Mimmit Koodaa-award. I was the first person in history to receive the award for my volunteering and my work for equality and breaking the IT industry's stereotypes. It's a great honor. One fantastic thing regarding the award was that my role model, former president of Finland Tarja Halonen, presented it. She has done so much for equality and has had a remarkable career. I highly recommend reading about her, if you haven't yet.

Finalist in Nordic Women in Tech Awards

Continuing with the awards theme, I was nominated and shortlisted to be a finalist in the Nordic Women in Tech Awards in the category Rising star of the year. That was an honor!

Naisten Linja

Naisten Linja works to help women and girls who have faced violence. I've been working to help build their website as a volunteer. That has been one of the most meaningful things for the last year. The work they do is super important.

Started at Oura

And finally, the one thing I'm super happy about is that I switched jobs from the consulting world to a product company to work as an accessibility specialist. If you want to read my initial thoughts about the first month, head to this blog post I wrote: First Month as an Accessibility Specialist at Oura.

Things You Probably Didn't See

I Got Tired

It was a challenging year. Not from the remote working perspective, no. That is actually something I enjoy. But there have been some other contributors that have led me to be on sickness leave.

It has been primarily work-related, which was one reason I switched jobs. Right now, I'm happy to be working in a role that I have control over, and I get to concentrate on accessibility.

Last spring was hard, and there were so many changes and uncertainties in the project I was working on. And this was even though the project team was fantastic! Many things worked smoothly, and we had good communication with the client. We had control over many things related to the project we were doing. People on the team - both from our and the client's side - were nice.

However, I was tired when the summer was approaching because of uncertainties and other things. To be honest, I was exhausted. And I realized that even though we had control over the project-related things, the uncertainties came from the corporation level, and no one in our team could do anything about it.

Maybe the best decision for the whole spring was to call the occupational health doctor and get sickness leave for the last two weeks before the holidays.

When the worst was over and I started to see more clearly, I realized that I needed change. Many of the problems that caused my condition were because I was working in a consultancy. So I sent an application to the one company I had often said that I would apply to when I wanted to switch away from consulting. I could say that the rest is history. Or some other cliché.

Exploring the Nature

I am one of those who picked up a new outdoor hobby in 2020. I learned kayaking in a local club, and I could say that was one of the best decisions ever. I've seen so many incredible, beautiful places that you can only reach by water.. And I've continued learning this year, and my next goal is to pass Euro Padel Pass level 2.

Another thing I've picked up in the last two years has been hiking. I've visited some Finnish national parks and can only repeat that Finnish nature is stunning. And nights in a hammock, away from all the rush and negativity on the internet, that is just amazing.

To give some numbers from this theme, I visited 11 out of 41 Finnish national parks last year. I plan to visit all of them at some point, but as I live in the south and many are in Lapland, it will take some time to accomplish.

So, What's Next?

I don't want to set anything in stone. These past years have shown that anything can change in an instant, and so can my plans. However, there are some themes I'd love to see being part of my life this year.

Cognitive Accessibility

This year, I want to learn more about cognitive accessibility. I think I have a basic knowledge about it, but I want to go deeper.

This goal is related to so many things - work, studies (technical communications), and personal life. I want to understand it better and to be able to help people around me to create content that is more accessible for everyone, and especially for those who need cognitive accessibility.

Accessibility Content in Finnish

I've noticed that writing (and speaking) about accessibility is more natural for me in English. My approach to content creation around accessibility has been about the content I needed - and one thing I want to improve is that I create content in Finnish as well. That's something I totally would have needed when I started learning about coding and accessibility.

So, I have some ideas for content creation in Finnish in 2022. However, I will not stress myself out about it.

Spend More Time Outdoors

As mentioned in the previous section, I've picked up some covid-safe hobbies such as kayaking and hiking. I want to continue with those and spend some more time outdoors in 2022. I also want to spend more nights outside in my hammock, preferably after a day of kayaking in different places. And when there is no water around, hiking is okay too.

So, to conclude this post, I want to wish you a happy New Year, may it be better than the previous ones!

How I Created Neule.art

2023-01-03T08:57:31.343Z

I'm a knitter. It's one way of expressing my creativity and also passing the time. And it's sometimes super relaxing. And I (and people around me) get to wear some nice, warm, self-made garments.

One ongoing project is that I'm knitting some Riddari-sweaters as presents to some of my close ones when they turn 30. Usually, I've just decided on the colors myself, but this time I wanted to ask from the recipient for their color choice.

So, I could have tried to find some pictures of the sweater in potential colors. But there was a chance that I couldn't find those. And it takes some imagination to try to think how some colors play together if you only see a picture of the yarn ball and the sweater in random color. Trust me; I've bought some new yarn in the middle of making a sweater because what I was knitting was not what I had imagined.

I needed a way of visualizing the colors somehow. And thus, the idea for my next project was born. In this blog post, I'll introduce you to Neule.art, a color picker or color visualizer for the Riddari sweater (among other patterns), and how I created it.

If you're interested in the code, you can find it from the Neule.art repository. The code is nowhere perfect, and I know I could polish it a lot, but my goal has been just to get it out and then, maybe at some point, improve the code quality.

The Planning and Decisions

So, I began pondering how to create this site or app. I instantly started thinking about using SVGs for the visualization, as you can manipulate the colors of an SVG pretty straightforwardly.

Another thing to decide on was the technologies. What should I use? React? NextJS? Something else? I wanted to build a page with the least possible amount of JavaScript, so I decided to go with Eleventy. That's a framework I've used before, and my website, for example, is built on Eleventy.

I'm a bit bored with JavaScript and wanted to try if I could build the site without any client-side JS. As Eleventy is a static site generator, this is possible. Even though I use JS for development, the result can be without JavaScript - if I want it that way. But how can the site manage changing colors? Eleventy Serverless and HTML forms to the rescue.

Let's talk next about how I implemented the different components mentioned above.

Getting the SVG

SVG was a great idea, but there was a problem: there were no SVGs for the Riddari-sweater I knew of. First, I thought about drawing the sweater. It sounded like a great plan - until I remembered that I'm not much of an artist. So no drawing.

After spending some time on the internet, I came across image tracing. That sounded like a plan, and after finally purchasing Procreate on my iPad and playing around a bit, I started tracing the shirt. It looked awesome.

It was just that there was no SVG export from the Procreate app. What do? Well, the thing I do best: search for answers. After some time, I had installed Inkscape, and after trial and error, I finally had the shirt in SVG, where it was possible to manipulate colors by CSS.

Building with Eleventy

Building the site could have been a tricky part. Fortunately, I had experience with Eleventy, specifically with serverless functions and Eleventy.

I also wanted to use HTML to its total capacity - in this case, it means using forms and form actions. I also didn't want to use JS on the site unless it was absolutely necessary. And spoiler alert: I didn't have any client-side JS in the first version of the site. Okay, I use Eleventy (which is, indeed, a JavaScript library) for building the site, but everything works with HTML in the production site.

At the time of writing, I'm building some progressive enhancements to change the colors dynamically without reloading the page. However, I will still keep in mind those who don't want to or can't have JavaScript enabled in the browser.

But back to the process. I started building the site.

First, I created a static site, showing the SVG of the shirt with default values. Then I added the Eleventy Serverless plugin and dynamic path to the site displaying the SVG. This way, I could pass the four colors for the shirt as a query parameter.

Using the Native HTML Form

Once I had done that, adding the form was the next step. If you're unfamiliar with HTML native forms, they work so that when you hit "send" (or whatever the primary action is), they send the values from the form as an object to the URL you've defined in the action-attribute. And if you use the "get"-method, you get the values as query parameters - which is perfect for what I was doing.

So, here's a code snippet I'm using in the project (I edited it and stripped away all Nunjucks-syntax I use for passing the data for clarity):

<form method="get" action="/en/colors/" class="colors-form">
  <label for="color-a">A (Main color):</label>
  <select id="color-a" name="a">
    <option value="0059" selected>Black (0059)</option>
    <option value="9423">Lagoon (9423)</option>
    <!-- More color options -->
  </select>
 <!-- More color selects -->
  <button type="submit">Check the result</button>
</form>

Getting the Data For Yarn Availability

Another thing I wanted to add to the site was a possibility to see if some selected stores had specific colorways available of the Lèttlopi-yarn (which knitters often use for Icelandic sweaters). And by "selected," I mean stores I either knew have Léttlopi on stock or were easily found on Google.

As I had this approach of not using client-side JavaScript, I needed to store the data in some way Eleventy could utilize it. Also, I didn't want to scrape the sites every time users visited my page. After some consideration, I wrote a function that runs once a day at night and scrapes the available colors from the selected yarn stores' sites.

I use Github actions and cron job for running the function. It scrapes through the yarn pages in the stores, parses the data to JSON, and then saves the new values into a data file. Then the site gets rebuilt, using the updated data for yarn availability.

Writing the scraper was fun. I used cheerio to get and find the relevant data from the document on the yarn stores' websites. Then I parsed it with JavaScript to JSON. The fun in this was that every site has its way of annotating available yarn. Every store was a new puzzle to solve so that I get the relevant piece of information - which colors of the yarn were available and which were not.

If you go and check the getColors.js-file, you can see that I've been using different techniques for different stores. Sometimes it used an id, sometimes Regex, sometimes splitting the string from specific places, and sometimes looking for a class name.

When I had the yarn data available, I just needed to use it. And then, I had all the pieces together and had the MVP (minimum viable product) ready for publishing.

Publishing

As I had decided to use serverless functions, and as Eleventy has instructions only for Netlify, it was pretty straightforward to use Netlify to host the site. Also, Netlify itself is relatively straightforward, so setting it up was fast - and the fact that I've used Netlify for many things in the past helped in that.

But the most challenging part of publishing the site was to buy the domain - or, rather, decide the domain name for the site. After pondering (and reading the list of possible top-level domains) for some time, it hit me. "Neule.art!" It's perfect. "Neule" means knit garment in Finnish, and hey, knitting is art. Also, from the beginning, I had plans to add other patterns than Riddari to the site, so I didn't want to use Riddari for the domain name.

I bought the domain, spent some time figuring out all the DNS stuff, and finally, the site was live! I was so happy. You know, it's not always obvious that one gets their side project published. I've started so many projects I've never finished, so it feels good to complete something finally. And that it is something I feel proud of and can share.

I shared the site with some of my friends, and their response was encouraging. So, I decided to share the project on LinkedIn. Suddenly, it got so many comments and likes, and someone shared it on Facebook's Icelandic sweater/yarn-related groups. On the first day, I got a couple of thousands of visits (it's a lot for me and a niche page).

What was super encouraging were the comments and feedback people shared with me. I was solving a problem for myself - and solved it for many others at the same time. It feels great to be able to help.

What I've Added After the Launch

I launched the site in mid-May. I've been working to improve it since then. I've added a possibility to generate random colors, added a version of the Riddari-sweater where users can change color for every motif (instead of the original pattern's four colors), and added a new yarn store (Lanka-Kaisa).

I've also done a lot of under-the-hood fixes and features, such as adding cypress tests, fixing bugs, and improving the SEO of the website.

The Future

I have plans to add more patterns and yarns to the site. Also, as mentioned, I'm working on improving the user experience by providing the possibility to change colors dynamically.

Also, I'm happy to hear ideas and feature requests to the site - you can either contact me (hello@eevis.codes) or send a feature request through Github.

Links in the Blog Post

How Can Backend Developers Improve Accessibility?

2023-01-03T08:57:43.114Z

This question might feel a bit strange. Backend developers often touch the UI less, so they don't need to care, right? I beg to differ. This blog post will look at some practices backend developers can do to ensure the accessibility of the end product and documentation.

We'll look into API structure, documentation, performance aspects, and backend rendered pages. This is in no way an exhaustive list of things, and there is definitely more backend devs can do, but let's start with these four.

API structure

There is actually a huge opportunity to improve accessibility when building APIs. This opportunity comes from reusable structures and ensuring that the content requires accessible roles, names, states, or properties. Also, APIs can enforce requiring things like having captions and transcripts for videos and audio content.

One concrete example of API supporting accessibility is images. When uploading an image, the API should require an alternative text or information that the image is decorative. So, when validating the sent input, there should be a check for having the alt-text (for example, as a separate parameter). And if the image is purely decorative, and thus the alt-text is not needed, then, for example, a boolean value indicating that.

Localization is another thing that helps with accessibility. Enabling people to use products in their native language can make barriers smaller. When designing an API, developers should consider localization and how that API can support it. I know there are cases where another service handles localization, or it's handled in the front end, but it's rarely only about the texts on the site. Often values stored in the database should be localizable too.

Documentation

Another aspect where backend developers can help with accessibility is the documentation. There are two sides to this: The site or platform, and the content.

Platform or Site

First of all, the site where the documentation is should be accessible. So, for example, the site uses semantic HTML, is keyboard navigable, has colors that have enough color contrast, and has a logical and clear structure. You can read more about web accessibility from Web Accessibility Initiative.

Many projects use readymade solutions to render documentation. Whether it's a Swagger-type documentation containing only endpoints and inputs, or a more extensive platform with text, it's not usually built from scratch. So, it's essential to check that the platform actually is accessible.

You can use automated testing tools and also do some manual checks. These blogposts contain resources for development, but there are tools and assessments you can do for any site.

I'm in the process of doing some quick accessibility tests for different documentation tools, and I will write a blog post about the results. So stay tuned!

Content

Another important thing is that the actual language in the documentation is accessible. You can use some of the principles of plain language. Let's look at what this means in practice.

If the documentation has longer text blocks, try to follow these instructions:

When you address the reader, use "you," not passive.
Avoid complex sentences and unnecessary words.
Write the most important information first.
Write short sentences and paragraphs.

Also, if the documentation has images, remember to add alternative texts explaining the image's message. If the picture is purely decorative, add alt="" to it. Here's more about alternative texts to images.

If you add videos to the documentation, add captions and a transcript for the video. Many people tend to watch videos without a sound on, so it serves all. The Deaf, Hard of Hearing, and Deafblind depend on the captions and transcripts to know what's happening in the video. Here's a resource where you can learn more about captions.

Also, it's good to pay attention to the structure of the content. Use headings correctly, meaning when you have a title, annotate it as such. Also, use correct heading levels. I just found a good tool for content creators to check some accessibility aspects, and I think it would work with documentation as well. The tool is called Sa11y. Go and check it out!

Performance

Another aspect to consider is performance. It is essential that the frontend does as few heavy calculations as possible. Not everyone has the latest devices with lots of memory and calculation power.

I know some people argue that this doesn't really matter. But it actually does. It matters for the user. If many things are happening in the front end, the user's internet is slow, and they have an older device, this might mean that nothing happens for them for a long time. That, in turn, means the site doesn't work for them.

If the site is something they can leave, they probably will. But what if they still need to use the site? Let's say it's the only way to book an appointment with a doctor, which they desperately need. If the site is slow and unresponsive, they might start trying to click things to see if it works. And when it finally starts working, all those things happen - and they find themselves in a totally wrong place. That's frustrating. But it can also be a huge barrier. Many don't just have the bandwidth needed to fight these non-working sites.

I want to remind you that many disabled people live in poverty. For example, in the United States, about 26% of disabled people lived in poverty in 2019. (Source: Disability Statistics.) They might not have the newest iPhone or the most high-performance computers.

And even if you don't live in poverty, it doesn't mean you'll always have the newest and most performant devices. I think this is often a bias we developers have - "Works on my computer" is so much more than being unable to reproduce a bug. It's also a privilege because we have our macbook pros and the newest phones to work with, and we build apps that work with them.

Backend-rendered pages

Another factor for the backend developers and accessibility is backend-rendered pages. They need to be accessible, too, like any client-side rendered pages.

Okay, I know; frontend developers handle the back-end-rendered pages in many cases. But there are always some times when backend devs need to create small pages. Those pages need to be accessible too.

So, even if you're a backend developer, I'd suggest looking into web accessibility and learning the basics. If you need to choose one topic to start with, I'd say semantic HTML. Not everything is a <div> - many other elements communicate meaning to assistive technology and work better. From there, I'd suggest continuing with keyboard navigation and other ways users use their devices - not everyone uses a mouse.

Wrapping Up

So, in this blog post, I've been discussing ways backend developers can improve accessibility. There are four points I've been talking about: API structure, API documentation, performance, and backend rendered pages.

These are not the only ways a backend developer can (and why they should) contribute to accessibility. Do you have some ways in mind? I'd love to hear your thoughts!

On the Edge of Burnout... Again

2023-01-03T08:57:41.542Z

I've been super tired during the spring. Again. I could write a blog post about how disappointed I am that I've let myself into this situation - again. But this blog post is not about it. It's about how I got further away from that edge and started finding myself - and the spark - again.

So, to give some context: About eight months ago, I wrote a blog post about my first month as an accessibility specialist at Oura. At that point, I was still in the honeymoon phase, and the realities of being the first-ever accessibility specialist in the company weren't apparent.

You see, being the first in any role, especially in a role whose goal is purely to change existing things, is not easy. If there are any miscommunications about the position, it makes it even harder. And if you don't know what's expected of you, well, that's certainly a risk for burnout.

I should have known better - hey, I've been here before, and I know I'm more at risk because of my brain injury than someone else without the same history.

I realized I'd lost my spark. Not just for the work but also for anything outside the job. I used to love sharing what I've learned, but writing and submitting proposals for conferences didn't feel good. I thought, "What's the point? Nothing's going to change anyway".

Now that I'm in a better position, I'm a bit sad because I missed some conference applying deadlines I had been waiting for for a long time. For example, I didn't submit a proposal to Inclusive Design 24 - I just didn't have the energy.

I'm better now

I'm better now. But it took some time, conversations, and challenging moments before I could be honest about the situation. And again, I could use the word "again." I've been here before.

I tried to raise the problems throughout the spring. I think it was a short sickness leave that made the people at the company understand that this is pretty serious.

After that, we had multiple conversations about my role. I understood some miscommunications about my position. I had a pretty different idea of the role than it actually was.

Understanding what was expected of me and the whole situation better helped me. Furthermore, having some time off out in the sea helped. (I spent time sailing and kayaking. Finnish nature is amazing.)

I also read two blog posts that made me think a lot about my relationship with accessibility. I'll share my thoughts about them next.

Progress over perfection

Working in a company, which is not very mature when it comes to accessibility, needs a specific type of attitude. Even though I knew that I couldn't (or can't) change everything instantly, I think I still had this idea of being able to change some visible things and doing it fast. And that was definitely a contributor to me being on the edge of burnout.

And I felt (and still feel) like I have responsibility. I'm the company's first (and the only) accessibility specialist, so I think I should be able to do something visible. To change something. Like how we don't add alternative texts to tweets, even the most important ones.

Meryl Evans has been talking about progress over perfection - and in her blog post, "Accessibility: Why You Need to Work Toward Progress Over Perfection", she writes:

Accessibility isn't all or nothing. It's progress, not perfection.

I try to remember that. I try to find those good things, things that we do right. For example, we have some outstanding professionals who contribute to accessibility from their positions - for instance, Janne Käki, who does a fantastic job with iOS development. And that definitely is progress.

Regaining my accessibility spark

As mentioned earlier in the blog post, I felt like I had lost my (accessibility) spark. Everything felt more or less pointless. I felt that whatever I do, someone always tells me, "No, accessibility doesn't matter." Ok, usually, the words were not that direct. And it wasn't just about work - it was also outside it.

I read Sheri Bryne-Haber's blog post "Regaining your accessibility spark". Initially, I thought it had some good advice. I didn't act on it. But I kept coming back to that post.

Some things on the list have helped me a lot this time. I needed to remind myself of the "why": why I do what I do.

I also needed (and still need) to remind myself about the progress, about the (little) things I've accomplished. Like the audit on our website and how the bug fixes from that audit are moving forward - they're not just visible yet.

And I sought help. I've had this incredible occupational psychologist with whom I've been talking about the work and how to improve it. To discuss with someone, to go through things with someone outside of the situation (but who knows the circumstances), has helped me tremendously.

Now that the situation is better, I have focused on things other than work. Sheri Bryne-Haber suggests things like finding accessibility mentoring/volunteering gigs, writing a blog or a book, or learning a new language, gaining a new hobby, or investing more in a hobby you already have.

And now that I think of it... I've done all three. I'm doing some volunteering. I've also been writing to my blog more (and I might have some ideas about the book part, too) and investing more in hobbies I already have - knitting and kayaking. As for investing, lately I've spent much more money on them than I have been for a while. But also time!

Wrapping Up

So, I've been on the edge of burnout - again. In this blog post, I shared how I got further away from that edge and how I've been finding my accessibility spark again. It's been a journey, and that journey continues.

Do you have similar experiences? Did you lose your spark and regain it?

My Advice to a Developer New to Accessibility

2023-01-03T08:57:41.203Z

Learning about accessibility for the first time can feel overwhelming. You start reading, and at some point, it hits you: There is so much to learn! And if you're like me and feel that it's your responsibility to make the things you create accessible, that might even make you feel anxious.

And yes, there is a lot to learn regarding accessibility. But you don't need to know everything at once. As Meryl Evans reminds us in her tweet (and a blog post the tweet links to), it's about progress over perfection:

https://twitter.com/merylkevans/status/1547635550466674692

So, here are some things I wish I had known when I first started learning accessibility. Heck, I wish I had known these things when I started learning web development! I'll share semantic HTML, keyboard navigation, and listening to people with disabilities.

Learn Semantic HTML and Use It

So, first thing: Learn semantic HTML. But what does it mean? Semantic HTML, or semantic markup, describes its meaning to the browser and developer in a human- and machine-readable way. So, with semantic elements, a human will know what the HTML element is about, and the browser knows what it should render and how it should behave when a user interacts with it.

Here's an example:

<button onClick={...}>I'm an honest button</button>

That button uses a semantic button-element. When it does so, the browser knows what it should do when the user either clicks or activates it with a keyboard or other input device. Here's an example of a non-semantic "button":

<div className="button" onClick={...}>
    I look like a button
</div>

So, this "button" made out of div looks like a button and even has the onClick-handler. So, wouldn't a human recognize it as a button? Well, yes and no. It depends on the human.

You see, this "button" works only for mouse users. As div is not an interactive element by nature, it doesn't handle interaction the same way as, for example, a button-element. When using a semantic button-element, that onClick-event propagates such that it handles keyboard interaction as well. However, divs don't do such a thing.

Another reason a non-mouse user will recognize that it's not a button is that you can't focus on it. That means the button is not in the focus/tab order. And that, in turn, means that a non-mouse user can't interact with it.

There are lots of semantic elements in the HTML. For some reason, we tend to use a div for many things. Did you know, for example, that you can annotate addresses with an address-element? Or wrap dates or times with the time-element? Or display progress with a progress-element? MDN lists HTML elements, so be sure to check that list.

If you want to read about other benefits of using semantic HTML, I wrote a blog post "Ode to Semantic HTML" a while back.

Another piece of advice I want to give is something we touched on in the previous section: Learn about keyboard navigation.

Now you might wonder, "Why would anyone use keyboard to navigate?". Well, first of all: not everyone can use a mouse, or they just don't want to. Sometimes doing tasks on a computer is way faster with, for example, a keyboard.

There are lots of different ways of using digital devices. Some people use a tool called a screen reader, which reads the screen's contents out loud. Some use a keyboard for navigation because they can't use a mouse. And some people utilize assistive tools like mouth sticks, custom keyboards, switch devices, and other tools to use digital devices. And let's not forget voice interfaces or eye-tracking technologies, which some people use.

So the point is that there are multiple other ways to interact with a digital device than just a mouse. And we, as developers, need to create interfaces that work for all of our users and not exclude anyone.

Now you might feel overwhelmed. "How can I create websites for all those needs?" Well, I have good news: You don't need to think about each different input method. Many of the input methods mentioned above emulate what a plain ol' keyboard does.

My suggestion is: first, learn how keyboard navigation should work on a website. After you've learned that, it's time to learn about the specifics of other input methods.

Let's talk a bit more about keyboard interaction. There are two things I urge you to learn and exercise: Keyboard navigation patterns and how to test them (and regularly do so).

So, how does keyboard navigation work? When users want to go forward, they press the Tab-key, and this takes (or should take, depending on how well the website has been coded) them to the next interactive element. That means a link, button, input field, or similar - and not, for example, a heading.

When keyboard users want to read something or to navigate forward on a site without interactive elements, they scroll with arrow keys. I want to emphasize that because I see a lot of websites where a developer has added tabIndex-attribute to non-interactive elements so keyboard users could navigate forward.

It's a great thing that a developer thinks about keyboard users. This pattern, however, increases the amount of the tab stops to reach the actual interactive elements. For some, it's frustrating, but for some, it can even be painful if, for example, each keypress causes pain.

Okay, back to patterns. When a keyboard user wants to navigate to the previous interactive element, they use Shift + Tab.

There are different patterns for activating interactive elements. I'll list a few of them:

<button>: activates with Enter or Space
<a>: activates with Enter
<input type="checkbox" />: toggles with Space
<input type="radio" />: Tab in (and out) the radio input group, arrow-keys to change the value.

As you can see, buttons and links are activated with different keys. Specifically, the spacebar key doesn't activate a link. This distinction between the elements is good to remember - when users see something like a button, they think it works as a button. If the underlying component is a link, it doesn't activate with Space but rather scrolls down on the page. That's super frustrating.

You can find the expected keyboard navigation patterns for more complex user interface element patterns from WAI-ARIA Authoring practices.

Testing with Keyboard

When you build user interfaces, be sure to test with a keyboard. The basic method is to navigate through the whole site using the keyboard. When you encounter an interactive element, try to trigger it. Check that it works as expected - meaning that you can do everything with a keyboard that you can with a mouse.

Oh, and one note if you're using Mac and Safari. You need to enable keyboard navigation for them - I don't know why, but it doesn't work out of the box. Here are instructions for enabling keyboard navigation for Mac and Safari.

Listen to People with Disabilities

The final advice I will give in this blog post is to listen to disabled people. This advice consists of two things: Listening and learning about their (our) life in general and listening to the feedback we/they give.

I'll share some resources I've found helpful and informative. There's plenty more out there on the internet, and if you think something should be included, I definitely want to know about them!

One of the good places to go for these stories is Twitter. There are a couple of hashtags I recommend following: - #ActuallyAutistic - #EverydayAbleism - #DisabilityPrideMonth

I'd love to add some more here, so if you know some other good hashtags, let me know.

Also, a good resource for experiences and expectations of disabled people is Nicolas Steenhouts' A11y Rules Soundbite-podcast series. These short discussions with disabled people give a lot of good points of view for designing and building the web.

I also want to mention a brilliant book from Emily Ladau: Demystifying Disability. I actually wrote some thoughts from it once I had read it, so check that blog post too: "Thoughts From Reading Demystifying Disability by Emily Ladau"

Another great resource is Disability Visibility-project. It's defined on the About-page with the following words:

The Disability Visibility Project is an online community dedicated to creating, sharing, and amplifying disability media and culture.

Do you have some other resources? Or other advice an accessibility-novice developer should know about?

Links in the Blog Post

Don't Set outline: 0 or outline: none for Focus-Styles

2023-01-03T08:57:40.850Z

"The focus indicator is ugly, and I will remove it. No, this is not up for discussion." These are some lines from a conversation with a designer-developer some years back. The theme of the conversation was a website they were working with.

I tried to explain the problem with non-existing focus styles. Still, they insisted their view of beauty was more important than the customer's right to a working website.

And this has not been the only conversation I've had around focus styles. Some people want, stubbornly, to remove all focus styles because they (as a mouse user) don't like those focus rings.

In this blog post, I'll share why these visible focus styles are so important - and why you should never set outline-property to 0 or none for focus styles. But let's first talk about the property itself.

What is `outline`?

outline is a CSS property, or actually, a CSS shorthand property. That means that you can set multiple properties with it. These properties are outline-color, outline-style, and outline-width. You can set one, two, or three attributes simultaneously. Here's an example:

.className {
  outline: 2px solid red;
}

In this example, the outline is set to be a solid red line, which is 2px wide.

In the box model, outline is set outside the box's border edge and does not add to the element's size, meaning it doesn't take any space from the page layout.

You can modify the looks of the outline with two more properties: outline-offset, which affects how far from the border of an element the outline is, and border-radius, which modifies the radius of the border. It affects the whole element, not just outline.

`outline` and Focus

The default styles for focus indicators are implemented with the outline-property. Every browser has its own default styles for this focus indicator.

These default styles are defined with user agent stylesheets. Jens Oliver Meier has written more about them, if you're interested: "User Agent Style Sheets: Basics and Samples".

Here are examples of default focus indicators for Chrome, Firefox, and Safari, as seen on Mac:

Chrome:

Firefox:

Safari:

The examples are from the Finnish Broadcasting Company's (Yle) website. I've disabled the author styles with the Web Developer extension.

As you might notice from the examples, these styles aren't apparent in most conditions. The default focus indicator styles do pass WCAG criteria about visible focus. Still, I think accessibility shouldn't be just about passing the success criteria. It should be about inclusion, and thus creating more visible focus styles is a must.

Why Visible Focus Styles Are Important?

So, why having visible focus styles is so important? It's because not everyone uses a mouse. Many people prefer or need to use tools like keyboards, switch devices, or others to navigate the page. And when they do so, they don't have the cursor of a mouse to tell them where they are on the page - they rely on focus styles.

So, to put it short - not having visible focus styles is like using a website with a mouse, but the cursor is invisible.

But What If I Have Better Focus Styles?

The outline completely disappears when you set outline to none or 0. Now you might ask, "But what if I have better focus styles? Why can't I remove the outline then?"

The problem is that it removes the outline from everywhere - also, from, for example, Windows High Contrast Mode (WHCM) users. WHCM works by removing the background colors and images and replacing text color (and some other colors) with the selected theme's colors. That affects things like box-shadow - it's not visible at all. And that, in turn, means that most of the enhanced focus styles won't appear.

"So, I'm stuck with a visible outline, then?" I have good news: No, you're not! You can actually use the transparent-keyword like this:

.some-element:focus {
  outline: 1px solid transparent;
}

That will show up in WHCM as it forces the colors on existing outlines and will be transparent in other cases. And also, because the outline doesn't take up space on the boxes, the transparent outline will be invisible in other cases.

Wrapping Up

So, the gist of this blog post is: never set outline-property to 0 or none for focus styles, use the transparent-keyword for the color in these cases. And if you do this, remember to add (more) visible focus styles via the chosen alternative method.

Notes of a Web Developer Learning Kotlin and Android Development - part 1

2023-01-03T08:57:39.902Z

First, a bit of background: I'm an accessibility specialist who recently started digging deeper into our company's Android application. When auditing a web page, it's easy for me to provide technical guidance on how to fix accessibility issues. However, native mobile development and accessibility have been a mystery to me. Now that I've started evaluating our native apps, I've realized I need to understand more from the technical side.

Okay, I have to admit that I'm not a complete newbie in Android development. When I was learning to code about 6-7 years ago, one of the learning paths I was following was Android development. I was working through Google's Android courses in Udacity back then but never finished them.

At the time, the language for Android development was Java, and I've never felt too comfortable with it. I ended up working as a web developer (one of the other learning paths I was taking) and have been able to avoid Java ever since. Fortunately, today Java is more in the background, and Kotlin seems to be the hot thing, so I decided to learn it with Android development.

In this and upcoming blog posts, I will share thoughts, learnings, and reflections from learning Kotlin and Android development. My initial plan is to work through the Android Basics in Kotlin and, after that, learn more about Android accessibility specifically.

Let's start with the first unit (Kotlin Basics). It is about the basics of Kotlin and Android - adding text and images and creating a simple, interactive interface.

First Impressions from Kotlin

I admit I've been a bit prejudiced towards Kotlin because many people have been selling it to me with the idea that it's like "better Java." I've never particularly liked Java.

However, now that I started learning Kotlin, I'm feeling like... Wow, why haven't I tried this before? For me, it resembles Python a bit. I can't exactly pinpoint why, but I get this same soft feeling when coding in Python.

Okay, I do just some dabbling with Python for fun, and I'm rarely working with it, but I really like it. So I can wholeheartedly say that the first impressions from Kotlin were positive.

I know that part of feeling like this is because I've been coding for a long time now, and I've learned at least the basics of many languages. I know JS, TS, Python, Java, Clojure, and Ruby, to name a few. And learning new (programming) languages gets easier after every new language.

Let's look at some concrete learnings and findings from Kotlin from the first unit. I collected the topics from the first unit and did some extra reading to understand some differences and concepts.

Variable Names

The first thing to learn with a new language is usually variables and what's their syntax. I collected three keywords from the first unit to define variables: val, var, and const.

val: val is used to define read-only, local variables.
var: var is used to define mutable variables.
const: const is used to define immutable values (the same as "val"). The difference is that these variables are known at compile time. An example from the course: TAG was used to define the component name when using Logger, and was set to MainActivity.

Another important keyword is fun, which defines functions. An example:

fun petACat() {
  // ...
}

That is straightforward, as JavaScript has a similar syntax with the function-keyword. I just need to remember the different naming.

Some Nice Methods and Data Types

The course went through some interesting and useful data types (range) and methods (random, when-statement, and repeat). I know that most, or all, are present in the other languages I mentioned learning. However, I'm working primarily with JavaScript, so that's what I'm comparing Kotlin to within my mind.

Ranges and Random-Method

One of the apps created on the course was a dice-throwing app. The functionality is simple: a user clicks a button, and the app shows a random number between 1 and 6.

To accomplish this, the code uses a range to create a set of possible values (as the values are in a range between 1 and 6). And that range (IntRange) has a method called random, which, as you would guess, returns a random number that is on that range.

It's so much more straightforward than in JavaScript. I like it a lot. Here's an example:

val range = 1..6
val randomNum = range.random()

When - Statement

Another cool method and/or statement is the when-syntax. I like the way you can, for example, define values with fewer lines of code with it:

val knitGauge10Cm = when(getYarnWeight()) {
      "Lace" -> "32-34 sts"
      "Fingering" -> "28 sts"
      "Sport" -> "24-26 sts"
      "DK" -> "22 sts"
      "Worsted" -> "20 sts"
      "Aran" -> "18 sts"
      "Bulky" -> "14-15 sts"
      else -> "Unknown"
 }

In the example above, when defines a gauge for 10 cm (or 4 inches) for a knit based on yarn weight. When knitting a garment, it is crucial to know how many stitches there are in a certain width of the knit to match the intended size. So if I had an app helping to calculate the gauge for different types of yarns, this example code would be helpful.

If you're interested in reading more about knitting and gauges, check out Knit Picks' guide about gauge.

Repeat - Method

The third method I want to mention is the repeat-method. It's so convinient to have a method for repeating something x times. In JavaScript, you naturally can do this - but it takes more lines of code. With Kotlin, you can do that with one function:

fun meow(times: Int) {
  repeat(times) {
    println("Meow")
  }  
}

Getting Back to Android Development

As mentioned at the beginning of the post, I was learning about Android Development years ago. Because of that, it was relatively easy to jump back to the world of Android Studio and other things. And as the first unit concentrates on fundamental things, it felt familiar and easy.

However, I recognized some things I need to practice in the upcoming units. For example, it was difficult to understand the whole ConstraintLayout-concept, and which constraint points to where. I think I will need to think and draw some kind of comparison to CSS layouts to understand the differences.

The next unit will be about layouts, so I'd imagine that will get easier. Also, I'll learn about user input.

Wrapping Up

In this blog post, I shared my initial feelings and thoughts from learning about Kotlin and Android development. It's been fun (pun intended), and I'm looking forward to the following units.

In the next blog post, I will cover the second unit, "Layouts." From the Kotlin side, it consists of things like lists, and from the Android side, different layouts and ScrollView.

Have you learned native (Android) development lately? What have your experiences been? Or do you have any tips for a web developer learning about Android development?

Results of Quick Testing of Documentation Tools' Accessibility

2023-01-03T08:57:42.398Z

When writing my blog post about what backend devs can do for accessibility, I did some quick accessibility tests for different documentation tools. Initially, I thought I'd write about the results in that blog post, but there was just too much to report. So, I ended up writing this blog post.

I chose four tools that I know many projects are using. These tools are:

Swagger
Read the Docs
Docusaurus
GitBook

First, I ran an automated test with the aXe browser extension and dug deeper into the DOM based on the test results. After that, I tested the site with a keyboard.

In this blog post, I'll share the test results and some thoughts about them. As you can see from the steps described above, the testing was not exhaustive. I just wanted to get an overview of the issues. I did not, for example, test with a screen reader or with narrower viewports (or zooming).

This was a conscious decision, partly because I didn't have time and partly because this blog post would've been super long. And I think this already provides some overview of the state of accessibility of these tools.

Let's get started.

Swagger

URL used for testing: https://petstore3.swagger.io/

Swagger is a set of tools used for API documentation. The Swagger API project started in 2011. Initially, it was a specification, but it was later named OpenAPI Specification. So it has a long history, and many projects use it.

One of its tools is Swagger UI, a user interface for browsing the API endpoints. That's the one I'm testing for this blog post.

Testing Swagger UI with Axe

Runnin Axe-browser extension showed 64 issues, two of which are critical, 35 serious, 18 moderate, and 7 minor. Most of the issues (37) were related to color contrast issues. The contrast ratio for the problematic color combinations ranged between 2.03 and 3.75.

Another problem was form input without programmatically associated labels. Some of them were flagged, but when I started digging deeper into the site's code, I noticed that not every instance was flagged. So, there were more problems with form labels than Axe was showing.

The third problem I want to raise is the lack of landmark regions. Not having these regions means that user, who needs these landmark regions for navigating, can't use them. For example, screen reader users and keyboard users who use tools to navigate using landmark regions would need to either listen to a lot more items and/or press a tab many more times to be able to navigate to certain parts of the website.

Testing Swagger UI with Keyboard

The next test was how well I could navigate Swagger UI with a keyboard. From this quick testing, it seems that Swagger UI is working somewhat ok with a keyboard. I could reach every element and interact with them.

Read the Docs

URL used for testing: https://docs.readthedocs.io/en/stable/tutorial/index.html

Read the Docs is an open-source documentation platform that was created in 2010. On their website, they say they host over 800 000 open source projects and support over 100 000 users.

Testing Read the Docs with Axe

Running Axe-browser extension showed 206 issues, 6 critical, 132 serious, and 3 moderate. For Read the Docs, too, the color contrast was the most significant cause of problems. The contrast ratio for the problematic color combinations ranged between 2.36 and 4.19.

Read the Docs uses ARIA-attributes - but not correctly. For example, some headings are annotated as headings with ARIA but without the level of the heading. Here's an example code from the site:

<p class="caption" role="heading">
  <span class="caption-text">First steps</span>
</p>

Another problem this automated testing revealed is a scrollable area, which is not keyboard accessible. In this case, it's a code-block visualizing warning messages. Lines are longer than the code block, adding horizontal scrolling to the element. And when a user, who uses a keyboard, comes to that particular element and wants to see what's at the end of the line (hidden by scrolling), they can't because that area is not keyboard accessible.

Read the Docs is also missing landmarks, so the same problems as for Swagger UI are present.

Testing Read the Docs with Keyboard

The search field is one of the first focusable items when navigating the page. When the user focuses on it, a modal opens. The "Close"-"button" is actually made of a div without a possibility to focus on it. Fortunately pressing Esc closes the modal.

When the modal is visible, the focus is set to the modal's first focusable element - the search bar. However, the focus is not trapped inside the modal, it's only moved there, and the modal is the last item on the DOM. The user can still reach the underlying links and other focusable elements if they navigate backward (which is definitely not optimal).

After closing the search modal, the focus is not managed. At least on my tests on Mac, Chrome, and Firefox, if I close the modal and then press Tab, the focus ends up in the first tab of my browser.

Combined with the on-focus behavior of the modal, this creates a sort of focus trap - the user can't reach the rest of the page by tabbing forward. Yes, they can do that by navigating backward with Shift and Tab, but that's problematic. And if the user can survive without the information on the page, they probably leave instead of trying to find all the ways they could navigate the site.

Another thing I wanted to mention from the keyboard navigation point of view is that there's no "Skip to content"-link. If the user somehow gets past the search modal, they need to tab through all of the links in the left side panel to reach the main content. On the example page, that means a lot of links to tab through.

Docusaurus

URLs used for testing:

https://docusaurus.io/docs and https://docusaurus.io/docs/styling-layout for automated testing
https://docusaurus.io/docs/styling-layout for other tests

Docusaurus is a static site generator created with React. On the Introduction page, they say that

It provides out-of-the-box documentation features but can be used to create any kind of site (personal website, product, blog, marketing landing pages, etc.).

The team behind the Docusaurus is from Meta, as it's one of its Open Source projects.

I'm testing with Docusaurus version 2. At the time of testing, it was still in beta. However, now it's published. I chose two pages to test so that I'd get a bit more components to experiment with.

Testing Docusaurus with Axe

Testing Docusaurus with Axe revealed 51 issues on the "Styling and Layout" page and 15 on the "Introduction"-page. From the first, 8 were "Needs review", 1 critical, 41 serious, and 1 moderate. On the "Introduction" page, 14 needed review, and 1 was moderate.

Most of the issues are about color contrast - on the "Styling and Layout"-page, 46 of the issues were about that. And some of the problems were because of examples of failing color contrast, so that's expected. Others were mostly from the code snippets' styles.

Other problems consisted of missing labels on a color input and non-unique landmarks.

Testing Docusaurus with Keyboard

Most of the problems I encountered when testing Docusaurus with the keyboard were related to focus management. For example, when I opened the search modal and left it without typing anything on the search field, the focus was not managed and ended up at the beginning of the page.

Another possible problem (although not a WCAG violation) is that Docusaurus uses the browser's default focus styles. In some cases, the focus is hard to see, especially if the theme of the documents is close to the default focus indicator's color.

One thing I noticed is the menu's dropdown-pattern Docusaurus uses. You can navigate the items on the dropdowns with Tab, but that's not the correct pattern for dropdowns in the menubar. Per ARIA Authoring Practices, the correct pattern would be that navigation happens with up and down arrows, and Tab gets you to the next widget.

I also found good things: Docusaurus has a "Skip to main content" link. It works - this is not always the case with skip-to-content links. Another nice thing is that the color picker in the "Styling and layout"-page works with a keyboard.

GitBook

URL used for testing: https://docs.gitbook.com/editing-content/rich-content/with-command-palette

GitBook is a documentation platform with lots of different features. It started as a simple open-source tool and grew into what it is today. It's free for open-source projects and priced for everyone else.

Testing GitBook with Axe

When I ran aXe on GitBook, there were 237 issues, from which 27 needed review, 2 were critical, 65 serious, and 143 moderate.

There were many color contrast issues (61), and the non-passing elements had contrast ratios between 2,53 and 4.48. Also, there were problems with HTML semantics; aria-labels on divs, lists with incorrect markup, and lang-attribute missing.

It also had missing landmarks and some missing alt-texts. And it had zooming disabled; this means that if someone needs to zoom in to see better, they can't. It's a terrible practice, making the site unusable for some users.

Testing GitBook with Keyboard

Continuing with the theme "Unusable for some users", GitBook doesn't have a focus indicator for most elements, so it's frustrating to try navigating with a keyboard. Because of that, I couldn't test the site much with a keyboard.

Final Thoughts

In this blog post, I've shared results from quick tests I've made on four documentation tools: Swagger UI, Read the Docs, Docusaurus, and GitBook. Each has accessibility problems, but I would definitely pick Docusaurus for documentation from these four.

After testing all the tools, I researched how they have reacted to accessibility. I wanted to know if they have accessibility statements on their pages, how they track accessibility issues, etc.

Research on Swagger led me to Github. Swagger tracks the accessibility issues with a cat: a11y-tag, but there seems to have been no activity this year. Search with "accessibility" on Swagger's site did not find anything, so I'm assuming they don't have any statements.

Read the Docs has no policies or statements on accessibility. They have some Github issues when searching for accessibility in the theme's repository. Read the Docs has a theming system, so in theory, the user can fix some of the problems found with the search. And with "some", I mean the ones related to styles (so, color, for example). If I've understood correctly, these themes are about styles, not the underlying HTML.

In Docusaurus' introduction, they say that Docusaurus has "attention to accessibility, making your site equally accessible to all users." They also track accessibility issues with the domain: a11y-tag in Github. However, I couldn't find any separate accessibility statement for Docusaurus.

Last, Gitbook mentions accessibility only in "Space customisation"'s "Primary color" section, where there is a mention about accessibility being important when selecting colors. When searching for accessibility and Gitbook, I found a couple of pages using Gitbook and writing about accessibility. That's a bit ironic - as the Gitbook itself is not that accessible.

What's your favorite documentation tool? Have you thought about or tested its accessibility?

Notes of a Web Developer Learning Kotlin and Android Development - part 2

2023-01-03T08:57:39.139Z

This blog post is the second in a series of posts about me working through the Android Basics on Kotlin-course. You can find the first one here: Notes of a Web Developer Learning Kotlin and Android Development - part 1

The second unit of the course, "Android Basics in Kotlin," is about Layouts. It also goes through some Kotlin-concepts, such as lists and with-syntax. From the Android side, the most significant theme is layouts, particularly adapters.

Kotlin: Lists and Other Things

Lists

There are different list types in Kotlin. Lists can be either mutable or immutable - you need to decide which one when defining the list. That's different from JavaScript: Even though you define them as constant in JS, you can still add and remove things. In Kotlin, you need to have a mutable list to do that.

Lists are defined with the following syntaxes:

val immutableList = listOf("list", "of", "words")
val mutableList = mutableListOf("other", "words")

Printing these would result in

[list, of, words]

and

[other, words]

You can get the first item from a list with method first() and the last item with method last(). Sorting a list happens with the sorted()-method, and you can reverse a list with reversed().

Mutable lists have a set of additional methods to mutate the list; here are some examples:

add(): Add an item to the list.
addAll(): Add a collection to the list. More about other collection types in the next part.
remove(): Remove an item from the list.
clear(): Clear the list.
isEmpty(): Check if the list is empty.

Again, here's plenty more than what you'll have with JavaScript. I mean, you can do all of these with JS, but you need to write more code for that, and it's not as verbose. Let's take a look at checking if a list is empty. With Kotlin, it would be:

// Kotlin

val list = listOf(...)
val isListEmpty = list.isEmpty()

And with JavaScript:

// JavaScript

const list = [...]
const isListEmpty = list.length === 0
// or
const isListEmptyShorter = !list.length

A final thing about the lists in this post is looping through them. The material mentions two methods - while and for-loops.

while-loops go on, as long its condition is satisfied. It first checks the condition and executes the body if it's true.

while (x < 10) {
    // Do something
    ++x
}

For-loops iterates through the collection provided. So, for example, looping through the range of numbers could look like this:

for (i in 1..6) {
   // Do something with the current number
}

`with`

with-syntax is nice when working with, for example, a specific class instance, and there's a need to access more than one of its properties and functions.

So, for example:

with(cat) {
    println("Cat's name is ${name}")
    println("It often sleeps in ${favoritePlace}")
    meow()
}

I could access these properties with cat.name or cat.meow(), but I need to write less code this way.

Android: Let's Talk About Adapters

Adapters are the most significant learning in this unit - or refresher, as I recall some distant things about them. They work as, you guessed, adapters between views and underlying data.

The adapter is a design pattern. It adapts the data and transforms it into something the client can use. In the course, the example is about RecyclerView, and how the data is adapted to it.

When introducing the adapters, the app being built is a list of affirmations. RecyclerView is suitable for this project as it's a good component for creating dynamic lists efficiently.

The course explains how an adapter works with RecyclerView in the app with the following words:

When you run the app, RecyclerView uses the adapter to figure out how to display your data on screen. RecyclerView asks the adapter to create a new list item view for the first data item in your list. Once it has the view, it asks the adapter to provide the data to draw the item. This process repeats until the RecyclerView doesn't need any more views to fill the screen. If only 3 list item views fit on the screen at once, the RecyclerView only asks the adapter to prepare those 3 list item views (instead of all 10 list item views).

In the app, the adapter has multiple parts. First, a layout is created for an individual list item. The next step is to create an ItemAdapter-class, which takes in a list of affirmations, and context-object instance.

After that, an ItemViewHolder is created inside the ItemAdapter. It represents a single list item view in the RecyclerView and can be reused. That view holder is the one that handles updating and showing data.

The adapter needs to implement three methods: onCreateViewHolder, getItemCount and onBindViewHolder.

The layout manager calls onCreateViewHolder to create new view holders for the RecyclerView, if there are no existing view holders that it could reuse.

getItemCount is for, as the name suggests, getting the item count for the list data. The layout manager calls onBindViewHolder to replace the contents of a list item view.

There's one more step: Once the adapter is created, RecyclerView needs to know about it. In the course project, MainActivity is the place to do that. To be more specific, in the onCreate-method of that activity.

I've had a hard time wrapping my head around the pattern. However, I think it's partly because it's a new, complex thing, and to be honest, it's been a while since the last last time I did object-oriented programming.

So I need to keep practicing - this concept among all the others. Luckily, from what I've understood, this is something I'll need many times when learning more about Android development.

Wrapping Up

There were many things to learn in unit 2 of the Android Basics in Kotlin-course. I know I will return to these topics in the following units - and definitely when I start creating something of my own.

The next unit is about navigation, and that's an interesting one. I've already started it, and there's so much to know! I'm so excited about these new concepts I'm learning. As there is so much material and new things in the Navigation unit, I might split it into two posts. We'll see.

Have you been learning Kotlin or Android development? Have any tips or thoughts?

Learnings From Creating a Guest Book App

2023-01-03T08:57:38.780Z

So it seems my sister is currently my biggest muse for side projects. She was the reason I created Neule.art, from which you can read more in the blog post "How I created Neule.art".

A while back, she asked me if I could create a guest book app for a party they had with their friends. The idea was simple - there should be a possibility to add a photo, some text, and the name(s) of the sender(s). They tried to search for a readymade app, but every one of them had some problems.

I also know, from experience, that these kinds of apps can be... how to put this... Not so good usability-wise. For example, no one wants to download an app for one night to be able to take one or two pictures. No one wants to create an account for that one night (and then forget that they have it).

So I wanted to try out if I could build a simple enough, non-account-needing web app. In this blog post, I won't share the code for that app. It was a bit hacky, as the app needed to work only for that one night. Aaand I was a bit in a hurry. However, I will share some learnings from creating that app. Let's first have a look at what the app was like.

The Guest Book App

The guest book app consisted of two pages: Login, which had this one input field for writing the password, and a page for guest book entries. In addition, there was a modal for adding a new entry. That had a form with the possibility of taking a photo (a file-type input field with accept="image/*" to open the camera) and adding names and a message.

As for the tech stack, I used NextJS with TypeScript, GraphQL, and GraphCMS (at the time, they changed their name just after I finished the project to Hygraph) for CMS. As for the photos, I stored them in an AWS S3 bucket and their URL to the CMS.

I've worked with all the other technologies before, but AWS was something new. However, I was pretty sure that because it's a fairly common use case to store things in AWS S3 buckets, and as React is so popular, there must be an easy solution for uploading files to S3 buckets from React apps. Turns out there is - but it wasn't that easy to upload the photos. That leads us to the first lesson learned.

There's Always a Typo Somewhere

As mentioned, this was my first time working with AWS. But I've heard the stories (mainly about someone forgetting to turn off something and getting an astronomical bill when they realize it the following day) - and I was prepared for problems.

I followed some tutorials on setting up an AWS S3 bucket, and to my surprise, that was easy. The problems started when I tried to upload the photo to the bucket. I tried a couple of packages and had CORS issues I couldn't solve.

I didn't understand why, and I was already ready to quit software development after spending a couple of days banging my head on the wall because of this issue. But I finally solved it.

The cause? Typo in the bucket name in the code.

Netlify, NextJS Images, and Orientation

Another issue I had (way more minor than the CORS issues) was with the NextJS Image component and Netlify. I had planned to use Netlify for hosting, and I was almost finished. I deployed the app and sent it for testing.

It turned out that Netlify removed the EXIF data from the images for some reason. Some of the photos were weirdly rotated. I found some discussions where (if I remember correctly) the team confirmed that this is what can happen. While writing this blog post, I searched for the issues/forum posts/anything I've read, but I couldn't find anything. So I can't back this up.

I would have loved to solve this problem in some elegant way. However, at that point, I didn't have too much time to finish the app. So I decided to use Vercel for hosting - NextJS images worked well with it as it's the company behind NextJS.

Simple Things Go a Long Way

Sometimes, we need to remind ourselves that simple things go a long way. When we build apps and sites, it doesn't always have to be something super complicated and have a multitude of features.

As I mentioned initially, this app aimed to be as simple as possible. It was an answer to my (and others') frustrations with the available guest book apps that either required app installation or an account (or both). And it delivered what it was supposed to: People could leave guest book entries for the hosts.

I'm not saying this app was distribution-ready, but it would have been a good starting point had I had time to make it more configurable. Or to open source it, because right now, the codebase looks like I hacked it together in a couple of days. That's precisely what I did.

I try to remind my mentees and anyone seeking my advice that it's better to have a simple app completed than a bigger one in progress when applying for jobs. The simple app can always have improvements and next steps, but I try to stress that it's good to have the MVP finished.

Stepping Out From the Tech Bubble Does You Good

The fourth thing I want to talk about is that if you usually spend time with developers (like I do), try sometimes showing your projects to someone outside that bubble. It can really boost your confidence.

When I went to the party and spoke with one of the hosts, it helped me to remember that what I can do is a lot. If I'm showing my projects to anyone who knows about coding, I think a lot about what could be better and the improvements. Case in point: I don't want to share the code with you, my reader.

Another person who I can rely upon to remind me about these points is my sister. I love her enthusiasm when I show her something I've coded. It's been like that ever since I started to learn to code, and I appreciate her for that

Wrapping Up

It was fun to create a project for someone's use. Even though there were some problems to solve, I'm proud of myself. I'm proud that I made this app, and it was usable. I'm also proud that I solved those problems.

Do you have any apps/sites in progress? Or have you finished something lately?

Hey Tech Recruiter, Here Are Some Tips from a Developer

2023-01-03T08:57:36.505Z

I wrote a rant to LinkedIn in the summer, summarizing a couple of tips on how (not) to contact me and similar stuff. Since then, I've been thinking about writing a blog post about this topic, and here it finally is!

I've had good experiences with tech recruiters over the past years, but unfortunately, there have also been bad experiences. And this blog post comes from those occasions.

Here's the original rant:

Dear tech recruiter, here are a couple of things I'd wish from you.

✨ Please don't call me. Even though you can find my number somewhere, it's not an open invitation to call. I hate speaking on the phone, so you calling me unsolicitedly makes me anxious. And I don't want to work for your company or your client if you make me anxious.

✨ Please don't call me many times. You know, the seventh call within three days is just too much. (The first one was too, but… seventh. C'moon.)

✨ If you say you're a tech recruiter, you really should know the difference between frontend, backend, and devops. And you should look at my profile at least just enough to know I'm a frontend developer - and not contact me with backend / devops-positions.

✨ Oh, and a tip: Java and JavaScript are different languages. Me having JavaScript on my profile does not mean I have extensive knowledge on Java.

✨ I won't answer "Hey I have this mysterious client you would be lucky to work for"-type of messages. Sorry, I know you always can't disclose the client, but I want to know where I'm getting into if I take a call with someone.

And a ✨Bonus Tip✨: Oh, and if your company's/your client's website has these fancy animations/auto-playing things that make me literally sick I don't want to work for you or your client. I know I'm an accessibility specialist who could come and fix these things, but from the messages I've received, you're not looking for that. You're looking for a backend developer. So… no.

Yes, it's been one of those weeks.

Source: LinkedIn

These tips are written from my perspective, and someone might disagree with them. But from what I've discussed with several other developers, they have agreed with me on these tips.

If you find yourself or your company from these examples, I don't assume you're doing it because you want to be evil or something like that. I don't think you're a terrible person because of that. I just wanted to say that. And now we can get to the tips.

Don't Call Me

Really, unless we have agreed in a conversation (which was in written form) that it's okay that you call me, don't. I don't like speaking with people I don't know on the phone. Also, due to some issues related to memory, I'd rather have everything written than try to remember details like who that person was, what the company was, etc.

And definitely don't call me multiple times. I won't answer you. I use search engines to find the number, and after I see that the number belongs to a potential recruiter, I write "Don't answer" as a note to it. And you know, seven calls within three work days is just way too much.

Know The Basics of Tech

If you're a tech recruiter, you should know the basics of tech. I don't mean that you should learn how to code - even though it is fun! No, you should know the difference between frontend, backend, DevOps, mobile, and other similar concepts. You should also have a basic understanding of programming languages at a level that you know that Java is different from JavaScript.

I get these messages fairly often that say, "Hey! We are/our client is looking for someone with extensive knowledge on Java to work with backend." Did you check what my LinkedIn profile says about my skills? I mean, it talks about frontend technologies, accessibility, and JavaScript. Not Java. There's no Java anywhere.

And I know that that is a tactic just to send many messages out there and hope someone answers. However, for every message I receive that's like that, I add the recruiter and company to my mental list. I don't want to work with companies that don't have a basic understanding of tech because it already tells me a lot about the culture.

Give Me All the Details

I receive many "I have this mysterious client in this and that sector looking for someone"-messages. Sometimes I might even bother answering and say that I'm not interested in starting a recruitment process with a company I know very little about.

And I understand that it's not always possible to reveal the name of the company, but I'd like to question the whole concept - why it needs to be like that? Having as much information as possible is best for both parties.

Knowing what I'm getting into (even if it's only the first interview or a call with a recruiter) is essential. It's a stressful situation, and if I go in without almost any information, I can't prepare. And I don't like that feeling. I need time to process my answers, and if I don't have any time to think about them before the interview, I will fail, and it's a waste of time for both parties.

Be Honest About the Process

Over the years, I've had several experiences where I agreed to have a meeting to "get to know each other and casually chat." And when that meeting started, the first question was something like, "Why do you want to work at this company?" Like, hey, I don't know if I want to! I'm here to find it out!

And don't get me even started on surprise technical interviews. If the information about the meeting is that we'll casually talk about technical topics, a live coding exercise is not okay. And neither is being a dick about not doing that exercise. (Okay, that was not a recruiter.)

The information and agenda of the meetings need to be known beforehand. I need to prepare for them, and if the agenda is something other than what was agreed upon, I can't prepare. And I feel shitty about that. And if I feel shitty... I probably don't want to work at that company. I am just saying.

Do What You've Promised - And Communicate If You Can't

When a tech recruiter says they'll contact me at a certain time, I assume they'll do that. But I can't even count the times when I've been told that a company would get back to me at a certain date, and there was nothing. Just silence. And when I asked about that, they either ghosted me or treated me as if I should be thankful that they even answered.

It's okay if some things take time. Sometimes people deciding about the next steps are unavailable, and that's life. Sending a short message like "Hey, I know we promised to get back to you today, but I am sorry, [insert reason for the delay], and we'll get back to you [insert new timeline]." shouldn't be too much effort.

And yes, things happen. And it's okay - if you communicate about it. Sending that short message mentioned in the previous paragraph shows respect toward the candidate.

Treat Juniors and People From Minorities in Tech with Respect

I know we are in an era where everyone wants a senior developer, and there are just not enough of us. And there's the fact that white men are often seen as more competent than others. But if you only treat the ones you would like to hire now with respect and not, e.g., ghost them, it will bite you back.

You know, those juniors will be seniors one day. And those people coming from minorities in tech are as competent as, well, white men. And as the tech scene is small, we also often tell about our experiences to others - seniors as well.

I have many examples where my being treated poorly led to someone more senior than me refusing even an interview with a company because of my experiences. And as I've become more senior, I've also refused to interview because of those experiences.

For many, this is a no-brainer. But from my experience, there are a lot of companies and/or recruiters who don't get that.

Check Your Website's Accessibility

On Global Accessibility Awareness Day 2021, I got a call from a recruiter. They told me from which company they were, and I opened their website. I was on my computer and had a large screen with a browser in full-screen mode, so everything was big on the site. It contained some pretty wild animations, which triggered my symptoms. I felt very disoriented and tried to get away from the call (I'm too nice to hang up).

I tried to keep it together just enough to explain what had happened - and honestly, I have no idea if I succeeded. After the call, I needed to lie down for over 30 minutes, and I couldn't continue working for a while.

That is my reality with all those fancy parallax scrollings and other effects. I need to be extra careful when going to a new site. And I'm not alone.

Also, there are lots of disabled people who you might want to hire. But if your company's website is not accessible, they either encounter similar things as I do, or they can't use the website at all if it's not accessible. And let me tell you - you probably won't be able to hire us.

Check Your Website's Representation

Looking at some companies' websites, the wanted employee consists of these attributes:

Man
Plays video games
Drinks beer
Has a technical master's degree (and from a certain university)

And you know... I don't fit into that. I'm a woman; I don't play video games because I didn't have the opportunity when I was a child. Nowadays, I get frustrated because everyone else is so much better at them.

I don't drink beer (I rarely drink alcohol at all), and I don't have a technical master's degree - after all, as a developer, I'm self-taught.

And I don't mean that if I don't fit in, then nobody who's from a minority wouldn't. But only some people fit into that. Even if the actual culture inside the company is something different, we, the potential recruits, won't know it. That is if the websites and job advertisements give a one-sided picture of the company and its culture.

So, check the imagery of your company's websites and advertisements. Does everyone in the pictures look the same? Or is there diversity in these images?

Another thing to check about the imagery is that it doesn't echo the idea of white men being the seniors and POC, women, and other minorities in tech as juniors/trainees. I can't count how often I get targeted ads where senior roles have a man in the picture, and for the junior position, there's a woman in the advertisement.

Wrapping Up

This blog post might feel a bit sharp-tempered, and you're right; that was the point. I wanted to write these feelings out. I am frustrated with certain types of messages (and calls) I get from recruiters.

However, only some recruiters are like that. I've had many good convos with fantastic recruiters who clearly respect the (potential) candidate and their time.

If you found yourself or your company from one of the points, here's the good news: Now you can learn and do better in the future! It's the best place to be - without learning, we never can get better.

Android, Animations and Reduced Motion

2023-01-03T08:57:37.971Z

I don't like animations, and I'm not alone. The Verge published an article by s. e. smith: My war on animation as part of their Accessibility week, and I loved it. I was able to relate to that article on so many levels.

For me, animation and motion on a website or app can be a problem for two reasons: They might make me physically sick and distract me. Especially when I'm tired, distraction is a huge problem.

So, now you might wonder, how can I survive the internet today? Animations are everywhere.

There's an app for that! Or, rather, a setting. I can turn motion off (or reduce it) with operating system settings on my phone and computer. When this setting is on, operating system level animations are turned off.

How about websites and apps, then? Do they respect that setting? Yes and no. It entirely depends on the developers implementing the reduced motion-media query on the web. On the other hand, in apps, it depends on how the animations are built.

In this blog post, I'm talking about Android animations and how to respect that setting. I also discuss when you need to implement the check and when the animations are turned off by default.

But first, let's talk a bit about why you should care about respecting that setting.

Why is this Important?

It's the right thing to do. I mean, users have expectations on how apps work, and one of these expectations is that operating system-level settings are respected.

Sometimes not respecting that setting creates inconveniences, but sometimes it's about real, life-affecting symptoms that might get triggered. Nobody enjoys having a migraine or feeling sick after encountering something unexpected in the app - something that could have been prevented with a few lines of code.

I know there's not much knowledge about the need for reduced motion. I've worked with multiple devs, designers, and product people who've had no idea about that. And animations are here to stay - they drive engagement (or that's what everyone keeps telling me), and some people like them. But I just hope "engagement" won't drive over the accessibility needs of the people - so that's why I'm trying to educate everyone about this topic.

When to Check the Reduced Motion Setting in Your Code?

Reduced motion (or, animations off) -setting affects all Animator-based animations. That means most of the animations you use are turned off by default. The other week, I was developing a feature that required me to turn that setting off because of the animations. I was surprised by how much motion and animation was being turned off by that setting!

Also, when creating animations with Jetpack Compose, its animation classes follow that setting from version 1.2.0. However, if you're using earlier versions, I'd recommend testing if the setting is respected out of the box.

Another case when you need to know how to check if the reduced motion setting is on is if you're using something like Lottie-animations. I love how Lottie's Android component checks for reduced motion and displays the first frame if it's on - and all of this, out of the box.

However, sometimes the first frame is not applicable. Often animations start with an (almost) empty screen, which is not what you want to show users with reduced motion. So in these cases, checking if reduced motion is on and displaying a static image instead is the way to go.

So, there's no need for extra checks in many cases - at least if you're using the latest versions of, e.g., Compose. However, testing is the key. You can turn the reduced motion setting on from the accessibility settings - the setting is called "Remove animations," and depending on your phone, it might be under "Display" or "Visibility enhancements" or other similar.

How to Detect if Reduced Motion is Enabled

Since Android doesn't expose the value for reduced motion the same way as other accessibility services, such as if a screen reader is enabled, we need to be a little creative.

One way to deduce if reduced motion is enabled is to check the animation duration scale. We can get that value with

Settings.Global.getFloat(
  context.contentResolver,
  Settings.Global.ANIMATOR_DURATION_SCALE
)

The animation duration scale is 0f if reduced motion-setting is enabled.

However, if the reduced motion setting is not enabled, that setting can be undefined. So, to check the value, we'll need a catch-block, where we set the value to basically anything than 0f:

val animationDuration = try {
  Settings.Global.getFloat(
    context.contentResolver,
    Settings.Global.ANIMATOR_DURATION_SCALE
  )
} catch (e: Settings.SettingNotFoundException) {
  1f
}

Finally, to check if reduced motion is enabled, we can check if the animation duration is 0f. Here's the complete function for that:

fun isReducedMotionEnabled(): Boolean {
  val animationDuration = try {
    Settings.Global.getFloat(context.contentResolver, Settings.Global.ANIMATOR_DURATION_SCALE)
  } catch (e: Settings.SettingNotFoundException) {
    1f
  }
  return animationDuration == 0f
 }

Wrapping Up

So, even though most animations on Android respect the reduced motion setting out of the box, it's good to be aware of the possibility of situations when it needs to be respected.

I hope you've learned something from this blog post, and in the future, remember that animations are only a delight for some.

Year in Review - 2022 Edition

2023-01-07T05:30:27.797Z

Another year has come to its end, and it's time to look back and reflect on it. I wrote a similar post last year: Year in Review - 2021 edition, and it was interesting to compare these years.

This blog post reflects on my 2022 - highs and lows, interesting new things, and some hard times. It doesn't include everything, but it has many important things that happened last year. Let's dive in.

Accomplishments

Looking back on 2022, I can see some real highlights and accomplishments. Many materialized this year and have been in the works for years. I am proud of them, and I've earned them.

WTM Ambassador

In November, I got a mail that I was selected as Women Techmakers Ambassador. What is WTM Ambassador, you ask? Here's how Women Techmakers' site defines the role:

Women Techmakers Ambassadors are leaders around the world who are passionate about empowering their communities through organizing events, public speaking, creating content, and mentoring. With access to a global community and exclusive resources, Ambassadors are helping build a world where all women can thrive in tech.

It's an honor and a great recognition of my work in past years. Not everyone gets selected, so it means that I've done something right.

NWITA Nominee

Last year (2021), I was one of the finalists in the Nordic Women in Tech Award's category, Rising Star of the Year, and this year, I was nominated in the category Developer of the Year. I didn't make it to the final five, but the nomination is an honor.

Dev Top Author

To my surprise, I got an email that I'm one of this year's Dev's Top Authors. Being recognized for the time and effort I've put in writing my blog feels good.

Career Switch

One of the most significant turns this year has taken is my switch from frontend to Android development. To be honest, I was already a bit tired of frontend things. I already knew so much, and even though there's always something new to learn, I've realized I wanted something new. And Android development has been just that.

Blogging

I've written some blog posts this year too. I haven't been as productive as in 2021, but I'm quite happy with what I've written.

Three of my blog posts got to Dev's week's top 7. Interestingly, they were quite different from each other: The first was my International Women's Day post (Nevertheless, Eevis Still Codes), the second was Results of Quick Testing of Documentation Tools' Accessibility, and the third was Hey Tech Recruiter, Here Are Some Tips from a Developer.

My personal favorite posts for this year are:

Results of Quick Testing of Documentation Tools' Accessibility

Published at August 11th

Read the post Results of Quick Testing of Documentation Tools' Accessibility

I tested four different documentation tools (Swagger, Read the Docs, Docusaurus, and GitBook) and used some accessibility testing tools and techniques with them. In the blog post, I summarise my findings from these tests. Writing this blog post was fun because I like to do these accessibility tests.

Hey Tech Recruiter, Here Are Some Tips from a Developer

Published at November 6th

Read the post Hey Tech Recruiter, Here Are Some Tips from a Developer

One of the most popular posts for this year was this one. It started as a LinkedIn post, and in November, I finally had the time to write it into a whole blog post. I share some frustrations I've faced when communicating with recruiters, and this blog post resonated with many developers.

Android, Animations and Reduced Motion

Published at December 12th

Read the post Android, Animations and Reduced Motion

This blog post is the first I've written about Android that's about something other than learning Android development. As the reduced motion/animations off-theme is close to me personally, I wanted to understand how I can respect that setting on Android. And as always, I love to share what I've learned, so I wrote a blog post about it.

Speaking

I did some speaking, and for the first time in a while, some talks I gave in person.

I was talking in:

Turku <3 Frontend
Women in Tech Summit
React Native EU
React Finland
Tyttöjen päivä
Twig the Code
We are developers live

I also had to cancel a couple of events:

React Meetup in Helsinki
Modern Frontends

The first meetup I've ever spoken at was in January 2020. And as we all know, Covid hit pretty soon after - and as I've continued speaking after that, it's been all remote until spring 2022. The first in-person meetup was Turku <3 Frontend in April, and let me tell you, I was nervous! I had thought that I was way better at speaking in front of a camera, not seeing the listeners, but I surprised myself with how well speaking in front of a live audience went and how good it felt.

The number of events for 2022 was lower than for 2021. However, I'm happy about that, and I'm glad about how my speaking year of 2022 turned out. I wouldn't have the energy for more.

Projects

This year, I created some (web) projects. The first was neule.art, a visualizer for knitting patterns. It has one pattern (an Icelandic sweater), but I hope I'll have some time and inspiration to add other garments. If you want to read about the progress, I wrote a blog post about it: How I created Neule.art. Neule.art is made with Eleventy and doesn't use client-side JavaScript.

Another project was a guest book app for my sister and her friends for their birthday party. It was created with React and used AWS for storing pictures. I wrote a blog post about that project: Learnings From Creating a Guest Book App.

The third project for this year was an accessibility-themed advent calendar. It was created with Eleventy, too, and used Github Actions to reveal each day's content. I've been writing a blog post about it and will publish it probably in January.

Helping with Theses

I've had the honor of helping with three different theses - one master's thesis and two bachelor's theses. My role in the progress has been as an accessibility specialist. Depending on the thesis, I've answered more general or technical questions.

Things You Probably Didn't See

I could copy some of the lines from last year's post here. I've been struggling with the same things - I had to take some days off because of burnout symptoms. In the summer, I wrote about the theme a bit: On the Edge of Burnout... Again.

Even though I wrote in the blog post that I'm better now, the following months weren't easy. But after some changes at work (like switching roles to Android development), things have started to look better step by step. The feeling during the weekends has turned into "Monday doesn't suck." I'm even excited about the projects I'm working on and what the future will bring.

I also spent lots of time outdoors. I visited five new national parks and acquired a kayaking instructor title. And on the last day of the year, I ordered my own kayak, which I'm super excited about, and I can't wait for it to arrive.

What's Next?

I've learned not to promise too much - the world changes so fast that I cannot know where I will be in a year. But from what I know now, I will learn and code more Android, I will probably write my master's thesis with an accessibility theme, and I definitely will spend some time in a kayak!

Automating Advent Calendar with Github Actions and Eleventy

2023-01-14T13:26:11.992Z

I've always seen advent/Christmas calendars as an interesting, technical challenge. How to build something that hides content until some specified time? And to do that without client-side JavaScript? And automatically, so I don't need to deploy the page daily manually?

Last year, I decided to take up the challenge and build an advent calendar. After some consideration, the concept was clear: it would be in Finnish and about accessibility. I have a Finnish Instagram account where I talk about accessibility, so this combination made the most sense.

After that, there was all the technical decisions and solving the problem above: How to keep content hidden until the right time? In this blog post, I'll share how I solved that problem. But first, let's look into the stack I chose to use.

The Stack

The calendar is built with Eleventy - my go-to choice when I want to create something that's not so complicated that I need to break it into smaller components. Actually, now that I think of it, I'd still take Eleventy - my projects are usually simple.

Other than that, I'm using plain CSS and no client-side JavaScript. I love how you can do that with Eleventy. So, if you're wondering how I'm doing "not showing the content before the correct date": No, it's not with JavaScript. It's a combination of Eleventy's features, a private repository, and Github Actions. Let's talk about them next.

Hiding Content with Eleventy

I spent quite some time trying to come up with a solution that would solve my problem. I could have used client-side JavaScript, but then again, if I could solve that without it, it would be great.

So I started doing some research. Is there a way to prevent some pages from getting into the build Eleventy does? After searching with some terms that did not give me good results, I finally found the solution: .eleventyignore and having an unpublished-directory containing the unpublished content. This way, the contents of the unpublished-directory won't be part of the build.

Yes, I felt a bit stupid after discovering this ignore file because that was not the first thing I thought. I mean, every JS project and package has one, so why didn't I think about it straight away? Well, that happens. I am sharing this because, usually, these blog posts are about results, not progress.

Back to the story, I now had a way to hide the following days. The next thing was to write a script to move the current day's content from one folder (unpublished) to another (2022).

As I've been using Node for many years, I used it for that. I could have gone with the shell commands, but my shell scripting skills are way rustier than Node skills, so I went with the easiest solution.

After a while, I had a small function to handle moving the file. The function takes the current date as a parameter. It checks if the unpublished folder contains a file with that date and moves it to the 2022-folder.

The next thing was to set up Github Action to run the script daily, commit it to the main branch and rebuild the site.

Github Actions

For the calendar app to work correctly, there were three noteworthy aspects of writing the Github Action file: Running the workflow daily Running the Node script mentioned in the previous section Committing changes to the main branch.

For running the workflow daily, I already had an example of a schedule-event with cron in another project, so that was a little copy-paste. Github has good documentation around triggering events on workflows, and I wanted to run the workflow every night at 00:00 UTC, so these are the lines I used:

  schedule:
    - cron:  '0 0 * * *'

The second task, running the Node script, was also straightforward. Defining the script in package.json´s scripts made it effortless to run in the workflow.

I used the shell scripts for the third task because I had an example of that in another project. I first defined the committers email and name with

git config --global user.email "updater-bot"
git config --global user.name "updater-bot"

And after that, I added the moved files and committed them with

git add 2022 unpublished
git commit -m "Move day"

and finally pushed the branch to the main with

git push origin main

When the commit hit the main branch, the project got rebuilt, and the new changes were published.

The Content

Writing the content was the most fun and time-consuming part of the project. I decided to go with three types of content: Information, task, and book recommendation.

I ended up having 14 days of information, seven days of tasks, and three book recommendations. My goal was to gather material from different sources, with different types, and mainly in Finnish. And as I wanted to provide something new for a wider audience, I avoided technical content.

At the beginning of December, I shared the calendar on my social media accounts: Instagram and LinkedIn. The initial response was tremendous and showed in analytics; there was a clear spike in the visits to the page. Looking at the analytics, there were shares on (assumed) work settings, as some traffic came from Slack and Teams.

After the initial sharing, I shared each day's content daily on my Instagram account. I could have advertised the calendar way more, but my December was so busy at work, and I didn't have the energy. It shows in the analytics; most of the traffic came from Instagram.

Wrapping Up

This project was a fun one to complete. It was also the first web project I've created since switching to Android development, so I was interested in seeing if I'd totally forgotten how to web. I hadn't - but I still like Kotlin more than JavaScript

Do you have technical challenges you've been thinking about for a longer time and want to solve? Or something seen as an intriguing challenge (but not necessarily wanting to solve yourself)?

And oh, if you want to see the calendar, it's Saavutettavuusjoulukalenteri.

Sometimes I Feel Like I'm Invisible - Experiences of a Woman in Tech

2023-02-05T17:26:01.720Z

This blog post is very personal and sharing it makes me very vulnerable. So please, respect that. And please, just please don't come and tell me it's all my fault or that I have imagined it all. Because I haven't.

Throughout my career, I've felt invisible. It's these small things - My man colleague being asked about a feature, even though I'm leading its development, or someone forgetting to add my team of one into their slide deck where every other team in the company is included. Or when the men in the room constantly speak over me. Or when it's known that I'm the most knowledgeable person on a certain topic, and still a man specifically asking another man in the group to answer his advanced questions on that topic.

As an isolated incident, it's not that bad - I can understand that communication hasn't worked as it should have, and someone didn't know I was responsible or that my team even existed. Or that a man just happened to ask another man this time.

But when it happens regularly from multiple people, pretty much in every workplace I've ever worked in tech, it hurts. It hurts like hell. I feel like I'm invisible, like I or my work doesn't matter. I feel like I'm fighting against something intangible I cannot win because it's too powerful.

Sometimes, after a long week full of these occasions, which have left me feeling invisible, I can't do anything else but cry because I'm so freaking exhausted. I feel so powerless.

And what happens if I try to speak up? Well, I'm that angry woman - or just dismissed or forgotten. Or I get greeted with, "Well that person clearly didn't mean it that way." Maybe what hurts the most is when someone says (repeatedly) that they're going to do something about it, but they never do anything.

Of course, this doesn't happen from everyone or in every instance, but it has happened regularly enough for me to notice it. I remember my first job in tech and how some people treated me like I didn't know anything and that I never would. At the time, I assumed that that's how it is, but reflecting on those encounters has made me understand that it wasn't me; it was them.

I remember being dismissed, not listened to, and sometimes completely ignored in the jobs following the first. I've been left out of a meeting invite as the only woman in the group. I also remember being called too aggressive and too angry.

And I'm not the only one. Women and other minorities in tech face these same experiences all over the world. And there is a word for it: Microaggressions.

Microaggressions

Many of the things I've described above are microaggressions. Kevin Nadal, who is a professor in psychology at John Jay College of Criminal Justice, defines microaggressions:

Microaggressions are defined as the everyday, subtle, intentional — and oftentimes unintentional — interactions or behaviors that communicate some sort of bias toward historically marginalized groups.

The difference between microaggressions and overt discrimination or macroaggressions, is that people who commit microaggressions might not even be aware of them.

(Source: Andrew Limbong: Microaggressions are a big deal: How to talk them out and when to walk away)

Jennifer Y. Kim and Alyson Meister have researched microaggressions women face in STEM workplaces. In the article, they first define what microaggressions are and how they can be classified. Let's have a closer look.

Microaggressions can be classified into three types, ranging in levels of subtlety:

microassault
microinsult
microinvalidation.

The first one, microassault, explicitly demeans women, like, by calling them a "bitch". Microinsults, on the other hand, are more subtle comments or behaviors - such as when a manager calls only man employees to the meeting. In this case, the subtle message is that man's work is more valuable.

The third one, microinvalidation, is comments or behaviors negating women's experiences with gender discrimination. Examples include things like gaslighting ("Sexism is a thing of a past!") and invalidating the lived experience of women. (Source: Jennifer Y. Kim & Alyson Meister: Microaggressions, Interrupted: The Experience and Effects of Gender Microaggressions for Women in STEM)

Further, they write about problems these microaggressions cause for women in STEM. Problems include threats to woman's identity, as they're subtly challenging their legitimacy as leaders, a burden by the difficulty of decoding microaggressions, and the effects on one's (mental) health - burnout is real.

For the research, they interviewed 39 women leaders in STEM in North America with various backgrounds. From the material, they found five types of microaggressions:

Devaluation of technical competence
Devaluation of physical presence
Denial of one's reality
Pathologizing one's character
Pathologizing one's gender

The other theme they were researching was the meaning of allyship. Let's talk about that in the next section.

The Meaning of Allyship

Kim and Meister found in their research that the intervention from allies was essential in keeping women from leaving STEM fields. I couldn't agree more. Reading the research paper, I could also put some feelings into words and understand why an ally stepping up has felt so great.

Usually, allies are defined as someone from the dominant group. In the case of gender and tech, by that definition, allies are often men. It's imperative that members of the dominant group help with the efforts to bring more equality, as the non-dominant group alone can't change the status quo.

However, in their study, Kim and Meister defined allies and ally interventions more broadly, including, e.g., more senior women stepping up in the events of microaggressions. And that's how I mean allyship in this blog post - something anyone can and, depending on the situation (e.g., assuming it's safe), should do.

The types of interventions from allies Kim and Meister found fell into two categories: domain-related and person-related. The first, domain-related, was about acknowledging one's technical skills (e.g., vouching publicly for a woman's technical skills after someone had doubted or minimized them). The second one, person-related, was about acknowledging the microaggressions women face and validating the experiences of women.

From my experience, the interventions of allies have often helped me understand and handle the situation and reframe it in my mind. I've recognized that I wasn't imagining the problem: someone else has noticed it too. And further, as Kim and Meister write, it has interrupted the internalization process - otherwise, I would have internalized the thoughts about me not being competent enough, of me not belonging in tech.

This is the call to action to anyone who can: When you see these microaggressions happening, step up and talk about it - especially if you are a leader or in a more senior position.

Wrapping Up

Microaggressions suck. As isolated incidents, they're small things, but when they happen repeatedly, they build this colossal load which can eventually lead to health problems and women and other minorities leaving tech. So we need to do better.

Think about your work environment. What could you do to prevent microaggressions from happening?

Improving Android Accessibility with Modifiers in Jetpack Compose

2023-07-11T05:56:24.800Z

The other day, I was doing some accessibility fixes on our codebase. I came across a switch that didn't have a label associated with it, meaning screen reader users would need to do a bit of guessing to get the information on what they were toggling. I wanted to fix that and started researching.

At one point, I was going through the list of modifiers for composable components and noticed that many could help make the app more accessible. I got so excited! And I wanted to share some of these modifiers with you, so here we are. I'm going to go through these modifiers:

toggleable
selectable
clickable
magnifier

But first, let's talk a bit about modifiers in general and what they are.

What are Modifiers?

As the Android Developers site defines modifiers:

Modifiers allow you to decorate or augment a composable. Modifiers let you do these sorts of things:

Change the composable's size, layout, behavior, and appearance

Add information, like accessibility labels

Process user input

Add high-level interactions, like making an element clickable, scrollable, draggable, or zoomable

(Source: Android Developers: Compose modifiers)

So they are a way to modify composables' looks, behavior, and semantics. They're used a lot in modern Android development with Jetpack Compose, so if you've ever tried Compose, you've probably come across them.

As the modifiers can do many things, we can use them for improving accessibility as well. Let's talk about that more in the next section.

Modifiers for Accessibility

There are many use cases for different modifiers to improve the accessibility of our apps. For example, with modifiers, we can reduce the amount of tab stops for users that use switch devices, hardware keyboards, or screen readers, or we can add more semantic information for assistive technology users in general.

We can add visual cues such as focus indicators or improve the visibility and feedback of touch interactions. A good example is what we will do later in this post by increasing the touch target size; we're also increasing the size of the ripple effect to give better feedback on actions to anyone using the app.

One thing I always want to emphasize when discussing accessibility is that when building your app, remember to test it with different assistive technologies. You might find that some things are not working as expected - that's precisely what happened to me when I was writing the code for this blog post.

Oh, and speaking about the code, if you want to see it, you can find the repository for Modifiers Example App here.

In this section, we will look closer at the modifiers I listed at the beginning of the blog post. Let's start with clickable.

Clickable

Clickable-modifier, as the name states, makes the element clickable. This utility can be useful when creating, e.g., lists of items that need to be clickable or if some larger area needs to be clickable.

However, if you're creating a plain ol' button, I advise using the Button-component because it already has the semantics and behaviors built in and is accessible by default.

Let's consider an example of a list where the user needs to be able to bookmark an item on the list. This picture shows what we are building:

As seen in the picture, there is a row with text ("Bookmark this item") and a bookmark icon. One option is to wrap the icon with the IconButton component:

Row(
    modifier = Modifier
        .fillMaxWidth()
        .clip(MaterialTheme.shapes.large)
        .background(MaterialTheme.colorScheme.primaryContainer)
        .padding(ClickableScreen.padding),
    horizontalArrangement = Arrangement.SpaceBetween,
    verticalAlignment = Alignment.CenterVertically,
) {
    Text(
        text = "Bookmark this item", 
        style = MaterialTheme.typography.titleMedium, 
        color = MaterialTheme.colorScheme.onPrimaryContainer
      )
      IconButton(onClick = { onClick() }) {
          FavouriteIcon(
              icon = icon, 
              contentDescription = "Bookmark this item"
          )
      }
}

This code snippet would work, and when a user taps the icon button, the item would get bookmarked. However, the area where the user can tap is small. It would be easier to tap the whole row.

Let's make a couple of changes:

Row(
    modifier = Modifier
        .fillMaxWidth()
        .clip(MaterialTheme.shapes.large)
        .background(MaterialTheme.colorScheme.primaryContainer)
        // Add clickable-modifier with the role of Button
        .clickable(
                role = Role.Button,
          ) {
                onClick()
          }
        .padding(ClickableScreen.padding),
    horizontalArrangement = Arrangement.SpaceBetween,
    verticalAlignment = Alignment.CenterVertically,
) {
    Text(
        text = "Bookmark this item", 
        style = MaterialTheme.typography.titleMedium, 
        color = MaterialTheme.colorScheme.onPrimaryContainer
    )
  // Remove IconButton. 
  // The content description is not needed anymore 
  // as the whole element is merged and text serves as a label 
   FavouriteIcon(icon = icon, modifier = Modifier.padding(12.dp))
}

This change improves the accessibility of the modifier a lot. It increases the touch target size and adds the role of a button so that assistive technology users will know it's a button.

This modifier works well if you need to perform a single click. However, if you'll need a double click and/or a long click in addition to a single click, combinedClickable is your friend.

Selectable

Another modifier we can use for improving accessibility and usability is selectable. It's often used as part of a mutually exclusive group - such as a radio button group.

There are a couple of benefits to wrapping the whole row with this modifier (instead of, e.g., using a button or clickable-modifier): The area where a user can tap and select the item is larger, you can add correct semantics for the element so that assistive technology users get relevant information and the items can be grouped easily.

Let's talk about how to improve an example I've seen in several places. The picture shows what we're building:

And here's the simplified code (not copied from any of the codebases mentioned above):

@Composable
fun RadioInputRow(text: String, checked: Boolean, onChange: (String) -> Unit) {
    Row(
        modifier = Modifier
            .fillMaxWidth()
            .padding(16.dp),
        horizontalArrangement = Arrangement.SpaceBetween,
        verticalAlignment = Alignment.CenterVertically,
    ) {
        Text(
            text = text, 
            style = MaterialTheme.typography.labelLarge, 
            color = MaterialTheme.colorScheme.onPrimaryContainer
        )
        RadioButton(
            selected = checked,
            onClick = { onChange(text) },
            colors = RadioButtonDefaults.colors(
                selectedColor = MaterialTheme.colorScheme.tertiary,
                unselectedColor = MaterialTheme.colorScheme.tertiary,
            ),
        )
    }
}

This code snippet works, but a user needs to be able to tap the radio button, which has a small touch target size. Let's make a couple of modifications to make the code more accessible:

@Composable
fun RadioInputRow(
    text: String, 
    checked: Boolean, 
    onChange: (String) -> Unit
) {
    Row(
        modifier = Modifier
            .fillMaxWidth()
        // We add a selectable modifier with state and role to the row
           .selectable(
               selected = checked,
               enabled = true,
               role = Role.RadioButton,
               onClick = { onChange(text) },
            )
            .padding(16.dp),
        horizontalArrangement = Arrangement.SpaceBetween,
        verticalAlignment = Alignment.CenterVertically,
    ) {
        Text(
            text = text, 
            style = MaterialTheme.typography.labelLarge, 
            color = MaterialTheme.colorScheme.onPrimaryContainer
        )
        RadioButton(
        // We clear the semantics from
        // the RadioButton, so that the user, 
        // who is using assistive technology,
        // doesn't have an extra tab stop on the way.
            modifier = Modifier.clearAndSetSemantics {},
            selected = checked,
            onClick = { onChange(text) },
            colors = RadioButtonDefaults.colors(
                selectedColor = MaterialTheme.colorScheme.tertiary,
                unselectedColor = MaterialTheme.colorScheme.tertiary,
            ),
        )
    }
}

This way, the click area is more extensive, and it's easier to hit and select the target. For this example, I decided to keep the Material Theme's RadioButton-component, but we could also switch it to two icons (selected and unselected), the same way as in the clickable-example.

There are a couple of things to note about the semantics of this example. First, the whole row gets the selectable-modifier, and we pass the state (enabled, selected) to it, and we also pass the role of a switch to it. This way, we can ensure that assistive technology gets correct information about the element, and users will know how to interact with it.

Another aspect related to semantics is to clear all semantics from the original RadioButton-element. If we don't do it, the user will encounter the same component with the same info twice - first on the container (Row) and then with the radio button. That also means an extra tab stop for anyone navigating with assistive technology using focus order.

We want to make one more change and add the selectableGroup-modifier to the parent component that is wrapping all the radio input rows:

Column(
    modifier = Modifier
        ...
    // Adding the selectableGroup here:
        .selectableGroup(),
    verticalArrangement = Arrangement.SpaceBetween,
) {
    inputs.map { input ->
        RadioInputRow(
            text = input, 
            checked = selected == input, 
            onChange = { selected = it }
        )
        ...
    }
}

This way, users using, e.g., a screen reader, get the information that there is x number of items in the list as an option to select.

Toggleable

Like selectable, the toggleable- modifier helps make components more accessible. toggleable can be used when there is a state with two values - like selecting a setting with an option to be on or off.

For this example, we have a row with text and a toggle at the end:

And the code we have at first looks like this:

fun SwitchRow(
    text: String, 
    checked: Boolean, 
    onChange: (Boolean) -> Unit
) {
    Row(
        modifier = Modifier
            .fillMaxWidth()
            .padding(16.dp),
        horizontalArrangement = Arrangement.SpaceBetween,
        verticalAlignment = Alignment.CenterVertically,
    ) {
        Text(
            text = text, 
            style = MaterialTheme.typography.labelLarge, 
            color = MaterialTheme.colorScheme.onPrimaryContainer
        )
        Switch(
            checked = checked, 
        onCheckedChange = { onChange(it) }
        )
    }
}

In this code snippet, the touch target is only the area of the Material Theme's Switch-component, as it was with the example of the selectable-modifier. Also, other similar problems (as mentioned in the selectable-section) are present. So, we'll make a couple of changes to make this component more accessible:

@Composable
fun SwitchRow(
    text: String, 
    checked: Boolean, 
    onChange: (Boolean) -> Unit
) {
    Row(
        modifier = Modifier
            .fillMaxWidth()
        // We add the toggleable modifier
        // with the state (value) and role
            .toggleable(
                 value = checked,
                 role = Role.Switch,
                 onValueChange = { onChange(it) },
            )
            .padding(16.dp),
        horizontalArrangement = Arrangement.SpaceBetween,
        verticalAlignment = Alignment.CenterVertically,
    ) {
        Text(
            text = text, 
            style = MaterialTheme.typography.labelLarge, 
            color = MaterialTheme.colorScheme.onPrimaryContainer
        )
        Switch(
              checked = checked, 
              onCheckedChange = { onChange(it) }, 
              // We clear the semantics
              modifier = Modifier.clearAndSetSemantics {}
        )
    }
}

It has a value attribute as part of its state. For toggleable, the role is usually Switch - compared to selectable's RadioButton.

Magnification

The final modifier in this blog post is different from the others. You can use this modifier for magnification in your app. However, it's important to note that in many cases, the operating system's magnification is sufficient, and people who need it know how to use it (and do use it). But this might be useful in some cases, not just for those who use the os's magnification but for anyone who needs to magnify a part of your UI.

For the magnifier modifier to work correctly, the Android's Magnifier widget needs to have support on the device. Before proceeding, we'll want to check that:

if (!MagnifierStyle.Default.isSupported) {
    Text("Magnifier is not supported on this platform.")
} else {
    // TODO
}

The magnifier-modifier needs to know the center of the magnified area. We can get that information from the pointerInput-modifier's dragDetectedGestures function. We want to store the value of the center to a variable:

var magnifierCenter by remember { 
    mutableStateOf(Offset.Unspecified) 
}

Then we'll wrap the area we want a user to be able to magnify with a Box element and set the modifiers:

Box(
    Modifier
        // Set the source center and styles for the magnifier
        .magnifier(
            sourceCenter = { magnifierCenter },
            zoom = 3f,
            style = MagnifierStyle(
                size = DpSize(height = 200.dp, width = 300.dp),
            ),
        )
        .pointerInput(Unit) {
            detectDragGestures(
                // Show the magnifier in the initial position
                onDragStart = { magnifierCenter = it },
                // Magnifier follows the pointer during a drag event
                onDrag = { _, delta ->
                    magnifierCenter = magnifierCenter.plus(delta)
                },
                // Hide the magnifier when a user ends the drag movement.
                onDragEnd = { magnifierCenter = Offset.Unspecified },
                onDragCancel = { magnifierCenter = Offset.Unspecified },
            )
        },
) {
    Text(
        "Try magnifying this text by dragging a pointer (finger, mouse, other) over the text.",
    )
}

So, with this code snippet, this is what we get:

Wrapping Up

In this blog post, we've discussed modifiers and accessibility in general, and we've looked more closely into four modifiers: clickable, selectable, toggleable, and magnifier. This post was not a comprehensive one on accessibility and modifiers, and I've intentionally left out some topics like focus management and hardware keyboards entirely. I'm planning to write blog posts about those themes later.

Do you have any thoughts, ideas, or questions? Let me know!

Android Developers and Accessibility - Challenges and Proposed Solutions

2023-07-17T04:21:15.578Z

My current Big Project is my master's thesis - I'm writing about Android accessibility, and my goal is to create a list of checks Android developers could use to create more accessible apps. I'm super excited about the theme, and once it's ready, I will definitely share the results on my blog.

One of the main theoretical themes in the thesis is how Android developers implement accessibility and what challenges prevent them from doing so. Research also provides some solutions to these challenges.

In this blog post, we'll first look through some of the challenges Android developers face (although these are common for other types of development as well) and then discuss proposed solutions.

The Challenges

Let's first look at the challenges developers face. I've listed all the resources used in the Resources section. The list has three studies about Android developers, their accessibility knowledge, and their willingness and readiness to develop accessible apps.

Not Knowing About Accessibility and Lack of Awareness

The first problem I want to mention is that Android developers often lack accessibility knowledge. This lack of familiarity varies - for some, it's total unawareness, but for most, it shows as problems understanding the exact needs of disabled users. ¹

This finding is something I can confirm from my own experiences. Often Android developers are familiar with the fact that accessibility should be part of an app. Still, the exact implementation and why they must do something are unclear.

Companies Ignoring Accessibility Requirements

Another aspect of the lack of awareness is that companies ignore the accessibility requirements. Patel et al. ² found out that the leadership in companies often prioritized other things over accessibility when a deadline was approaching. They usually see accessibility as an extra cost rather than an opportunity. This attitude is also visible in the internal policies, so for developers, it's often hard to find time to fix accessibility issues retroactively.

Another thing that is related to fixing accessibility as an afterthought is that it can be considered hard - and it might lead to a situation where those accessibility issues don't get fixed. ¹

I can again confirm these findings - throughout my career, I've witnessed situations where accessibility is not part of the company's requirements, which means there is no time or resources to consider accessibility.

Little to No Exposure or Background with Accessibility

Vendome et al. ³ found out that developers often don't have exposure or background with accessibility and assistive technology, and that leads to misunderstandings, e.g., in questions developers ask on platforms like Stack Overflow. For example, they might ask about how TalkBack reads phone numbers and how to force it to read them in a particular way. (For those unfamiliar with TalkBack: TalkBack users can control this with settings, and developers should not force it on apps.)

On the other hand, opportunities to interact with people with disabilities were considered as a helpful way to understand user expectations better. ² I think this all comes down to the fact that it's helpful to talk to users to understand their expectations and needs. It's a crucial part of creating good apps.

One challenge for accessibility is that it's mostly about screen reader accessibility. Vendome et al. ³ found out that the most discussed topic on Stack Overflow (in the material they collected) was screen reader accessibility.

I can second that finding from my experience - when discussing accessibility, it's often about screen reader accessibility. And it's an important aspect, but it's necessary to remember that it's not all. Considering interaction for people who can see or have low vision is as important as is, e.g., cognitive accessibility.

Belief of Accessibility Having Negative Effects on the App's Aesthetics and Usability

Another finding I've witnessed is that some developers (and designers) believe that if they incorporate accessibility into their apps or designs, it will affect the app's aesthetics and/or usability. Di Gregorio et al. ¹ found that developers might meet ideas about progressive functionality or interfaces negatively because they can add complexity to the app.

As a developer, I can understand where this comes from. Especially requirements added as an afterthought do increase complexity - so it's important to include accessibility right from the start, and building these interfaces is less work.

Lack of Tools

The second to last finding is the lack of tools for developing accessible apps. Also, some developers have had situations where free tools have disappeared suddenly, and there has been nothing to replace them. ²

Another thing related to different tools (or assistive technology) is that developers often don't have experience with those tools, which can lead to misunderstandings and solving problems that are not problems. One example is the problem described in the section "Little to No Exposure or Background with Accessibility" about TalkBack and numbers. TalkBack handles how numbers are presented, and users can alter that, but because developers didn't know it, they tried to force their app to represent numbers in a certain way when using TalkBack. ³

From the perspective of a mobile dev with a background in web development, I agree that there aren't enough tools for developing accessible Android apps. There are way more tools for accessibility in web development, but for Android, not so much. The situation is changing, but slowly. I've also seen the lack of exposure to assistive technology and how it can lead to interesting outcomes.

Relevant and Usable Information is Hard to Find

The last finding is that it's hard to find relevant and usable information. One interviewee from Di Gregorio et al.'s research noted that it's not just about unawareness of accessibility guidelines but also about not being able to find usable information from the internet to fix the issues. ¹ Patel et al. ² also discovered a lack of resources - especially for building accessible components. And one of their study participants noted that the available accessibility guidelines should be in a form that is more digestible so that developers would use them.

I can fully agree. Especially with Android development, I often know what I should do regarding how the app should behave to be more accessible. Still, it's hard to find usable articles on how actually do the technical implementation. So I can only imagine how hard and frustrating it can feel for someone with less background in accessibility.

We've gone through many challenges Android developers face, and let's look next at the solutions proposed in the research. These solutions don't solve every aspect, but at least some of them.

Proposed Solutions

The three research articles I've looked at list two types of proposed solutions to solve the challenges of building accessible apps for Android: Better tools and education. Let's look at both of them more.

Better Tools for Development

Both Patel et al. ² and Vendome et al. ³ suggest having better tools for development to address accessibility in specific technical implementations. These tools could be integrated with, e.g., IDEs and could (or from what I've observed and talked with other developers, should) be semi-automated.

I've been following the Android development ecosystem for a while now, and there are ongoing processes to improve the tooling. There are some code checks in Android Studio for XML-based views, but they've been lacking from Compose components. However, in Google I/O, they announced that there would be improvements for Compose previews in the form of these accessibility warnings. (Source: What's new in Android Accessibility)

Increase Accessibility Knowledge Through (Formal) Education

Another proposed solution is to increase accessibility knowledge through education. That could be achieved by adding more accessibility-related topics to curriculums of non-computing fields. Also, within computer science and related fields, learning about addressing accessibility issues during development would be beneficial. ²

This solution goes past formal education - developers would generally benefit from learning more about universal design principles and targeted tutorials and workshops addressing specific accessibility topics. ² ³

From my perspective, on both formal and informal education, I've been happy to notice the increase of accessibility-themed articles and workshops, as well as accessibility in the curriculums of, e.g., universities. There is, of course, a lot to be done, but the direction is correct.

But even if we had many quality articles and other resources, it's always each developer's responsibility to learn more about the topic. Any amount of education or materials is only enough if we, as developers, take the opportunity to learn more.

Wrapping Up

In this blog post, I've gone through some challenges Android developers face regarding accessibility per prior research. I've discussed lack of awareness, companies ignoring accessibility requirements, developers having little to no exposure or background with accessibility, accessibility being only about screen reader accessibility, the belief that accessibility makes the app less usable or beautiful, lack of tools, and that relevant and usable information is hard to find.

I've also shared some suggested solutions: better tooling for development and increasing accessibility knowledge through formal and informal education.

Do you recognize these challenges in your work? Or do you have additional solution ideas?

Resources

¹ Di Gregorio, M., Di Nucci, D., Palomba, F., & Vitiello, G. (2022). The making of accessible Android applications: An empirical study on the state of the practice. Empirical Software Engineering, 27(6), 145. https://doi.org/10.1007/s10664-022-10182-x
² Patel, R., Breton, P., Baker, C. M., El-Glaly, Y. N., & Shinohara, K. (2020). Why Software is Not Accessible: Technology Professionals' Perspectives and Challenges. Extended Abstracts of the 2020 CHI Conference on Human Factors in Computing Systems, 1–9. https://doi.org/10.1145/3334480.3383103
³ Vendome, C., Solano, D., Liñán, S., & Linares-Vásquez, M. (2019). Can Everyone use my app? An Empirical Study on Accessibility in Android Apps. 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME), 41–52. https://doi.org/10.1109/ICSME.2019.00014

More Accessible Graphs with Jetpack Compose Part 1: Adding Content Description

2023-07-24T09:03:19.422Z

Data visualizations rely on the visual representation of data. And that data is usually portrayed by some combination of colors. On mobile apps, they also often include different interactions that rely on touch.

But what if your user can't see? Or if they're colorblind, and the combination of colors is not visible to them? Or if they use a switch device or hardware keyboard for navigation?

From my experience, data visualizations of apps are often inaccessible for these groups of users, for instance. I wanted to experiment with how much changes and code would be needed to make a line chart more accessible. To my surprise, the amount of code wasn't that much. Of course, experimenting took some time, but after solving these problems, I now have an example project I can utilize in other projects.

And because I love to share what I've learned, I'm writing this series of blog posts to help you to build more accessible graphs with Jetpack Compose. We'll look at three different aspects:

Adding information for non-visual access users (so, e.g., a TalkBack user)
Adding keyboard interaction in addition to touch-based interaction
Differentiating data by other means than just color

This first blog post in the series is about adding information for non-visual access users, e.g., screen reader users. The following two blog posts will cover adding keyboard interaction and differentiating data with other means than just color. There might be additional posts about voice access and increasing touch target size in the future.

My goal is not to provide a final solution but ideas you can take and improve to use in your codebase. Of course, graphs can be more complex, and these relatively simple solutions might not work for everything, but I hope they'll give you pointers on improving your graph's accessibility.

Let's first talk about the example project I prepared for this experiment.

The Initial Project Code

So, before starting any explorations on making things more accessible, I needed to build a small example app. You can find all the code in this blog post from the Graph Example-project repository. The main-branch contains the final version with all the changes, and the starting-point-branch has the initial code I started tweaking.

Here's a short video on what I built:

The app has a line graph containing data from woman applicants in Finnish higher education per year (starting from 2015) from two fields: Information Communication Technology and Engineering (non-ICT). The graph shows the percentage of women applicants for these fields individually and displays the total percentages for these two fields.

When a user touches and horizontally drags a pointer over the graph, the selected year's percentages are shown in the bottom right corner. These values are not available in any other way - so if a user can't use a pointer, they would miss this information.

Technically, this graph is built with the Canvas-API, which adds some restrictions on how to add, e.g., content description to elements. And that's something we want to do - as that is one way to communicate the values to someone who can't see the texts. Let's next look at how we can add them to the graph.

Adding Content Descriptions to Items on Graph

Because of how the graph is utilizing Canvas-API, it means that it's completely hidden from accessibility services. In practice, it means that someone using, e.g., TalkBack can't access the values inside the graph. Also, because the labels on x- and y-axes are built with the drawText-method, they're unavailable. Here's an example of how TalkBack reads through the screen:

On the video, I'm navigating through the screen with TalkBack. The video shows that the cursor entirely skips the graph. It reads the title before and the labels under the graph but nothing from it. Let's start improving the experience by adding a Highlighter-component.

Add `Highlighter`-Component

In this case, the Highlighter-component is an overlay over the graph, highlighting the selected section, and should be visible only when focused. Technically, it's a Box that overlays the whole graph, with smaller Box-elements that are the size of the highlighted area. This component also helps improve the keyboard and switch interaction, as we'll see in the later blog post.

The Highlighter-component looks like this:

@Composable
fun Highlighter(
    modifier: Modifier = Modifier,
    widthBetweenPoints: Float,
    pixelPointsForTotal: List<Point>,
    pixelPointsForTech: List<Point>,
    pixelPointsForIct: List<Point>,
    highlightedX: Float?
) {
    Box(
        modifier
            .fillMaxSize(),
    ) {
        val sectionWidth = with(LocalDensity.current) {
            widthBetweenPoints.toDp()
        }

        pixelPointsForTotal.forEachIndexed { index, point ->
            val xOffset = ((index + 1) * widthBetweenPoints - widthBetweenPoints * 0.66f).toInt()
            var isHighlighted by remember { mutableStateOf(false) }
            var position by remember { mutableStateOf(Pair(0f, 0f)) }

            if (highlightedX == null) isHighlighted = false

            highlightedX?.let {
                isHighlighted = it > (position.first - widthBetweenPoints) && it < (position.second - widthBetweenPoints)
            }

            Box(
                modifier = Modifier
                    .fillMaxHeight()
                    .width(sectionWidth)
                    .offset { IntOffset(xOffset, 0) }
                    .border(
                        width = Graph.Highlighter.width,
                        color = if (isHighlighted) MaterialTheme.colorScheme.onBackground else Color.Transparent,
                        shape = RoundedCornerShape(Graph.Highlighter.borderRadius),
                    )
                    .onGloballyPositioned {
                        position =
                            Pair(
                it.positionInParent().x, 
                it.positionInParent().x + it.size.width
              )
                    }
            ) {
            }
        }
    }
}

It takes the following parameters:

modifier: Modifier - a modifier to pass down styles. Defaults to Modifier
widthBetweenPoints: Float - as the name states, width between the points. It's used to position the highlighting section correctly
pixelPointsForTotal: List - List of values for total as Point
pixelPointsForTech: List - List of values for engineering as Point (should be renamed to pixelPointsForEng)
pixelPointsForIct: List - List of values for ICT-field as Point
highlightedX: Float? - x-value of the currently highlighted item

Note: The Point is a data class defined in the code, and the definition looks like this:


data class Point(
    val x: Float,
    val y: Float,
    val year: Int,
    val percentage: Float,
    val isHighlighted: Boolean = false,
) {
    val percentageString = "${percentage.toInt()} %"
}

Inside the component, all the pixel point values for the total (but this could be any of the lists) are mapped, and the lambda returns a highlighting section for each point. The offset for each section is calculated with the help of widthBetweenPoints.

We'll also need to get the position of the highlighter. The values are the start and end x-coordinates of the component. We'll save it to state, and on the Box-component, we change the value on the onGloballyPositioned-modifier:

var position by remember { mutableStateOf(Pair(0f, 0f)) }
...

.onGloballyPositioned {
    position =
        Pair(
            it.positionInParent().x, 
            it.positionInParent().x + it.size.width
        )
 }

We can then use these values to determine if the currently selected year (the highlightedX-parameter) is inside the area of this highlighter component.

var isHighlighted by remember { mutableStateOf(false) }
...
if (highlightedX == null) isHighlighted = false

highlightedX?.let {
    isHighlighted = 
        it > (position.first - widthBetweenPoints) 
        && it < (position.second - widthBetweenPoints)
}

In the code snippet, isHighlighted stores the value of whether the pointer is inside its area. If highlightedX is null (there's no pointer input on the graph), then isHighlighted is false.

We can then useisHighlighted to change the border color of the area in the border-modifier:

.border(
    width = Graph.Highlighter.width,
    color = if (isHighlighted) MaterialTheme.colorScheme.onBackground else Color.Transparent,
    shape = RoundedCornerShape(Graph.Highlighter.borderRadius),
)

This image shows the current state when the year 2019 is highlighted:

We now have a highlighter component. The current implementation just outlines the current selection when using pointer input, so it's not improving accessibility that much just yet. Let's next add some content descriptions to make the graph more accessible.

Add Content Description

Next, we want to add a content description for anyone using assistive technology such as TalkBack. We first want to add the focusable- modifier to each highlighter's child element. As the name states, it makes the element focusable, meaning people with different assistive technologies can reach it. Without it, the element is hidden from a screen reader and not focusable with, e.g., a hardware keyboard or switch device.

The second step is to add the content description for each highlighter's child element. Because we use the Box-component, we need to use the semantics-modifier's contentDescription-property - contrary to the contentDescription-property available for some components (such as Images).

As each highlighted section displays the year and values for ICT, engineering, and total, that's what we want to add to the content description as it is the relevant information for that section. We first form the content description inside pixelPointsForTotal.forEachIndexed {}:

val contentDesc = 
    "${point.year}: " +
    "${stringResource(id = R.string.all)} ${point.percentageString}, " +
    "${stringResource(id = R.string.eng)} ${pixelPointsForTech[index].percentageString}, " +
    "${stringResource(id = R.string.ict)} ${pixelPointsForIct[index].percentageString}"

Then we add the focusable modifier and use the content description we defined in the semantics-modifier:

...
    .focusable()
    .semantics {
        contentDescription = contentDesc
    },

This way, when a user focuses on a highlighted section with a screen reader, they would hear (or get in Braille) the following:

The complete difference in code for this section is available in this PR.

Wrapping up

In this blog post, we've looked at the initial code of the Graph Example project and how it's built. We then added a highlighter component to help us with our task of creating more accessible graphs. Finally, we added a content description for each highlighted section.

Please remember that this code is simplified, and when applying it to your codebase, you'll probably need to find out how to tweak it to work correctly.

Do you have any questions, comments, or feedback, or want to say anything else? Please share; I'd like to hear it!

Links in the Blog Post

More Accessible Graphs with Jetpack Compose Part 2: Adding Keyboard Interaction

2023-07-31T06:00:12.392Z

Welcome to the second episode of "More Accessible Graphs with Jetpack Compose" - in this blog post, we'll continue from where we left off in the first one. We will look at improving the (physical) keyboard access for graphs in Jetpack Compose. Link to the first part: More Accessible Graphs with Jetpack Compose Part 1: Adding Content Description

At the end of the blog post, I mentioned that the second part would be about keyboard and switch access. After testing my code for the blog post, I realized that the switch access part didn't work. After some deep-diving into documentation, I admitted I wouldn't add it to this post as it would require a lot of research. So there likely will be at least four parts in this "More Accessible Graphs with Jetpack Compose"-blog post series.

In the first blog post, we added a Higlighter-component, an overlay on top of the line graph I had built. Then we made it focusable and added a content description for accessibility services.

After these changes, a keyboard user can already focus on the different parts of the graph, but there's one problem: The graph legend is not visible. And you may now wonder if it is really a problem - we added the content description, right?

The content description is unavailable if you only use a keyboard. If a person, who can see and uses a hardware device for navigation, navigates with the graph in the current state, they probably get frustrated because this is what they would get:

They can see that the focus changes but can't see the individual values. If I encountered something like this, I would think there is a bug in the app.

Adding Keyboard Interaction

Users can already focus on each section, so we no longer need to worry about that. But we'll need a way to change the currently focused position on the x-axis - like if a user was moving their finger on the graph.

The highlightedX-parameter is the one that controls the currently highlighted position on the x-axis. We'll need to add a way to change it programmatically when a highlighter section gets focus. Let's first add a function to do that:

@Composable
fun Highlighter(
    ...
    setFocus: (Float) -> Unit
) { ... }

On the parent component, which stores highlightedX, we define a function to change the value of highlighted X-position:

Highlighter(
    ...
    setFocus = { newX ->
        highlightedX = newX
    }
)

Okay, now we have a function to control the x-position and switch the currently focused position on the x-axis. We want to pass the x-position of the currently focused highlighter section to the function, and for that, we attach an onFocusChanged-modifier.

.onFocusChanged {
    if (it.isFocused) {
        setFocus(point.x)
    }
}

Within the modifier, we check if the current section is focused, and if it is, we use the setFocus-function, passing the x-position of that currently focused section.

After this change, we already have working code - focusing on a highlighter section that shows the graph label so that a user can see the values for each point on that focused year.

There is just a minor tweak we still want to do. Right now, the border of the highlighter is visible if there is a focus on the component from both hardware devices and pointer input. We don't want to show the highlighter component's border for pointer input because there is already a different highlighter (a dashed line) when a user uses pointer input.

We will fix that by adding a state for border color, setting it to transparent by default, and then updating it when the focus changes.

var color by remember { mutableStateOf(Color.Transparent) }
...
// Then on .onFocusChanged-modifier:

.onFocusChanged {
    color = if (it.isFocused) focusedColor else Color.Transparent
    ...
}

And we use that color-variable for the border color for each highlighter section.

Now it all works as expected, as seen in this video:

The video shows that focus and the label text change when a user navigates by using a keyboard.

You can find all the changes made in this commit.

Wrapping Up

In this blog post, we've developed the Highlighter-component further to allow interaction with assistive devices like hardware keyboards. This way, a user won't be relying only on being able to use pointer input, such as touch.

The third blog post will be about differentiating data with other means than color.

Links in the Blog Post

The Power of Default

2023-08-07T04:30:31.014Z

Oh, hey there! Before you read this blog post, I want to say that it contains a lot of talk about equality and how some groups of people are not seen as equal compared to others. I'm passionate about changing that. If you know that a feminist point of view makes you angry, I recommend reading but take some deep breaths before commenting. Try to be friendly, like there was actual human reading your comment. Thank you!

There's a lot of power with the default. And with default, I mean default selections in (digital) services, apps, and others - but also in the fact that some groups of people are seen as the default, "normal", compared to other groups.

Why I'm writing about this theme? Well, I believe that we, as developers (or, basically, any role in the tech industry), need to be really conscious of this topic so that we don't accidentally (or, in some cases, on purpose) exclude, or even discriminate, some of our users. We need to recognize what our decisions can do to actual people.

In this blog post, I'll first talk about who is default and who is not, then about the default in tech, and finally, I'll discuss using the default for good.

Who is Default and Who is Not?

The Default in What We Don't Say

The default is visible in what we don't say and what needs to be explicitly said. Let's take an example from sports: When writing this post, the FIFA Women's World Cup is ongoing. Do you know what the men's tournament is called? FIFA World Cup. There is no mention of men; it's just an assumption that everyone knows it's about men; it's the default.

However, I want to mention that I love how Finnish YLE (the national broadcasting company) is talking just about "Jalkapallon MM 2023", meaning Football/Soccer World Championships 2023 — so they don't mention gender.

That is, of course, a problem for some; some Finnish people have complained online that it should be called women's football. Well, the same people have a history of saying that they're defending women's rights in sports when they're just being transphobic. Talk about caring about women's sports now.

The other example of the default is the color of skin. Have you ever noticed that when someone is describing a person, they often mention the color of the skin only if it's not white? It's as if white skin color is a default.

The third example I want to highlight is heteronormativity and its defaults. If someone says they're in love and has not explicitly told that they're not heterosexual, others often assume that if that person is a woman, the person she's in love with is a man, and vice versa. To be seen, they'll need to tell that they're, e.g., gay/bi/pansexual (or something else). The default assumption is that everyone is heterosexual.

And yes, heteronormative assumptions often forget that gender is not binary - which makes other genders than men and women invisible.

The Default with Professions

As a woman in tech - and especially in a technical role, I constantly face the fact that the word "software developer" is a gendered word for many. There's this implicit assumption that developers are men. This belief is visible in how people speak - it's not once or twice when the hypothetical software developer is gendered as "he" (not, e.g., "they). It's also visible when I meet new people - there have been situations where I've assumed to be in a non-technical role, such as HR or marketing, or a designer, just because of my gender.

And this default with professions is detectable in other disciplines as well. It can be created through words, or it can be implicit. In Finland (and in many other countries), nurses are assumed to be women. Firefighters (no, I'm not going to enforce the stereotype by calling them "firemen") are often assumed to be men.

If we talk about high-paying roles, the assumption is that these people are men. There's this joke I've heard: "Women just don't want to be in the high-paying positions, they choose the lower paying ones, such as woman-CEO, woman-doctor, woman-lawyer, etc."

Defaults with professions are usually implied, something that's not said out loud. I gave examples from gender - but the other aspects have their own defaults. They all work the same way - often whiteness, cis-gender, heterosexuality, living without a disability, and other aspects are assumed.

The Default in Tech

The other part of the power of the default I wanted to discuss is the default in and with tech. There are lots of occasions where the default selection affects how we operate - and that's often intentional. The creators of services know how the default selections affect us, so they utilize them, often for profit.

Sara Wachter-Boettcher discusses the default settings in her book "Technically Wrong: Sexist Apps, Biased Algorithms, and Other Threats of Toxic Tech." She writes:

Defaults also affect how we perceive our choices, making us more likely to choose whatever is presented as default, and less likely to switch to something else. This is known as the default effect.

And this is exploited often. It can be tip amounts defaulting to one of the higher options or preselecting accepting marketing emails. Or it can be the preselection of the pricing option in the middle when subscribing to a service. Of course, defaults can make our paths on these services faster - sometimes, it's just about that. But unfortunately, often, it's part of a design to profit more.

Sara Wachter-Boettcher also writes about the defaults in voice assistants like Apple's Siri, Google Now, and Amazon's Alexa. The default voice was a woman's for a long time for all of them. Apple switched to a non-woman default voice some major updates ago, but the other two have a woman's voice on by default.

As these voice assistants are, as the name states, assistants, it's as if the default gender for assistant, helper, should be a woman. And with this, I mean in the eyes of the creators.

In general, there's a lot to unpack about these voice assistants. If you're interested, there's a publication about the problematic design of these assistants: UNESCO and EQUAL Skills Coalition: I'd blush if I could: closing gender divides in digital skills through education, specifically the Think Piece 2-chapter.

And as a final example for this section, have you ever paid attention to the default options of forms when, e.g., registering on a service? If they have default options and ask for gender, the preselection is usually "man." And if they ask for other things, it's often one of the abovementioned aspects, which I've mentioned as the default.

Using the Power of Default for Good

The nice thing about the power of default is that we can also utilize it for good. As developers, designers, and in other roles in the tech sector, we can change the defaults to more inclusive options. We can ensure these defaults are not used for discrimination and exclusion.

We can also affect how the technology itself behaves. As Caroline Criado Perez writes in her famous book "Invisible women", we have the data about inequality in our systems. "(but) whether or not coders will use it to fix their male-biased algorithms remains to be seen", she continues. In this case, she was writing about translations and how gender-neutral sentences were translated into English stereotypes - like Finnish "Hän on koodari," which is gender-neutral, would often be translated into "He is a coder."

We have the data about inequality; we have studies; we have what we need. Are we going to work on changing the default, which has for too long been a white, cis-gendered, heterosexual man without disabilities? We have the power to change that. All we need to do is pay attention, educate ourselves, and act.

Oh, and by the way, if you fall into the categories that I described above being the default, and especially if you fall into all of them: You probably can do the most, so I'm counting on you to work towards a more equal world and using your power to do so!

Links in the Blog Post

UNESCO and EQUAL Skills Coalition: I'd blush if I could: closing gender divides in digital skills through education

More Accessible Graphs with Jetpack Compose Part 3: Differentiating without Color

2023-08-16T03:43:44.518Z

This blog post is the third one in my series on more accessible graphs with Jetpack Compose. You can find the previous two from the following links:

The third topic we will cover is differentiating data by other means than color. Color is a convenient way to distinguish data, but what if you can't see color? Or what if you see colors differently? For example, the example project we've been developing during the blog post series would look like this for someone who can't see color at all:

And someone with red-green color blindness:

Another aspect of why not use color alone is that phone screens display color differently. A noticeable difference on a high-end external screen for a designer might be almost the same shades for a lower-end phone, making usage impossible.

There are better ideas than just using color to differentiate data. In the next section, let's explore some of these other ways.

Options for Color

When talking about graphs, there are generally two ways to improve the distinguishability of data: Shapes and patterns. For example, if a bar chart is initially differentiated by color, adding patterns for different colors could differentiate those bars.

For a line chart, both these options are valid. Let's explore both and differentiate the data by adding different shapes for points and some patterns for the line. This solution is not the most beautiful because I'm mixing these two options, but it's there to demonstrate, not to be a final design.

The Code

In the situation we're starting with, the function we're using to draw the data points looks like this:

drawPoints(
    points = pixelPoints.map { Offset(it.x + 20f, it.y) },
    pointMode = PointMode.Points,
    color = color,
    strokeWidth = 8.dp.toPx(),
    cap = StrokeCap.Round,
)

It takes the points and point mode from the parameters, and other than that, everything is defined inside the helper function. In this example, we're interested in the strokeWidth and cap-properties because we're using them to change how the data points are drawn. In addition, we will modify the code for drawing the path between the data points by adding an additional style.

Let's get started with changing the shape of the data points. First, let's add new parameters for the drawData-extension, which encapsulates the data points and line's drawing methods:

fun DrawScope.drawData(
    ...
    strokeWidth: Float = 8.dp.toPx(),
    strokeCap: StrokeCap = StrokeCap.Round
) { ... }

We add two new parameters: strokeWidth and strokeCap, and then set the current values as defaults. Then we use these new properties in the code:

drawPoints(
    ...
    strokeWidth = strokeWidth,
    cap = strokeCap
)

Note: We add these for both of the drawPoints-methods, as there is one for highlighted points and one for all points.

Then, in the Graph-composable, we add the actual differentiation for each data set:

drawData(
    ... // Engineering data
    strokeCap = StrokeCap.Round,
)
drawData(
    ... // ICT-data
    strokeCap = StrokeCap.Square,
)
drawData(
    ... // Total data
    strokeCap = StrokeCap.Butt,
    strokeWidth = 12.dp.toPx(),
)

As we set the defaults, we don't need to pass a value for both parameters if the value is the default value. That's the case for the ICT and Engineering data, as we want to keep the point size the same. Actually, we wouldn't need to pass the strokeCap-value for the Engineering data either for the same reason - but I chose to add it for clarity and to display the different values.

Okay, after these changes, the points look different. For Engineering data, nothing has changed, but for ICT data and total data, the points are rectangular, and the total data has more significant points than the others.

Let's add another differentiator before we look at the results. We want also to be able to distinguish the lines from each other, and one way to do that is by changing the pattern of the line. In this example, we will add a dashed line for one of the data sets.

Let's start with adding another new parameter for drawData:

fun DrawScope.drawData(
    dashed: Boolean = false,
) { ... }

The new parameter is dashed, and it's set to false by default. When it's true, we want to change the style of the path that we're drawing:

drawPath(
    path = path,
    color = color,
    style = Stroke(
        width = 3f,
        pathEffect = if (dashed) 
            PathEffect.dashPathEffect(floatArrayOf(10f, 10f), 0f) 
        else null
    ),
)

We add thepathEffect for the stroke and set it to a dashed path effect with intervals of 10f. If dashed is false, then we don't set the path effect - or we set it to null, which is its default value.

The last thing to do is to pass the value to one of the drawData-functions, and in this case, we pass it to the ICT data:

drawData(
    ... // ICT-data
    strokeCap = StrokeCap.Square,
    dashed = true
)

And with that, we have added both shapes and a pattern. The final implementation looks like this:

You can find the final code from this commit.

Wrapping Up

In this blog post, we have looked at improving differentiating data by other means than color. We've covered adding shapes and patterns by changing the data points in the line chart to have different shapes and adding a dashed pattern to one of the lines.

The fourth post in this series will cover switch devices and how navigation should work with them. Publishing it will take some time - I'll need to find out why it wasn't working with the solution it should have.

Links in the Blog Post

Understanding Density-Independent Pixels

2023-09-04T03:35:42.696Z

I switched to Android development from web front end, and one thing that was a bit hard to understand was how the density of Android screens affects the use of units. For web, I mainly worked with pixels, ems (the computed value of the element's font size), and rems (the computed value of the root element's font size).

So, I wanted to write a blog post about this theme because I bet I'm not the only one. Let's first look at the density-independent pixels, what they are, and why they're used. After that, let's discuss the conversion between them and pixels. I've purposely omitted scale-independent pixels from this blog post to concentrate on density-independent pixels.

What Are Density-Independent Pixels?

Android devices have different sizes of screens. They also have different pixel sizes for a screen - so a certain amount of pixels in, e.g., width, looks different on a screen with fewer pixels compared to one with a lot more pixels. This is because one screen might fit only 320 pixels in the same physical space while the other fits 640 pixels.

Density-independent pixels are here to fix the issues these differences cause. Android documentation defines density-independent pixels in the following way:

To preserve the visible size of your UI on screens with different densities, design your UI using density-independent pixels (dp) as your unit of measurement. One dp is a virtual pixel unit that's roughly equal to one pixel on a medium-density screen (160 dpi, or the "baseline" density). Android translates this value to the appropriate number of real pixels for each other density.

Source: Support different pixel densities - Android Developers

Let's next look at the conversions between real pixels and density-independent pixels.

Conversions Between Pixels and Density-Independent Pixels

There are multiple cases when we need the conversion from device-independent pixels to pixels - and vice versa. Let's look at how we can convert them - first in the scope of Composable components and then in other cases.

Composable Components

With Jetpack Compose, LocalDensity helps with conversions between pixels and density-independent pixels. LocalDensity is one of the built-in composition locals for Compose, and it provides a Density that can be used for conversions between pixels and density-independent pixels, as well as scale-independent pixels.

Let's look at how we can use it in a Composable component. First, conversion from pixels to device-independent pixels:

@Composable
fun PxToDp(widthInPx: Int) {
  val density = LocalDensity.current
  val widthInDp = with (density) { widthInPx.toDp() }
  ...
}

And then vice versa:

@Composable
fun DpToPx(widthInDp: Int) {
  val density = LocalDensity.current
  val widthInPx = with (density) { widthInDp.toPx() }
  ...
}

Both of the examples utilize Kotlin's with-scope function. In the scope of Density provided by LocalDensity, the extension functions for conversion are available, and we can use them.

Other Cases

When not using Jetpack Compose and/or LocalDensity is unavailable, you can, for example, write your own extension functions for conversion. Here's an example with extension functions for Float-datatype:

fun Float.toDp() = 
    (this / Resources.getSystem().displayMetrics.density)

fun Float.toPx() = 
    (this * Resources.getSystem().displayMetrics.density)

In both functions, the device's screen density is fetched from Resources.getSystem().displayMetrics.density. For the pixel-to-dp-conversion, a pixel value is divided by it, and for the dp-to-pixel-conversion, the dp value is multiplied by it.

Wrapping Up

In this blog post, we've discussed device-independent pixels. We also looked at how to convert them to pixels and back. These conversions can be useful in many cases, such as when positioning elements on layouts.

Do you have any examples of when converting between them was needed? Or when it was more complex than you would have wished? Share your thoughts!

CatGPT - or How to Position Elements on Overlays

2023-10-22T03:48:20.410Z

Have you ever wondered how to display an element with an overlay while keeping it in the same position? The same way that, for example, many messaging apps highlight the message you want to react to.

I had this type of challenge in one of my work projects. It took some trial and error to get it working, but I was so proud of myself when I finally found the correct modifiers (and numbers). I want to share one way to do it with you in this blog post.

The Example App

Okay, I must say that I maybe, just maybe, got a little bit carried away with this example app. But it's a CatGPT - a chat client where you can ask anything from a cat. Here's a short video:

This app is simple; It doesn't use any third-party APIs, so the cat in question lives in the code. The app has one Room database, where it stores messages, and it has one screen called ChatScreen which displays messages.

If you want to see the code, the starting point for the app is in the starting-point-branch, and the final code is in CatGPT-repository's main-branch.

Showing Reaction with Message

To simplify this app, each message can have only one reaction. In the Message data class, the reaction is already present:

// data/Message.kt

@Entity
data class Message(
    @PrimaryKey(autoGenerate = true)
    val id: Long = 0,
    val text: String = "",
    val sender: Sender = Sender.ME,
    @TypeConverters(ReactionConverter::class)
    val reaction: Reaction? = null,
)

And it's a nullable Reaction-enum. The complete code and converters for Reaction are in Message.kt.

Let's first add code for showing that reaction before building the actual reaction picker. In the MessageRow.kt-file, there is already a ConstraintLayout, which contains the component for the message. We want to show the reaction in the bottom right corner of that component, so we'll add the reaction inside the constraint layout.

The component for reaction looks like this:

// ui/components/MessageRow.kt

message.reaction?.let {
    Text(
        modifier = Modifier
            .clip(ChatScreen.shape)
            .background(MaterialTheme.colorScheme.surface)
            .padding(MessageRow.reactionPadding)
        text = it.emoji,
    )
}

As the reaction is a nullable string, we first check if it's available with Kotlin's let, and inside its block, we add the reaction as Text-element.

Now, the reaction is visible. We still want to position it correctly, so we'll first add the reaction as a reference for constraint:

// ui/components/MessageRow.kt

// From
val (text) = createRefs()
// To
val (text, reaction) = createRefs()

And then for the Text-component we just added, we'll add the constrainAs-modifier:

// ui/components/MessageRow.kt

message.reaction?.let {
    Text(
        modifier = Modifier
            ...
            .constrainAs(reaction) {
            end.linkTo(text.end, MessageRow.reactionPadding)
            bottom.linkTo(text.bottom)
            },
        text = it,
    )
}

Inside the constrainAs-modifier, we constrain the end of the component to the end of the message text with a bit of padding and the bottom of the reaction to the bottom of the message text. After these changes, the message component with a reaction would look like this:

All the changes for showing the reaction with the message are in this commit.

Alright. Now we're showing the reactions - but to have something to display, there should be a way to add a reaction. We will do it with an overlay with a blurred background and a component that shows the selected message and available reactions.

Getting the Message's Y-Position

We first want to get the y-position of the message component in the conversation to position the element correctly in the overlay we're adding. We can do it by using the onGloballyPositioned-modifier and storing the y-value to a state variable. For that, we also need to know the density of the user's phone so that we can convert between the pixels and density-independent pixels:

// MessageRow.kt

val density = LocalDensity.current
var yPosition by remember { mutableStateOf(0.dp) }

If you're wondering about the need for density or need a refresher on density-independent pixels, I've written a blog post about them: Understanding Density-Independent Pixels.

Okay, now we have what we need to get the actual position:

// MessageRow.kt

ConstraintLayout(
    modifier = Modifier.
        .fillMaxWidth()
        .onGloballyPositioned {
            yPosition = with (density) { 
                it.positionInParent().y.toDp() +
                  MessageRow.reactionDialogOffset + 
                  MessageRow.reactionPadding
            }
        }
) { ... }

We use the .onGloballyPositioned-modifier to get the y-position. positionInParent() returns pixels, and to get the density-independent pixels for position, we use the with-scope function to convert them. We also add a bit of offset and padding to match the position because the original message component has those offset and padding.

After the changes in the previous section, we have the y-position of the message. The next thing we need to do is to create the reaction picker component and pass the y-position to that component. After that, we can actually place the element in the overlay.

The component inside the overlay is a ConstraintLayout, which wraps a MessageBlock that contains a message text, and Reactions, which displays the available reactions. It also has a Box used as overlay/background, covering the whole screen. You can find the complete component from ReactionPicker.kt

Okay, now we have the component, which takes the y-position of the message as a parameter. Let's move on to placing the elements.

Placing Elements on the Screen

To place the message block and reactions correctly within the screen, we use a custom modifier that takes the y-position of the message from the message screen and finds the correct position for the message and reactions:

fun Modifier.positionReactionsPicker(yPosition: Dp) = layout { measurable, constraints ->
    val placeable = measurable.measure(constraints)

    layout(placeable.width, placeable.height) {
        placeable.place(0, yPosition.roundToPx())
    }
}

To accomplish what we want, we use the layout-modifier. It's a lambda with two parameters: measurable and constraints. We first measure the element presented by the measurable parameter (the component on which the custom modifier is called) and store the value in the placeable variable.

Then, we create the layout with measured height and width and place the element with placeable.place(). For the x-value, we use "0" because the component fills the whole width, and we can place it on the left edge of the screen. For the y-value, we use the yPosition passed to the modifier and round it to pixels.

Finally, we call the custom modifier on the ConstraintLayout that is wrapping the message and reactions:

ConstraintLayout(
    modifier = Modifier.positionReactionsPicker(yPosition)
) { ... }

In this way, we have positioned the reactions picker:

Wrapping Up

In this blog post, we've looked at how to position elements on screen. We've done that by getting the y-position of that message and then creating an overlay where we've placed the opened message with the help of a custom layout modifier.

This code is a good starting place visually but has some accessibility problems. Not everyone who uses different assistive technologies can use it, so I will write a second blog post tackling some of the accessibility issues this code has.

Do you have any comments or questions? Please share and/or ask!

How to Add Content Descriptions in Compose - A Guide for Android Devs

2023-11-15T04:09:07.227Z

When it comes to the contentDescription-attribute, I've noticed a couple of things Android devs do that are wrong and make apps harder to use with assistive technology. The first thing I see a lot is setting the content description of an icon to the icon name, such as icon_cat_sleeping. Another thing is suppressing the warnings Android Studio gives about missing content descriptions.

I decided to write about this theme, and in this blog post, you'll learn about content descriptions: the problems and solutions. And yes, you'll understand why those things I mentioned in the previous paragraph are problematic.

Let's start discussing content description, then continue with how to write one, and finally, how to set the content description.

What Content Description Is

When I talk about content description, I mean text alternative. If you have any background in web development or, e.g., using any social media platforms, you might have heard about the word "alt text". They mean the same thing and different environments have different names for this concept.

In Android, the attribute is called contentDescription, and I think that content description is actually a very explanatory name for what we're trying to accomplish with it: describing the content of an image or a graphic.

One thing that's important to remember is who we are describing the content for: Users who utilize the accessibility APIs. This means, for example, screen reader and voice access users. Screen reader users rely on the content descriptions for visual content (that they usually can't see, depending on their sight level), and voice access users can use these values as labels to interact with elements, such as buttons.

Content descriptions should be added for meaningful visual elements like images, icons, and graphs. For some of the elements, it's more straightforward, but for, for example, different types of graphs, it's more complicated. This blog post won't go into details on adding content descriptions for graphs, but I've written a blog post as one example around the theme if you're interested: More Accessible Graphs with Jetpack Compose Part 1: Adding Content Description.

Now, if you've been working with testing tools such as Appium, you might remember adding the test id as contentDescription. Unfortunately, some tools use the so-called "accessibility id," which maps to contentDescription on Android. On iOS, there is a separate property called accessibilityId. This is a problem because content description actually overrides the text value for many elements, meaning that for these elements, a screen reader user would hear the value of a button being button_submit (the id set for testing) instead of the "Submit" that's a text for that button.

I've had to fix issues like this, and my solution was to check that if a screen reader is running, we would set the element's content as contentDescription; otherwise, use that testing id. That is not an optimal solution, but it was the best we could do at the time. And this would fail with some of the automated accessibility checks, even if it works for real screen reader users.

Content Description is not Available for All Users

The content description is invisible to most users. This means that it's not the all-powerful solution to fix accessibility issues.

A common misconception is that adding it as a label to an icon would make it available to every user. But that's not the case - a user who is not using any sort of assistive technology can't see it, nor can someone with, for example, a keyboard. So, it's available just for assistive technologies that utilize the accessibility API underneath - including, but not limited to, screen readers, switch access, and voice navigation.

I want to underline this because many users usually would benefit from things like text labels with icons, but they tend to be dismissed when asking for them because of the abovementioned misconception. I'm one of them, so I've experienced this firsthand.

How to Write a Good Content Description

The actual content for the contentDescription attribute varies, depending on the purpose and type of the element. As mentioned, more complex visualizations are outside the scope of this blog post, so we will discuss meaningful and decorative images. We'll also discuss icons as a separate, unique use case.

One important thing to note is that whenever you write a content description, remember to localize it!

Meaningful Images

What does a "meaningful image" mean? It means any image (or graphic) that has meaning and adds something to the content. It includes icons, and pictures that contain instructions is another good example. The text alternative (so, content description) should contain what the image is trying to communicate.

An image's content description is also affected by the context where the image is. WebAIM has a list of instructions for writing text alternatives:

The alt attribute should typically:

be accurate and equivalent in representing content and function.

be succinct. Content (if any) and function (if any) should be presented as succinctly as possible, without sacrificing accuracy. Typically, only a few words are necessary, though rarely a short sentence or two may be appropriate.

not be redundant or provide the same information as text near the image.

not include phrases like "image of ..." or "graphic of ...", etc. This would be redundant since screen readers already announce "graphic" along with the alt text. If the fact that an image is a photograph or illustration, etc. is important content, it may be useful to include this in alternative text.

Source and read more: WebAIM: Alternative text

Decorative Images

In the previous section, we've talked about meaningful images. Sometimes, illustrations or images are there for purely decorative purposes and don't have any other meaning. In these cases, you should mark the content description as null:

Image(
  ...
  contentDescription=null
)

Now, you might wonder, why not leave it as an empty string? The reason is that when left empty, the accessibility API doesn't get the info that this is decorative and keeps this image in the accessibility tree. This leads to a situation where, when a user encounters that image, they would hear "Unnamed" instead of not encountering it in the first place.

That "Unnamed" is redundant information and can be really confusing. Is that image really decorative, and a developer didn't know how to set it as such? Or is it meaningful, but the developer forgot to add the actual text alternative?

In the Compose world, components like Image and Icon require contentDescription to be set explicitly. However, it was (or, is) possible to leave the attribute out in the View world and XML-layouts.

That would lead to similar situations, with "Unnamed" being announced. This would also create a warning in the Android Studio about missing content descriptions. It's possible to suppress that warning, and I've fixed multiple instances where the warning was suppressed.

So, don't suppress that warning - set the content description to null or provide a descriptive content description, depending on the image.

Icons

As mentioned, icons are a special case. Icons are often used as the only action indicator (like an edit button with just some icon representing editing). I usually have problems with this because of how I process information. I keep asking for text labels but typically don't get them. But this is not a blog post about text labels; it's about content descriptions, so let's move on.

When an icon is the only thing inside a button, it's even more critical to include meaningful content descriptions because it's the text used for the button. So, when a screen reader user encounters a button with an icon that is a quill, they'd hear something like "Button, Edit" instead of "Button, icon underscore quill" if the content description is set to the icon's name. Or, in the case I mentioned in the intro, "Icon underscore cat underscore sleeping." Remember that whatever text you enter there will be what non-sighted screen reader users hear (or read from braille) - they can't see the icon.

So, when adding a content description for an icon, ask yourself if it's used to convey meaning or if it's purely decorative. If it's the latter, use null. Otherwise, describe the action or meaning, not the actual icon. So, usually, an "X" icon represents something like "Close," and a chevron pointing to the left means something like "Back".

How to Set the Content Description

`contentDescription`-attribute

You can set the content description through the contentDescription-attribute for Image and Icon -components. Other components don't have this attribute, so you'll need the help of semantics or clearAndSetSemantics-modifiers.

`semantics` and `clearAndSetSemantics`-modifiers

Both semantics and clearAndSetSemantics modifiers change the element's semantics. The difference is that the first builds on top of existing semantics, and the latter clears all the other semantics.

While Image and Icon components have the contentDescription, other elements, such as graphics created with Canvas, would require using these modifiers. Also another case is text with an emoji - for example, if your app is a chat app with reactions, and you're using Text-element for displaying the reaction, you'd need to set the content description for those Text components.

You can use the semantics-modifier in any element and set the content description within its semantic properties lambda:

Canvas(
    modifier = Modifier.semantics {
        contentDescription = "Put the content description here"
    }
) {
    ...
}

Wrapping Up

In this blog post, we've covered content descriptions, what they are, how to write them, and how you can set them.

Do you have questions? Or comments? Please do ask or share!

Links in Blog Post

Women Developer Academy Europe 2023 - My Experience

2023-11-24T03:44:15.259Z

My October was busy. I spoke at three conferences (droidcon Italy, droidcon London, and KKON, which was an online conference). I had also applied to the Women Developer Academy Europe earlier, and when the acceptance letter arrived at the end of September, I wasn't sure if I could participate. But as you might guess from me writing this blog post, I decided to attend, and it was a great decision! In this blog post, I'll share my experiences with the program.

Women Developer Academy (WDA)

Women Developer Academy is a program from Google, and the event page for our cohort (Women Developer Academy Europe) explains it in a nutshell:

The Women Developer Academy is a specialized program for female developers, aimed at increasing the diversity of speakers at tech events in the region, focusing on creating an inclusive community of speakers and mentors who can support each other.

The program consisted of weekly sessions, the I Am Remarkable workshop, mentoring, and a mini-conference with 5-minute talks. I'll share a bit more about them next.

Sessions

The program had 2-3 evening sessions each week. The topics for the meetings were about public speaking, applying to conferences, online branding, and many other related topics. Many of those topics were familiar, as I've spoken at many conferences, but I also learned new things.

For me, living in the eastern side of Europe in Finland, these meetings started at seven in the evening. It's not an optimal time for someone who is definitely a morning person, and needs their wind-down time in the evening. But I was so happy that we got the sessions as recordings and could watch them later!

I Am Remarkable-workshop

The WDA program included a I Am Remarkable workshop. The website describes the movement behind this workshop:

#IAmRemarkable is a global movement that empowers everyone to celebrate their achievements in the workplace and beyond.

I've heard of this workshop but never got to attend one. I can see the need for such workshops - especially within minority groups in tech. It's so easy to forget or not see the accomplishments, and this workshop is a great time to dedicate some time to acknowledging and celebrating them.

We spent one Saturday afternoon talking about ways we are remarkable, and how self-promotion matters. I can share a couple of sentences I wrote during the workshop:

I am remarkable because I care and know a lot about accessibility.

I am remarkable because I dare to question inequality.

I am remarkable because I'm really good at what I do.

Mentoring

The third part of the program was mentoring. The minimum number of mentoring sessions to graduate from the program was 4. To be honest, I didn't have time to even think of having more mentoring sessions. I wish I had more time, but it is what it is.

I had four interesting mentoring sessions, and we discussed many different things related to accessibility, speaking at conferences, and the GDE program, to name a few. A huge thanks to Piotr Prus, Sabrina Jodexnis, Nourhan Gehad, and Carlos Mota!

Mini-Conference

In the last session before graduation from the program, we had a mini-conference where everyone could talk for 5 minutes about a topic they're interested in. The timing wasn't optimal for me - I had a flight to London the next day, but luckily, I got to present my talk second in order.

I spoke about Android developers and the challenges we face regarding accessibility. The talk was based on a blog post I've written: Android Developers and Accessibility - Challenges and Proposed Solutions. Five minutes is a really short time, and the amount of content was almost too much for that time. I had to skip introductions to fit everything in.

I got good feedback, but it was interesting that some people said they liked my slides that had almost nothing on them - and some said that I should add, e.g., pictures. It is an excellent example of how we all are different - some like more simplistic slides, and others want more visual ones.

Final Thoughts

Despite having a really busy October, I am happy I got accepted into WDA and decided to participate. I met amazing people, made connections, and learned new things.

So, if you are in the target group of this program, and whenever it opens in your area, I highly recommend applying!

Links in Blog Post

More Accessible Graphs with Jetpack Compose Part 4: On-Screen Control Buttons

2023-12-09T10:34:40.289Z

This blog post is the fourth one in my series on more accessible graphs with Jetpack Compose. You can find the previous three from the following links:

Continuous (or path-based) pointer input, like drag-gesture, might be problematic for some users. For example, if a user has tremors in their hands, the gesture is not always continuous, and if the app relies on this kind of gesture to work, it may be unusable for these users.

Now, if you have followed this blog post series, you might wonder - hey, we added keyboard interaction; isn't that enough? No, it's not - it would require a physical keyboard. Many users don't use a physical keyboard, even if they could benefit from it.

So, in this blog post, we'll add on-screen controls to the graph. The best part is that this solution also solves the issues with a switch device I mentioned at the end of the blog post about keyboard interaction! Head to the paragraph about Switch Access for more in-depth explanations.

Adding Buttons

So, one way to solve this problem with path-based gestures is to add visible buttons as an alternative way of navigating inside the graph. In the case of this graph, we want to add two buttons: One for going forward and another for going backward. This is what the UI will look like once we add the controls:

We add a new component, called ControlButtons that wraps these buttons:

@Composable
fun ControlButtons(
    highlightedX: Float?,
    lastIndex: Int,
    setFocus: (Int) -> Unit
) {
    ...
}

It takes three parameters: highlightedX, which is the currently highlighted year on the x-axis, lastIndex, which is the last year's index, and a function called setFocus, which takes in an integer - the index where the focus should go next - and returns Unit. This is what it looks like when we call it in the parent component:

ControlButtons(
    highlightedX = highlightedX,
    lastIndex = pixelPointsForTotal.count() - 1,
) { selectedIndex ->
    highlightedX = pixelPointsForTotal[selectedIndex].x
}

So, we pass in the highlightedX that we have been using to define the currently highlighted year, the last index for pixel point lists, and then, in the lambda block, we take in the new selected index and set the highlightedX to the x-value in the pixel point list in that index.

Let's get back to the ControlButtons composable. At the beginning of the composable, we'll define two things:

// ControlButtons

var selectedIndex by remember {
    mutableStateOf(-1)
}

fun setSelectedIndexAndFocus(newIndex: Int) {
    selectedIndex = newIndex
    setFocus(newIndex)
}

First, we want to store the currently selected index to a selectedIndex variable, remember it and set the initial value to -1 as there is no index selected initially. We'll also want a function to set a selected index and focus to update the state within the component, and set the new highlighted year (or, x) on the parent component, as we saw a couple of paragraphs ago. We call it setSelectedIndexAndFocus.

After that, we'll have everything we need in that component to create the actual buttons. As they're pretty similar, we'll make a new component called ControlButton that takes in type (we'll talk about it a bit later), currently selected index, last index, first focus index (so, where the focus should go first when pressing this button if nothing is selected), highlighted X value, and a function to set the focus:

@Composable
fun ControlButton(
    type: GraphControlType,
    currentIndex: Int,
    lastIndex: Int,
    firstFocusIndex: Int,
    highlightedX: Float?,
    setFocus: (Int) -> Unit,
) {
...
}

To make the function a bit more abstract in order to work for both the next and previous years, I made an enum called GraphControlType:

enum class GraphControlType {
    Next {
        override val icon = Icons.Filled.ArrowForward
        override val textResId = R.string.button_next_year
    },
    Previous {
        override val icon = Icons.Filled.ArrowBack
        override val textResId = R.string.button_previous_year
    }, ;

    abstract val icon: ImageVector
    abstract val textResId: Int
}

This enum contains the icon we want to use and the resource id for the text in the button.

As mentioned, the idea of the button is that it moves the focus to the next year when pressed. If it's the "next year" button, it would go forward from last year to the first one. If it's the "previous year" button, it would go backward; when it's in the first year, it would go to the last year.

We have helper functions for getting the next index (or, year) to focus (you can see them in the commit containing all the changes), and we want to define which one to use, depending on the type that we passed:

// ControlButton

val nextIndexFunc = when (type) {
    GraphControlType.Next -> ::getNextIndex
    GraphControlType.Previous -> ::getPreviousIndex
}

Now that we've defined everything, we'll add the button:

// ControlButton

OutlinedButton(onClick = {
    val newSelectedIndex = when (highlightedX) {
        null -> firstFocusIndex
        else -> nextIndexFunc(currentIndex, lastIndex)
    }

    setFocus(newSelectedIndex)
}) {
    if (type == GraphControlType.Previous) 
        ControlButtonIcon(icon = type.icon)
    Text(stringResource(id = type.textResId))
    if (type == GraphControlType.Next) 
        ControlButtonIcon(icon = type.icon)
}

So, in the onClick handler of the button, we check if the highlighted x-value is null, and if it is, then we move the focus to the first focus index, which is the first index for the "next year" button, and the last index for the "previous year" button. Otherwise, we'll use the defined nextIndexFunc to get the next index where the focus should go. Once we have the index, we call the setFocus-function with that index.

In the content of the button, we use the type to define the placement of the icon - for the "previous year" button, it's before the text, and for the "next year" button, it's after the text.

The final thing is to add the controls to the ControlButtons-composable. We want them to be on the same row, so we wrap them with the Row-component. I've left out some modifiers for clarity:

// ControlButtons

Row(...) {
    ControlButton(
        type = GraphControlType.Previous,
        currentIndex = selectedIndex,
        lastIndex = lastIndex,
        firstFocusIndex = lastIndex,
        highlightedX = highlightedX,
        setFocus = {
            setSelectedIndexAndFocus(it)
        },
    )
    ControlButton(
        type = GraphControlType.Next,
        currentIndex = selectedIndex,
        lastIndex = lastIndex,
        firstFocusIndex = 0,
        highlightedX = highlightedX,
        setFocus = {
            setSelectedIndexAndFocus(it)
        },
    )
}

Okay, now we have added the controls. Here's a video of how they work:

You can find the final code from this commit.

Switch Access

The initial implementation for keyboard access did not work on a switch device. When I was testing it with the switch, I noticed that the focusable elements are not available to the API a switch device uses, so the implementation did not work. I don't know why this happens; I haven't had time to investigate it further, but if anyone knows more about the technical details behind this behavior, I'd be glad to learn more!

This is also an excellent example of why you must test with different assistive technologies. Assuming that something works without testing might lead to some inaccessible code.

So, you might wonder what the app now looks like for a switch device user. I recorded a short video:

As you can see in the video, adding these buttons allows a switch device user to change the highlighted year and see the percentages for each year.

Considerations

This implementation has some considerations from the accessibility point of view. If I had started with these controls, I would probably have built the whole graph a bit differently from a screen-reader and keyboard user perspective, but this time, I was building on top of the previous blog posts, so that was a constraint. I'll share some concerns about this implementation and the reasoning behind my decisions.

Non-Descriptive Buttons

First, the buttons in the UI have text content saying "Next year" and "Previous year," and when a screen-reader user presses those buttons, nothing happens, especially if they're non-sighted or have turned the screen off. This is because even though we move the currently selected year, we don't move the accessibility focus. Or focus at all, for that matter.

If I had added the button controls first, I would probably have made the Labels component, which contains the selected year's values, into a live region. That way, every time the content changes when the year changes, the content would have been announced.

Also, I could have added that to this version, but I wanted to keep this blog post as simple as possible. Also, if a user navigates linearly, they would first encounter the graph and the data before hitting the buttons. That way, there would be context for buttons and a way to navigate through the years. If they are not navigating linearly, then the situation can be different, depending on the mode they're using.

Additional Tab Stops

Another consideration is that this implementation creates additional tab stops for a keyboard user. It's only two, but if every time you press a key is painful, those two can be too much.

In this case, a similar implementation I described for screen-reader users would also be better for keyboard users. That would reduce a lot of tab stops from the graph and replace them with just these two buttons. Of course, a button needs to be activated with a keypress, so there's that.

Wrapping Up

In this blog post, we've looked into how to add visible controls for navigating the graph. This approach has solved issues for those who might have trouble with path-based gestures or use a switch device. We've also looked into some considerations this implementation has related to screen-reader and keyboard navigation.

This blog post series has provided two approaches to solving issues with pointer input-based graph navigation so far: Adding an overlay and focusable areas on top of the years in the graph and adding control buttons. As every app and use case is different, you might need one or both of them to make your graphs more accessible - or, in some cases, a different type of solution can be the answer.

Links in Blog Post

How My App Won the 2nd Place in the WWCode App Deploy Hackathon

2023-12-14T04:01:55.939Z

A few weeks ago, I participated in my first mobile hackathon; it was so much fun! This hackathon was also the first more traditional (so, just over the weekend) for me and the second in general. The first was the Github Actions hackathon in 2020, organized by Dev.to, and it spanned throughout weeks.

The hackathon I participated in was App Deploy Hackathon from Women Who Code, and the goal was to build an Android app and use any of the Google APIs available. WWCode organized the hackathon in partnership with Google Play.

I can already share that I won second place in the hackathon! You can read more from Women Who Code's Winner announcement blog post.

I'll share my journey from planning to submission in this blog post. You'll also find links to the code and a video demonstrating the app. I haven't yet published the app in Google Play because there was not enough time to jump through all the hoops, but I will probably release it sometime at the beginning of next year.

Planning for the Hackathon

I registered for the hackathon about two weeks before the event. Those two weeks were hectic, but I had some time to think about the hackathon app idea. I spent quite a bit of time with the Google API Explorer and tried to come up with some ideas.

I came up with two more concrete ideas: a menstruation-tracking app with the features I'd love to have with Google Health Connect, or an app for documenting accomplishments and wins at work and generating a text for a performance review cycle from those items. That second one would use the PaLM API (or so I thought).

When the start of the hackathon came closer, I decided to go with the second idea. I researched and had my building plan (or the general lines) ready for action.

The Story Behind the App Idea

The app idea was something that had been on my mind for a long, long time. Someone shared Julia Evans' blog post "Get your work recognized: write a brag document" a long time ago, and I loved the idea. I have often started writing my brag documents, but I have always forgotten about them because they have been in forms I don't use that much, like Google Docs or other similar solutions.

So, I wanted to build an app for that - maybe I'll remember it better if I see the application icon on my home screen. That remains to be seen, but now I have an app I can use.

Building the App

Finally, the hackathon started. I live in Finland (UTC+2), and the event times were in Eastern Time (UTC-5), so for me, the building started only on Saturday morning.

I'm an Android developer and had a good idea of what architecture components I'm using, so I got the basis of the app built and running relatively quickly. Then, it was time to start implementing the actual things that the app does. Everything went smoothly until I was about to integrate the PaLM API into my app.

Need to Switch the API

As I mentioned, I had already planned to use the PaLM API and Vertex AI in the app. I started integrating it, had everything I needed for it to work, and... I got an error that it's not yet available in Finland. I had forgotten to check its availability - like, it's available in many countries, so Finland must surely be one of them. Well, it was not.

My solution relied on some sort of text generation, and the hackathon rules also said that I'd need to use a Google API as part of the app. I didn't have time to start over, so I had to come up with a solution.

I went for a walk to clear my head and returned to my computer with a plan. I'd use Open AI's Chat Completions API for text generation and Firebase Crashlytics as the Google API.

After trial and error, and some prompting, I integrated the Chat Completions API into my app. I felt so great the first time I got the generated text on my screen - a moment I'll definitely store in my memory and my BragDoc app.

Integrating Crashlytics

The other thing I needed to add was Crashlytics. I was surprised at how easy it was - I usually encounter some problems when following instructions, but everything went smoothly this time.

It might have something to do with the fact that I've added Firebase Notifications to an app before, and back then, I had a lot of problems. Nothing seemed to work. That was until I realized that I had added the google-services.json to the wrong folder as I had added it manually. This time, I used the helper in Android Studio, and let me tell you, that went smoothly.

The MVP of the App

The idea of the application is simple: There is a screen where you can add your wins and accomplishments throughout the year. You can see them listed on that screen and delete them if needed - meaning there is no edit option.

There is also another screen for generating a summary of your accomplishments. It takes all the achievements not part of a summary yet and generates a short-ish summary from them with the help of OpenAI's Chat Completions API. You can see all the generated summaries on the same screen.

Here's a video of the app:

https://www.youtube.com/watch?v=UnFLjTYSkeE

Submission

The deadline for submission was on Monday (or, in my time, early Tuesday morning). As I had to work on Monday, I had to get the submission as ready as possible before I started working. That was a busy morning - I had to quickly create all the assets I'd need, the video for the submission, and decide if I wanted to add a possibility to download the app.

At this phase, all the skills I have with Figma and the VN video editor came in handy - without some prior knowledge, I'm not sure if I would have been able to submit everything in time. I'm still slightly unsatisfied with the video, but it is what it is.

I wanted to get the app to the Play Store, but if you've ever submitted anything there, you know it requires time. There are so many questions to answer and checks to complete. I had to rule that option out, and I started wondering what I could do.

Luckily, I was logged in to the Firebase console and noticed a link, "App distribution." I started reading about it and realized that this is exactly what I need. A few moments later, I had the app available through there and could add a link to it to my hackathon submission.

I got it in in time and was so happy and proud. I had started developing something and had made the MVP out of it. It's not perfect, and I could improve many things, but I finished it in time.

Winner Announcement

On the morning of December 7th, I opened my email and found a message from Women Who Code congratulating me on being one of the hackathon's winners. I was so happy and honored!

I also want to congratulate the other winners - Marissa Campa with RecipeApp — A Recipe Finder, and Melike Altin, Arzu Caner, Ezgi Efe, and Yagmur Baran Karakus with Travel Brew!

Final Thoughts and Link to Code

I'm proud of myself for completing this MVP of the hackathon app and being one of the winners. I also did well with the scoping of the app. It's so easy to start building an app that's too big for the time constraints of the hackathon and get lost in different features. A weekend is a short time (especially when you're making something alone), so it needs to be scoped well if the goal is to get something done.

If you want to see the application code, you can find it in my BragDoc-repository in Github. I will improve and publish the app in the Play Store later, so stay tuned! I will share about it on my socials, so if you want to get your hands on it, follow me on LinkedIn (Eeva-Jonna Panula) or Mastodon (@eevis@mas.to).

Links in the Blog Post

Year in Review - 2023 Edition

2023-12-29T04:37:41.528Z

Another year, another Year in Review blog post! When I started listing things from 2023, I realized a lot had happened. And I probably don't even remember everything.

I've written similar posts before, and you can find them from:

Accomplishments

There are so many things I've accomplished this year. One of them is surviving through the year. It has been one of the most challenging years so far. But more about that later.

My latest accomplishment was winning 2nd place in the WWCode App Deploy hackathon. I was so proud of the app, and even more proud when I got the letter that they selected my app as second best. If you want to know more about the app, I wrote a blog post: How My App Won the 2nd Place in the WWCode App Deploy Hackathon.

Another thing I want to mention was completing the Women Developer Academy in October. I'm so happy about meeting all the people and getting to know them. I also can't wait for all the future conferences and other events where we'll meet in person! I wrote a blog post about my experiences: Women Developer Academy Europe 2023 - My Experience

During the fall, we organized a study group for learning Android with my colleague at Oura. It was for a Finnish organization called Mimmit Koodaa (Women Code would be the literal translation), and we got a great group of Android newbies joining us throughout the months. Even though fall turned out to be full of events and other things, I'm happy that we got to organize this study group.

Another notable thing is that I was a guest on two podcasts: Tech Talks with Madona and Women Who Code podcast. It was so fun to record both of them! I recommend checking both podcasts out (not just the episodes I'm in); there are so many gems in the episodes.

Finally, I'm Dev Top Author for the second year in a row! Dev has always been a dear community to me, as it has been so welcoming and inclusive, so this is an honor.

Speaking

In 2023, I did more in-person talks than last year. Most of the engagements were conferences, with a couple of meetups.

Conferences:
- Android Worldwide
- Women Who Code Dev Summit - Mobile & Web
- Droidcon Italy
- KKON
- Droidcon London
- Saavuta 2023
Meetups
- Aurajoki Overflow
- Accessibility Morning Mixer

I also had to cancel two talks: RN EU and DevFest Stockholm.

Even though I enjoyed every talk I gave, the most meaningful were Droidcons. Those were both in person, and I got to travel to Turin and London, both for the very first time. Meeting everyone there made me really feel like I'm part of the Android community. And as they were in-person conferences, that facilitated some very interesting discussions.

And there was one more thing: I've struggled a lot at work, feeling like I'm not seen as the professional I am, so being a speaker and having all those conversations felt great.

Even though I didn't give that many talks last year, I'm happy about the ones I gave. So, it was a good year in terms of speaking.

Writing

2023 was alright from a writing perspective. I published 16 blog posts and found new mediums, like Medium (pun intended). I mainly wrote about Android-related topics, with some more career or inclusion-related posts.

I started publishing on Medium, and many of my posts were published on ProAndroidDev-publication. One of my posts also got boosted by the Medium team, which was a pleasant surprise.

Many newsletters featured my blog posts, which was also nice. I made it to Dev's week's top 7 list twice, first with my #WeCoded-post "The Language We Use Matters" and then with my recent post "How My App Won the 2nd Place in the WWCode App Deploy Hackathon".

Here are some personal favorites:

Improving Android Accessibility with Modifiers in Jetpack Compose

Published at July 11th

Read the post Improving Android Accessibility with Modifiers in Jetpack Compose

I wrote about using Jetpack Compose's modifiers to improve accessibility. In the blog post, I cover four modifiers: clickable, toggleable, selectable, and magnifier. This post is also something I've turned into a talk; for example, I gave a talk by the same name and contents at Droidcon Italy.

Sometimes I Feel Like I'm Invisible - Experiences of a Woman in Tech

Published at February 5th

Read the post Sometimes I Feel Like I'm Invisible - Experiences of a Woman in Tech

Another personal favorite is this blog post about how I sometimes feel invisible as a woman in tech. In the post, I wrote about personal experiences and microaggressions in general. I wrote it after some events at work, but it wasn't just about those events - it's something I've been feeling my whole career.

More Accessible Graphs with Jetpack Compose Part 4: On-Screen Control Buttons

Published at December 9th

Read the post More Accessible Graphs with Jetpack Compose Part 4: On-Screen Control Buttons

This blog post was fun to write. Or, rather, to build. In the series of blog posts about more accessible graphs, I've been improving a line graph, and this blog post adds on-screen control buttons for easier navigation. It was also the blog post that got boosted by the Medium team.

Other Things

Of course, this year has been about more than just writing, talking, and accomplishments. It's not a secret that this year, once again, has been a fight with burnout for me. I wish I could tell you a story about how I was burnt out and re-discovered myself, and now I'm one of those success stories out there.

No, the story is way more boring and closer to reality for many living with burnout. There have been better times, and there have been worse times. I wish taking sickness leave would solve this, but it hasn't, so here we are, trying to solve the problems at work that cause this. And it doesn't help that because of the brain injury I had, I'm more prone to burnout than some others.

But this year hasn't been all bad either! I cherish many beautiful moments - like when I went kayaking in spring to one of the Finnish national parks (Kolovesi), home to the Saimaa ringed seal. I saw many of them from a distance, but when I unpacked my kayak on the dock at the end of the trip, I heard a sound behind me. I turned around, and I saw that there had been something big. A large fish, I thought to myself and continued unpacking.

Then I realized that someone was staring at me from the other side of the dock. It was Saimaa ringed seal! I slowly tried to get my phone to get a picture, and right before I was ready to take the photo, the seal just looked at me with those side-eyes (you know, the same that dogs do often) and slowly disappeared to the water. So, no, I didn't get a photo. But the memory will live forever.

Another notable thing from 2023 was that I started writing my master's thesis. It's about Android developers and how to help us to make more accessible apps. I plan to finish it by summer. I'm taking part-time study leave for that, but we'll see what the spring brings. I've learned to not to plan too strictly.

I've tried to develop new hobbies to improve my recovery outside work, and I started golf. First, going to the green card course was just to be able to join my sister when she's playing, but I kind of fell into a rabbit hole, and now I'm taking lessons during winter to improve my game, and I can't wait for the snow to melt to get to play.

What About 2024?

I'm not making many promises for 2024 either (as I didn't do last year), but I hope to finish my master's thesis and graduate next year. I also hope to find balance and write a different type of year in review a year from now.

There are also some longer-term dreams, like writing a book. I've been dreaming about it for a long time, and the time to make that dream come true is closer than it used to be. But first, I really need to finish that master's thesis.

Overall, I hope 2024 will bring peace, time with old and new friends, a lot of time spent outside, and lots of new learnings.

I wish you a better year in 2024!

Links in Blog Post

Exploring Health Connect Pt. 1 - Setting Up Permissions

2024-01-12T08:49:31.417Z

I've been really intrigued to try out Google Health Connect and build an app that utilizes it. When I started thinking about what I'd make, I realized that the one thing that I would need is a custom period tracker.

There are some apps to track your menstruation, but they're usually pretty complex, and most require an account. And when all I want to do is track the times when I'm bleeding, I thought I could build my own app.

Also, many of these apps are often so freaking heteronormative that I don't want to use them. What if I don't have just (CIS) men as potential partners? What if I don't need to care about possible pregnancy? What if I only want to track when I'm bleeding?

Also, why are these apps often colored pink? And why do they (almost) always assume it's women using these apps? Some non-binary folks and trans-men menstruate, too, you know. And yes, some apps are more inclusive than others. However, it is still frustrating how many apps make these assumptions about people who menstruate.

So yes. I decided to build my own app. I'm also writing a couple of blog posts that will share the steps I took to make the first version of my period-tracking app. Even though I'm writing about the menstruation-related Google Health records, these same steps apply to other records.

In this first blog post, I'm sharing how to set things up and ask for permission from the user. The following blog post (published next week) will be about writing and reading data from Health Connect. After these two posts, the app I'm building will look like this:

Before diving into the coding, let's discuss Health Connect a bit.

What is Health Connect?

Health Connect is a way to share data between apps on Android. It provides a centralized way to handle health and fitness data, giving users control over which apps they want to share their data. You can learn more from Health Connect by Android site.

As Health Connect is related to sensitive data, you must fill out a form to use it in production. I'm not pushing this app to production anytime soon, so I have yet to check that procedure out. You can read more from the "Request access to Health Connect data types"-documentation.

Starting Point for the App

So before I started implementing integration to Health Connect, I built the UI ready. The app is simple: It has one screen that lists all the periods and a dialog to pick the start and end dates. Here's a picture of the UI:

The code from where we're starting to build this is in the start-branch.

Setup

To be able to use Health Connect, we need to do a couple of things: Add necessary dependencies, add required permissions to AndroidManifest, and ask permission to use Health Connect data from the user. Let's start with the first two.

Add Dependencies and Permissions to AndroidManifest

A separate Health Connect client is available, and we need to add it to module-level build.gradle.kts. By the time of writing this blog post, the latest version is 1.1.0-alpha06, but be sure to check the latest release from Jetpack library versions.

So, let's add this line to module-level build.gradle.kts:

// build.gradle.kts

implementation("androidx.health.connect:connect-client:1.1.0-alpha06")

We also need to add the permissions to AndroidManifest. The following two lines are enough as this application only reads and writes menstruation-related data. They go just before the <application>-element.

// AndroidManifest.xml
<uses-permission 
    android:name="android.permission.health.READ_MENSTRUATION" />
<uses-permission 
    android:name="android.permission.health.WRITE_MENSTRUATION" />

You can read more about the permissions for each record Health Connect provides from the documentation's "Permissions"-section.

Ask for Health Connect Permissions

The next thing to do is ask the user for permission. In the context of this app, we want to read the data when the user opens the app, so we need to ask for permission when the user opens the app for the first time (or any time if the permissions are not granted).

We could implement a second check for writing permissions when the user wants to save data to Health Connect. However, I'm trying to make things straightforward, so in this app, we'll ask for both writing and reading permissions simultaneously, and the user needs to give them both to be able to use the app.

So, let's start by adding an intent-filter to MainActivity in AndroidManifest so that we can actually open the permissions dialog:

// AndroidManifest.xml

<intent-filter>
    <action 
        android:name="android.intent.action.VIEW_PERMISSION_USAGE"/>
    <category 
        android:name="android.intent.category.HEALTH_PERMISSIONS"/>
</intent-filter>

Without these two, the permission dialog won't open. In a production app, you'd probably add a privacy policy screen, and these intent filters would be part of that activity. Read more in Show privacy policy section in Health Connect documentation.

Next, let's create a new file and name it HealthConnectManager. It will serve as a connection point to Health Connect. Inside the file, we declare a class and pass it context as a parameter:

// HealthConnectManager.kt

class HealthConnectManager(private val context: Context) {
  ...
}

To be able to ask for the permissions, we need three things inside the class:

// HealthConnectManager.kt

private val healthConnectClient by lazy { 
    HealthConnectClient.getOrCreate(context) 
}

suspend fun hasAllPermissions(): Boolean = 
    healthConnectClient
        .permissionController
        .getGrantedPermissions()
        .containsAll(PERMISSIONS)

fun requestPermissionsActivityContract(): ActivityResultContract<Set<String>, Set<String>> {
    return PermissionController
        .createRequestPermissionResultContract()
}

We store the healthConnectClient we use later as a private variable and lazily initialize it. We're also implementing a check for permissions we need and getting the activity result contract.

In addition, we define the permissions we need as a separate variable. In the case of this app, and at this point, we need just two:

// HealthConnectManager.kt

val PERMISSIONS =
    setOf(
        HealthPermission
            .getReadPermission(MenstruationPeriodRecord::class),
        HealthPermission
            .getWritePermission(MenstruationPeriodRecord::class),
    )

The view model is another layer we'll need to define between the API and UI. The view model needs an instance of HealthConnectManager, which we pass in as a parameter.

We also define a variable to store whether the app has all permissions, a variable to store the permission launcher, and a function to check the permissions.

// PeriodViewModel.kt

var permissionsGranted by mutableStateOf(false)

val permissionsLauncher = 
    healthConnectManager
        .requestPermissionsActivityContract()

private fun checkPermissions() {
    viewModelScope.launch {
        permissionsGranted = 
            healthConnectManager
                .hasAllPermissions()
    }
}

Now, we have all we need to implement the permission check. In MainScreen-composable, we'll define the actual launcher with rememberLauncherForActivityResult, and pass in the permissionsLauncher we defined in the view model:

// MainScreen.kt

val permissionsLauncher =
    rememberLauncherForActivityResult(
        viewModel.permissionsLauncher
    ) {
    // TODO
}

We will fetch the records in the next blog post in the TODO-block.

After that, we use LaunchedEffect to check if the user has given permissions:

// MainScreen.kt

LaunchedEffect(Unit) {
    if (viewModel.permissionsGranted) {
        // TODO
    } else {
        permissionsLauncher.launch(PERMISSIONS)
    }
}

Here again, the TODO-block is where we'll call the function to get records.

With these changes, the app will prompt the user to give the necessary Health Connect permissions, as seen in the video at the beginning of this blog post.

What If User Doesn't Give Permission?

There is just one more thing in the context of this blog post. What if the user doesn't give Health Connect permissions to the app? Or what if they accidentally press cancel when the permission screen is prompted?

We'll need to add a possibility to re-ask the permissions. In the LazyColumn in MainScreen, let's add an item with a Button conditionally as the first thing in the column if the user has not granted permissions:

// MainScreen.kt 

if (viewModel.permissionsGranted.not()) {
    item {
        Button(onClick = {...}) {
            Text("Give permissions to Health Connect")
        }
    }
}

This button would be visible only when the permissions are not granted.

When the user presses the button, the settings for Health Connect should open. The following code does that:

// MainScreen.kt

Button(
    onClick = {
        val intent = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
            // HCM is an import alias for HealthConnectManager from the Health Connect client
            Intent(HCM.ACTION_MANAGE_HEALTH_PERMISSIONS)
                .putExtra(
                    Intent.EXTRA_PACKAGE_NAME, 
                    context.packageName
                )
        } else {
            Intent(
                HealthConnectClient.ACTION_HEALTH_CONNECT_SETTINGS
            )
        }
        startActivity(context, intent, null)
    }
) { ... }

In the onClick-handler, we first check if the user has Android 14 (SDK-version 34), as Health Connect permission management is slightly different starting from that version. If the answer is yes, we set the intent to be HealthConnectManager.ACTION_MANAGE_HEALTH_PERMISSIONS with the extra of the package name to open the dedicated Health Connect permission management screen.

If the user has an earlier version, then the intent is HealthConnectClient.ACTION_HEALTH_CONNECT_SETTINGS, the general Health Connect settings page.

You can find all the changes done in this blog post in this commit: Add Health Connect Permissions

Wrapping Up

In this blog post, we've been looking at how to set up things for Health Connect and how to ask for the permissions from the user. As I'm building this app for my personal use, there might be some corners I've cut, so be sure to check the official documentation if you're building an app that uses Health Connect in production.

The next blog post will be about reading and writing data, as well as updating and deleting it. So stay tuned; I will publish it next week!

Links in the Blog Post

Exploring Health Connect Pt. 2 - Reading and Writing Data

2024-01-19T04:22:38.527Z

I've been building a period tracking app for myself with the help of Health Connect. Last week, I published the first blog post where I explained how to set up Health Connect and asked the user to give permission to use their data.

I initially thought I'd write one blog post about building this app - now, it's turning into (at least) three. But I have to say that I've enjoyed this process a lot.

This blog post will look into reading and writing data with Health Connect. There will be one more blog post about updating and deleting data before we get to the point where the app looks like in this video:

Reading and Writing Data

Before going into code, I want to mention one handy app: Health Connect Toolbox. With its help, you can write and read data from Health Connect, which helps debug issues like if the data was saved at all. Trust me, I know.

Health Connect Toolbox also helps with the first task we're looking into: Reading records. If you don't have any other app writing that particular type of data to Health Connect, you can use the Health Connect Toolbox to write data and then see that data in your own app.

Now, we have the permissions to read and write data from/to Health Connect, so we can add the implementation for those actions.

Read Records

The first action we're implementing is reading data. Let's start from the closest point to Health Connect: HealthConnectManager, which we defined in the previous blog post. We need a function to read data from Health Connect:

// HealthConnectManager.kt 

suspend fun readMenstruationRecords(): 
    List<MenstruationPeriodRecord> {
        val request = ReadRecordsRequest(
            recordType = MenstruationPeriodRecord::class,
            timeRangeFilter = 
                TimeRangeFilter.after(
                    LocalDateTime.now().minusMonths(12)
                ),
        )
        val response = healthConnectClient.readRecords(request)
        return response.records
}

First, we define the request, which is ReadRecordsRequest. The type is MenstruationPeriodRecord::class, as we want to read menstruation period data from Health Connect. We also add a time range filter going back 12 months from today. This end date will probably be changed while developing this application, but for now, let's stick with data from the past 12 months.

Next, we call readRecords from the Health Connect Client. It returns a response with records as one of its values, and we want to return those from this function.

In the view model, we need to make a few more adjustments. Basically, we want to add a wrapper that checks if the app has all permissions to try to read (or write) data. We also need to add the actual data reading function, as well as store the read data to a variable in the view model.

Let's start with the wrapper and add the function:

// PeriodViewModel.kt

private suspend fun tryWithPermissionsCheck(
    block: suspend () -> Unit
) {
    permissionsGranted = 
        healthConnectManager.hasAllPermissions()
    try {
        if (permissionsGranted) {
            block()
        }
    } catch (remoteException: RemoteException) {
        Log.e("Error getting records:", "${remoteException.message}")
    } catch (securityException: SecurityException) {
        Log.e("Error getting records:", "${securityException.message}")
    } catch (ioException: IOException) {
        Log.e("Error getting records:", "${ioException.message}")
    } catch (illegalStateException: IllegalStateException) {
        Log.e("Error getting records:", "${illegalStateException.message}")
    } catch (e: Exception) {
        Log.e("Error getting records:", "${e.message}")
    }
}

It's a suspend function that takes in a block that will be executed if the app has permissions. First, we check the permission situation from the Health Connect Manager and store the value to the permissionsGranted variable we defined in the previous blog post.

Then, if the permissions are granted, we try to execute the block we're passing in. There is also a somewhat granular exception handling - for this app, for now, it's just logging the errors, but this would be the place to handle errors in other ways, too.

Now that we have permission checks in place, we can read the Health Connect records and store them in the view model.

// PeriodViewModel.kt 

var periods by mutableStateOf<List<MenstruationPeriodRecord>>(emptyList())

fun getInitialRecords() {
    viewModelScope.launch {
        tryWithPermissionsCheck {
            getPeriodRecords()
        }
    }
}

private fun getPeriodRecords() {
    viewModelScope.launch {
        periods = healthConnectManager.readMenstruationRecords()
    }
}

In this block of code, we first define the periods-variable as a mutable state and list of MenstruationPeriodRecord. Then we define the getInitialRecords-function, which uses tryWithPermissionsCheck on calling getPeriodRecords, which calls readMenstruationRecords from the Health Connect Manager. Finally, it sets the records returned by this function to the periods-variable.

The final piece in the puzzle is the UI layer. The first bigger change is to change the type of data we're passing around: from the Period-data class we defined for the initial UI to MenstruationPeriodRecord. You can see all the changes required from the final commit, linked at the end of the blog post.

In the previous post, we left a couple of blocks with TODO-comments. Let's replace them with the actual data reading functions:

// MainScreen.kt

val permissionsLauncher =
    rememberLauncherForActivityResult(
        viewModel.permissionsLauncher
    ) {
        viewModel.getInitialRecords()
    }

LaunchedEffect(Unit) {
    if (viewModel.permissionsGranted) {
        viewModel.getInitialRecords()
    } else {
        permissionsLauncher.launch(PERMISSIONS)
    }
}

We call the getInitialRecords from the view model in these two places. What happens here is that when the user opens this activity, the LaunchedEffect is run. The app fetches the data from Health Connect if permissions are granted. If they're not, it calls the launch-method from the permissionsLauncher we defined to ask for permissions from the user. When the permissions are granted, it calls the getInitialRecords.

We also refactor the code to use periods from the view model instead of the hard-coded periods.

With these changes, we actually get data from the Health Connect! If you don't have any other apps writing this type of data, adding some records with the Health Connect Toolbox is a way to test that everything works as intended.

This is enough if you want to just read data from other apps. But if you want to add and modify data, then keep reading.

Write Records

For writing data to Health Connect, we'll take similar steps as when reading data: First, the Health Connect Manager, then the view model, and finally, the UI layer.

Let's start with the Health Connect Manager and add a function to write records:

// HealthConnectManager.kt

suspend fun writeMenstruationRecords(
    menstruationPeriodRecord: MenstruationPeriodRecord
) {
    val records = listOf(menstruationPeriodRecord)
    try {
        healthConnectClient.insertRecords(records)
        Toast.makeText(context, "Successfully insert records", Toast.LENGTH_SHORT).show()
    } catch (e: Exception) {
        Toast.makeText(context, e.message.toString(), Toast.LENGTH_SHORT).show()
        Log.e("Error", "Message: ${e.message}")
    }
}

writeMenstruationRecords-function takes in the record to write. As Health Connect Client's insertRecords takes in a list of records, we wrap our menstruationPeriodRecord in a list.

Within a try - catch block, we call the insertRecords-method, and if everything is successful, we'll show a toast message to the user. If there is an error, we show a toast message with the error and then log the error.

In the view model, we use the tryWithPermissionsCheck-function to check the permissions before writing data:

// PeriodViewModel.kt

fun writeMenstruationRecord(
    menstruationPeriodRecord: MenstruationPeriodRecord
) {
    viewModelScope.launch {
        tryWithPermissionsCheck {
            healthConnectManager.writeMenstruationRecords(
                menstruationPeriodRecord
             )
            getPeriodRecords()
        }
    }
}

This function takes in the MenstruationPeriodRecord and writes it to Health Connect with the Health Connect Manager's writeMenstruationRecords. After that, it re-fetches the records from Health Connect to update the UI. I haven't found a way to observe the data yet, so it needs to be updated manually.

The next thing is to modify the UI. The date range picker dialog already takes in a function that is called when the user presses "Save" in the dialog. Let's edit it to allow writing data:

// DateRangePickerDialog.kt

TextButton(onClick = {
    val startTime =
        if (dateRangePickerState.selectedStartDateMillis != null) {
            Instant.ofEpochMilli(
                dateRangePickerState.selectedStartDateMillis!!
            )
        } else
            Instant.now()

    val endTime =
        if (dateRangePickerState.selectedEndDateMillis != null) {
            Instant.ofEpochMilli(
                dateRangePickerState.selectedEndDateMillis!!
            )
        } else
            startTime.plusSeconds(60) // This needs to be different from start time, but within the same day to work as intended on my code.
    ...
}) { ... }

Let's start unpacking the code. First, we need the start date and end date, and as Health Connect records take in Instant, we need to convert the milliseconds dateRangePickerState uses to Instant. We also need to check if the values are null - and if they are, then we set the start date to Instant.now() and the end date to be 60 seconds from the start date. This 60-second difference is because, for Health Connect menstruation period records, the end date can't be null, but it can't be equal to the start time either.

The app allows the user to not set the end date because if the menstruation is ongoing, there's no way to know when it ends. So, I've modified the code to check if the end time is the same date as the start time, and if so, then it's treated as null elsewhere in the code - like in the visualization.

Now, we have enough data to actually save the new period. The DateRangePickerDialog takes in a selectedPeriod, which is either an empty record with default values, or a record we're updating. We define this updated record with the start and end times inside the onClick-handler and call the onConfirm-function we pass to DateRangePickerDialog:

// DateRangePickerDialog.kt

TextButton(onClick = {
... 

val updated = MenstruationPeriodRecord(
        startTime = startTime,
        endTime = endTime,
        startZoneOffset = selectedPeriod.startZoneOffset,
        endZoneOffset = selectedPeriod.endZoneOffset,
        metadata = selectedPeriod.metadata,
    )
    onConfirm(updated)
}) { ... }

Then, in MainScreen, we add a new function, saveMenstruationPeriod that calls the view model's function by the same name. We also modify the onConfirm-function a bit:

// MainScreen.kt

fun saveMenstruationPeriod(
    menstruationPeriodRecord: MenstruationPeriodRecord
) {
    viewModel.writeMenstruationRecord(
        menstruationPeriodRecord
    )
}

....

DateRangePickerDialog( ... ) { updatedSelectedPeriod ->
    showDatePickerDialog = false
    selectedPeriod = updatedSelectedPeriod
    saveMenstruationPeriod(updatedSelectedPeriod)
}

Okay, now we've allowed the user to add new records. But what if the user inserts incorrect data and wants to edit the dates? They need to be able to edit the records, which we'll look at in the next blog post.

Wrapping Up

In this blog post, we've looked at how to read and write data with Health Connect. You can find all the changes made to the code in the context of this blog post in this commit: Read and write data from/to Health Connect.

In next week's blog post, we'll look into how to update and delete Health Connect data. So stay tuned for that!

Links in Blog Post

Exploring Health Connect pt. 3 - Updating and Deleting Data

2024-01-28T09:07:54.490Z

I've been building a period tracking app for myself, and my other goal has been to explore Health Connect. There are already two blog posts in this series:

This is the third (and last) blog post of the MVP version of this period tracker. We'll look into updating and deleting Health Connect data. After changes in this blog post, the app will look like this:

So, let's start with allowing the user to update data.

Update Records

Updating records is pretty straightforward after the changes we made in the context of the last blog post. First, in Health Connect Manager, we add updateMenstruationRecords-function:

// HealthConnectManager.kt

suspend fun updateMenstruationRecords(
    menstruationPeriodRecord: MenstruationPeriodRecord
) {
    try {
        healthConnectClient.updateRecords(
            listOf(menstruationPeriodRecord),
        )

        Toast.makeText(context, "Successfully updated records", Toast.LENGTH_SHORT).show()
    } catch (e: Exception) {
        Toast.makeText(context, e.message.toString(), Toast.LENGTH_SHORT).show()
        Log.e("Error", "Message: ${e.message}")
    }
}

It works the same way as writing - takes in a record, calls Health Connect Client's function updateRecords with a list of records, and then shows a toast message if an update is successful.

Then, in the view model, we add a function to call updateMenstruationRecords in Health Connect Manager:

// PeriodViewModel.kt

fun updateMenstruationRecord(
    menstruationPeriodRecord: MenstruationPeriodRecord
) {
    viewModelScope.launch {
        tryWithPermissionsCheck {
            healthConnectManager
              .updateMenstruationRecords(
                  menstruationPeriodRecord
              )
          getPeriodRecords()
        }
    }
}

After a successful update, we re-read the records from Health Connect to update our UI as we did with the write-action.

Then, in the UI layer, we don't need to modify the DateRangePickerDialog, as the functionality already returns an updated record when the user presses the "Save"-button. However, we need to use different methods in MainScreen for writing and updating data. So, let's define an enum to represent whether we're updating or editing the dates:

// MainScreen.kt

enum class DatePickerAction {
    UPDATE, INSERT
}

We want to remember that value as a mutable state:

// MainScreen.kt

var datePickerAction by remember {
    mutableStateOf(DatePickerAction.INSERT)
}

Then, we set the value for this datePickerAction when we're opening the date range picker dialog: When it's from the floating action button, we set it to INSERT, and when it's from the edit button in a period row, we set it to UPDATE.

Then, in the onConfirm-block of the DateRangePickerDialog, we check the action and call the correct method:

// MainScreen.kt

when (datePickerAction) {
    DatePickerAction.INSERT -> 
        saveMenstruationPeriod(updatedSelectedPeriod)
    DatePickerAction.UPDATE -> 
        updateMenstruationPeriod(updatedSelectedPeriod)
}

And if you're wondering, the update method we're calling looks like this:

// MainScreen.kt
fun updateMenstruationPeriod(
    menstruationPeriodRecord: MenstruationPeriodRecord
) {
    viewModel.updateMenstruationRecord(
        menstruationPeriodRecord
    )
}

Alright, after these changes, the user can update the dates. Yay! But we have one more action to add: Deleting a record.

Delete Records

Once again, let's start with the Health Connect Manager and add a function there. For deleting records, it's a little bit more complex than for other actions. First, we want to get (possible) client record ID from the metadata of the menstruation period record we're passing in:

// HealthConnectManager.kt 

suspend fun deleteMenstruationRecords(
    menstruationPeriodRecord: MenstruationPeriodRecord
) {
    val clientRecordIdList = if (menstruationPeriodRecord.metadata.clientRecordId != null) {
        listOf(
            menstruationPeriodRecord.metadata.clientRecordId
        )
    } else {
        emptyList()
    }
   ...
}

This is because the delete operation from Health Connect Client requires both client record IDs and IDs. Next, we pass in the variable we just defined and the id of the MenstruationPeriodRecord we're deleting. Otherwise, this function uses the same patterns as the others:

// HealthConnectManager.kt

suspend fun deleteMenstruationRecords(
    menstruationPeriodRecord: MenstruationPeriodRecord
) {
    ...
    try {
        healthConnectClient.deleteRecords(
            MenstruationPeriodRecord::class,
            recordIdsList = listOf(
                menstruationPeriodRecord.metadata.id
            ),
            clientRecordIdsList = clientRecordIdList,
        )

        Toast.makeText(context, "Successfully deleted records", Toast.LENGTH_SHORT).show()
    } catch (e: Exception) {
        Toast.makeText(context, e.message.toString(), Toast.LENGTH_SHORT).show()
        Log.e("Error", "Message: ${e.message}")
    }
}

Next up is the view model. It's as straightforward as with the other operations:

// PeriodViewModel.kt

fun deleteMenstruationRecord(
    menstruationPeriodRecord: MenstruationPeriodRecord
) {
    viewModelScope.launch {
        tryWithPermissionsCheck {
            healthConnectManager.deleteMenstruationRecords(
                menstruationPeriodRecord
            )
            getPeriodRecords()
        }
    }
}

So, once again, we call the deleteMenstruationRecords from Health Connect Manager after checking if the app has all the permissions. After that, we re-read the records after deleting the item.

We'll need to do a couple of things on the UI side. First, we want to change the edit button in the PeriodRow to a menu with two actions: Edit and Delete, as seen in the picture:

As this blog post is about Health Connect (and getting rather long), I'm leaving out the details of the UI change, but if you're interested, the change is reflected in the final commit.

To complete the deletion, we need to pass the action to execute when the user presses "Delete". This, again, is pretty similar to what we did with other options: Defining a method and then calling it in the correct place in the UI:

// MainScreen.kt

fun deleteMenstruationPeriod(
    menstruationPeriodRecord: MenstruationPeriodRecord
) {
    viewModel.deleteMenstruationRecord(
        menstruationPeriodRecord
    )
}

and

// MainScreen.kt

PeriodRow(
    ...
    onDeleteIconClick = {
         deleteMenstruationPeriod(it)
        ...
    }
) { ... }

With these changes, the user can delete the period. From a UX perspective, it would be good to add a dialog to ask if the user really wants to delete that menstruation record, but for the sake of this blog post being straightforward, I decided to leave implementing that to some later moment.

Wrapping Up

In this blog post, we've looked at how to update and delete data from Health Connect. You can find all the changes made to the code in the context of this blog post in this commit: Update and delete data from Health Connect.

I'm planning to develop this app further, including things like adding menstruation flow to the mix (that is, how much you bleed when menstruating?). From a development perspective, this will be interesting because it's another type of record, and working with aggregated data adds more complexity to the code. I won't promise to publish that blog post next week, but sometime in the near-ish future!

Links in Blog Post

Font Size Considerations for Accessibility

2024-02-02T03:46:04.480Z

Discussions about accessibility, especially in software development, often center around screen reader accessibility. With that, I mean that if accessibility is considered, it's mostly about, for example, content descriptions, setting correct semantics, and then leaving it there.

Don't get me wrong, it is important. But the problems arise when only taking these actions for accessibility and calling it done. In some apps, those actions also bring many good things for other users. But in others, many issues that create barriers to usage can be missed if the attention is only on screen reader-related accessibility.

In this and a couple of future blog posts, I'll share some things you can check to find accessibility issues, and suggest ideas for fixing them. As you might guess, these are not related to screen reader accessibility. This first blog post is about font sizing.

By the way, I'm currently writing my master's thesis, and its goal is to create an accessibility checklist for Android devs to help create more accessible Android apps. The initial checklist is live, and I'm collecting feedback, so if you want to help me, check the Android Accessibility Checklist and then answer a couple of questions in this Google Form. I'm really, really thankful for anyone participating!

Alright, let's get started.

One interesting thing related to font sizing is that about 25% of Android users increase the font size. (source: Appt.org) So this is a big group of our users! Sometimes, accessibility is dismissed because it's said to be something that concerns only a small group of users. A quarter of the user base is already a considerable amount of users - actually, it can be bigger than, for example, some language your app supports.

But if the user increases font size, it might cause problems with, for example, text overflowing or being clipped. We will explore some of these issues later in this blog post, but first, let's talk about how to test your app for different font sizes.

Testing Font Size

For testing the font size, you have at least two options: Using a phone (real device or emulator) or Compose previews. Let's look at each of them in the following subsections.

On Phone

You can test your app by changing the font size in your Accessibility settings. It's most likely located in Settings > Accessibility > Display size and text > Font Size. Turn the font size to the biggest option.

After increasing the font size, go through your app. Notice anything that does not work? Some text is unreadable? You've found the problems. The next section will contain some suggestions on how to fix these issues.

With Compose Previews

You can also test how different font sizes behave with Compose's previews. If you're working pre-Compose 1.6, you'll need to define font scales explicitly. You can do that via the fontScale-attribute:

@Preview(fontScale = 1.8f)
@Composable
fun ComponentPreview() {
  ...
}

Compose 1.6 brings something handy: Multipreview API templates, specifically @PreviewFontScale.

@PreviewFontScale
@Preview
@Composable
fun ComponentPreview() {
  ...
}

In the picture below, you can see how it adds previews for all the configured font sizes (85%, 100%, 115%, 130%, 150%, 180%, and 200%) for my graph example app:

Fixing Font Size

Okay, you tested your app, and you've found a problem. What to do to fix it? I'm going to use one of my favorite answers: It depends. I'll list a couple of issues and how to fix them.

Problem: Font Itself is not Scalable

If the font itself doesn't scale, one reason could be that you haven't configured the font size correctly.

This "not configured correctly" mainly means that the font sizes are something other than sp, scalable pixels. Check your text styling, and if it's something other than sp (for example, dp), change it to sp. That should fix the problem of the font itself not scaling.

Problem: Text Cuts Out

Another possible problem is that you've defined the components wrapping the text as not flexible enough to accommodate bigger or longer texts. This usually leads to text either overflowing or being clipped - both making the user interface harder to use.

One place where this often happens is graphs. It's not always straightforward to accommodate all font sizes when you use something like Canvas that is not so responsive to begin with. And if you can't, you should think about alternative ways to provide that data (you probably should anyway, because not everyone enjoys, or even understands, graphs).

Here's one example from a graph example app, zoomed to 200%:

The picture shows how x- and y-axis labels cut off because there is not enough space for them when the font size increases. One way to fix this is to add some room for growth for the labels. You can even make the paddings (or whichever thing you'll need to wrangle here) dynamic based on the font scale.

You can access the user's font scale value in Compose through their configuration. To be more precise, with LocalConfiguration.current.fontScale. It is a float value - for 100% font scale, it's 1, and for 200% 2.

The exact code for fixing the issues varies case by case, but here's what I did on my graph (I will write a more extensive blog post about this later):

// First, get the font scale
val fontScale = LocalConfiguration.current.fontScale

// Second, use it to scale the padding:
Canvas(
    modifier = Modifier
        .padding(
            bottom = GraphComponent.innerPadding * fontScale,
            start = GraphComponent.innerPadding * fontScale,
            end = GraphComponent.innerPadding / 2,
        )
... ) { ... }

This way, I get some breathing room for the axis labels. Here's the same 200% font scale picture after the changes:

I'd be happy to know if you've found other ways to solve these issues, especially with graphs and Canvas!

Problem: Layout is not Responsive

You might have noticed another problem related to font size in the previous pictures: When font size increases, buttons under the graph don't accommodate well. This is a common problem with layouts that must fit two or more items in a row.

One way to fix this is to allow flexibility on items. So, if these items fit on one row, they stay like that, but if not, they should be on two (or more) rows. Compose 1.5.0 added a nice, although experimental, layout composable called FlowRow, which does what I described.

When I change the current implementation to use FlowRow (So, just Row -> FlowRow), the buttons align nicely with 200% font size:

Wrapping Up

In this blog post, we've looked into font size and what problems might appear if different font sizes are not tested and accommodated. I've provided some examples of these problems and how to fix them.

Have you encountered any of these problems? Or have you gotten user feedback about font sizes? Do you have alternative ways to fix the issues? I'd love to hear, so please share them!

Links in the Blog Post

Testing with Accessibility Scanner

2024-02-16T03:38:58.642Z

When I talk about accessibility with Android developers, I often hear that some easy-to-use tests should automatically catch every possible accessibility issue. And I get it. That would make the whole topic of accessibility so much easier and straightforward.

But the truth is that automated testing only catches some things. Studies suggest that the maximum percentage of caught accessibility issues is 40-50%. Deque, the company that develops the aXe accessibility tool, claims that the number is 57% in their study of automated accessibility tools. These studies have been performed with websites, but based on my experience, I have no reason to believe that the number would be higher on Android. So manual testing is always needed.

But for that 40-57% (or whatever the exact number is on Android accessibility testing), there are some tools to use. One of them is Accessibility Scanner, and in this blog post, I'll discuss how to test your app with it. Let's start with what it is.

What Is Accessibility Scanner

Accessibility Scanner is a helpful tool for semi-automated accessibility testing. It's an app which can catch issues from the following categories:

Content labels
Touch target size
Clickable items
Text and image contrast

It also suggests how to fix some of its findings and provides more info about the issues. However, it does not find every possible accessibility issue and thus does not guarantee the accessibility of your app. Manual testing is still needed. I keep saying this because I've seen these claims so many times that "Well, our test automation didn't find any accessibility issues, so our app is accessible".

One great thing is that you can use Accessibility Scanner with any Android app - it can be a native Android app or built with cross-platform technologies such as Flutter or React Native. Or it can even be a PWA - Progressive Web App.

Using Accessibility Scanner

Installation

To use the Accessibility Scanner, you must first download it from Google Play: Accessibility Scanner. Once downloaded, you can turn it on from Accessibility settings (Settings -> Accessibility -> Accessibility Scanner -> Use service). This action adds a button overlay on your screen, and it's the access point to using the Accessibility Scanner.

Usage

Accessibility Scanner provides two options: Scan one screen or record multiple screens. Navigate to your app, then press the Accessibility Scanner button on the screen. It opens a menu where you can choose to record, take a snapshot (one screen), or turn the Accessibility scanner off.

Press the record option to record a flow or multiple screens. Then, navigate through the screens. If your phone has a vibration turned on, you should feel a slight vibration every time the app takes a screenshot.

I've noticed that sometimes I need to go back and forth to get a screenshot from some screens. I don't know why this is, but navigating to another screen and back has usually worked for me - if not the first time, then the second time.

You can end the recording by pressing the same button that has now transitioned into a stop button. If it's not visible on the screen, then you can, for example, open the Quick settings (slide them down from the top of the screen). The button should re-appear.

Results

Okay, now you've either taken a snapshot or recorded a flow. The next step is to see the results and interpret them.

The Accessibility Scanner provides an overview of the screens:

You can navigate through the screens and see possible problems highlighted. If you prefer seeing the suggestions in a list view, you can find it from the top right corner, under the list icon:

Found issues are grouped either by screen or by category. When clicking the element on the screen, it displays a screenshot of the problematic element:

It usually also provides ideas on how to fix the issue. You can read more about different issues and their possible causes and fixes from the materials mentioned in the following section.

Learn More About Accessibility Scanner

Google has created materials to learn more about the Accessibility Scanner. There are two good text-based resources:

And if you prefer watching a video, they also have one on YouTube: Accessibility Scanner - Accessibility on Android.

Wrapping Up

In this blog post, we've discussed Accessibility Scanner, a tool for testing some parts of Android apps' accessibility. While it does not guarantee fully accessible apps, it is a great tool for finding low-hanging issues.

Have you tried Accessibility Scanner? Or is it in regular use for you? If you've tried it, what was the most interesting thing you found?

Links in the Blog Post

Another Year Of Being in Gender Minority in Tech

2024-03-01T07:31:34.759Z

It's time for Dev's annual We Coded campaign again, and it's the fifth time I'm participating. You can find my previous contributions from the links above. This year, I want to share experiences from another year as someone in gender minority in tech. I'll share some not-so-pleasant experiences and, after that, some moments of allyship.

Note that the stories I'm telling are from encounters with (assumed) men - and I'm referring to them generally as men here. I chose this approach because this celebration is about gender minorities in tech, and men belong to the majority. So, I'm not trying to paint a picture of men being something awful; it's more about the minority-majority aspect here.

Also, a content warning: I'm sharing some comments containing misogyny.

Sometimes it Just Sucks

I've seen many men choose the path of not being a nice person. I'll share some stories from the past year alone.

There was this conversation in one Finnish tech-related Slack community where someone shared a piece of news about women not feeling welcome in tech. Multiple men were telling how this all is 90% in the heads of women, and how the way to solve the issues would be to stop using words like "tech bro" when describing, well, tech bros, and that it's not a problem because they haven't witnessed it.

When people who had witnessed and experienced the problems spoke up, they were either just ignored or told that they were "white knights," depending on the assumed gender.

Oh, and that conversation had my all-time favorite argument: "What about the x, y, and z fields? They don't have a proper gender balance." And that was said in a tech-centered Slack community, where the talk was about how women in tech feel excluded. I don't know if you noticed, but the topic was about tech, not the other fields.

I've also been told that women should respect men, and I don't belong even in a kitchen, but a cave, to learn about respect all the things men have done for me. This person made the threat in March last year, after I shared a LinkedIn post about gender equality and how some technologies are biased. Here's the whole comment:

There have been countless times that I've been speaking up about something related to tech, and my (man) colleague has needed to repeat what I've said to get the point through. And countless times when a man has been praised for something that I've done.

When talking about tech, I've been physically blocked from the conversation, as in I was standing in the circle of people and having a conversation, but when we started talking about the tech, one person turned their back on me, forcing me out of the circle.

And then there was this one incident, which paints a picture of our doubts: Is it me and something I did, or my gender? I was speaking at a conference and had just ended my talk. A person came to me and started giving their opinion about my talk. They used phrases like "I'm a speaker myself, and I teach speakers" and "You should have done the talk completely differently".

Let's pause here, I'll explain something. If you have ever spoken at an event, you know that the adrenaline rush speaking gives probably makes the minutes right after stepping down from the stage the worst time to give that kind of feedback. You will hardly remember anything the person said, just the feeling you had.

So, I thanked the person for their feedback (that was all I could do) and went somewhere quiet to calm down. I later spoke with several co-speakers at the conference, and they confirmed what I had thought: The feedback that person gave was not okay.

In those moments, it's tough to be a person from gender minority in tech. You never know if they would've given that same feedback to anyone in that situation - even if the speaker was a man - or if it was because the person felt somehow threatened by there being someone professional on the stage who is not from the majority.

The final example I wanted to share is from Dev. During the past year, I've shared several blog posts about gender equality, and last year's #WeCoded-post hit the jackpot. I mean, I knew that there would be at least some hateful comments, but the content surprised me. It's been getting worse year after year.

The comments were moderated pretty fast, but they contained things like drawing a line between asking for equality to mass murders and about wishing for "simpler times" - so, the times when it was women's job to just take care of the children and home, and be of service to men. And definitely not be a professional in any field. Oh, and then there was this one comment about enforcing equality being fascist.

These are just some examples from the past year. I've faced a lot more, but this already paints a picture that tech is not yet equal for all genders. We need to do better.

You Can Be an Ally

Not all I've seen has been bad, and I'm thankful for that. I want to share some examples of allyship regarding gender equality in tech, too.

First, remember that part where I told you I needed a man colleague to repeat what I had said for the thing to be heard? That same colleague did that tirelessly and kept acknowledging the problem (that they needed to repeat what I said) and speaking up about it. So, they weren't trying to take credit for my ideas, but they amplified them, gave credit to me, and tried to solve the problem.

Then there were the other speakers I mentioned in the example about the feedback at the conference. When I got myself back together and could talk about the experience without starting to cry (yes, it felt that bad), the other speakers were understanding and on my side. They acknowledged the problem and assured me I didn't imagine the problem there. So, if you recognize yourself and remember being there and one of those people, thank you!

There's also one person close to me, without whom I wouldn't have survived through the last years. We've had so many conversations about gender equality in tech and all the things I've seen and endured, and that person has always listened to me, acknowledged the inequalities, and never questioned my feelings. They've also let me just rant and haven't tried to solve the problem in that situation. Everyone should have a person like that.

Wrapping Up

In this blog post, I've shared my experiences from the past year as someone in gender minority in tech. There have been a lot of nasty things, but good things as well. Without the goods, I would have already left tech - something I've been thinking more and more about over the last year.

If you're in gender minority in tech, how has the last year been for you? And if you aren't, what are you doing for more equal tech? Share your thoughts in the comments!

Why Your App Should Have Both Dark And Light Themes

2024-03-07T04:11:50.757Z

You might have heard that your app should have a dark theme available. Some say it's because of preference, but it's actually also an accessibility thing.

This blog post itself doesn't have the code to enable dark and light themes for the user. Instead, it explains why having both of them is essential and provides further reading on the topic — yes, with links to some code and instructions as well.

Accessibility of Dark and Light Themes

Many people use everything they can in a dark theme. After all, staring at screens for a long time might be easier if the user interface uses darker colors. Using a dark theme instead of a light one also saves some battery.

However, many people choose to use the dark theme because it is more accessible for them. For example, some vision issues might cause discomfort because of light or even wash out the rest of the person's vision. A white (or similar) background behind the text can cause these issues. Another reason is that dark themes often have better contrast (if they're designed properly).

Now, if the dark theme is so great, why not just have the dark theme for the app and forget about the light theme? While dark theme is more accessible for many, some people benefit from light theme. For example, people with astigmatism may find light theme more accessible, and people with dyslexia might prefer light mode for readability. For reference, see, for example, this article: Dark mode: How accessible design raises the bar - Layth Sihan

Luckily, defining light and dark themes in modern Android development is straightforward. Let's discuss the technical considerations of light and dark themes next.

Technical Considerations

Starting from Android 10 (SDK 29), there is a system setting for switching between dark and light modes. If you define your themes correctly, your app will respect that system-wide setting by default.

To define a dark theme for your app using themes from XML files, follow the instructions in Android documentation: Implement dark theme. For apps using Jetpack Compose, the instructions are in Material Design 3 in Compose - Color scheme.

A handy tool for generating themes is Material Theme Builder, a web tool for defining themes. You can use the web UI to define the colors and then export the theme and the color definitions to import to your project. It provides exports for both Compose and XML, as well as for Flutter, web, and Material Tokens.

If you want to give the user more granular control and select the theme for your app different from the system setting, here's an article with a tutorial on how to do that with Jetpack Compose: Dark Theme Switch in Jetpack Compose with CompositionLocal - Sibel Nalop

I mentioned that dark themes might have better contrast if they're designed properly. So, when defining your theme colors for both light and dark themes, check for enough contrast between the background, texts, and other UI elements. The Material Design docs explain color contrast: Material Design 3: Accessible design—Color & Contrast.

Wrapping Up

In this blog post, I've discussed the accessibility of dark and light themes. As neither is the most accessible choice for all users, you should design and develop your apps to have both. They should either respect the user's system settings or have an in-app setting for switching between the themes.

Which do you personally prefer, the light or the dark theme? Do you select them app-by-app (if possible) or use the system-wide setting? And do you implement both for the apps you develop?

Links in the Blog Post

I'm Still Not One of the Guys

2024-03-08T08:17:38.290Z

As #WeCoded is a month-long this year, I'll post a couple of blog posts during this month. This post is the second of these posts.

In 2021, I wrote a blog post called "Why I'm Not One of the Guys" that got a response I didn't expect. When I published it in Dev, it received many comments about how I was wrong to say that the word "guys" is not gender-neutral. I still disagree, but to debate that is not the point of this blog post.

Since then, I've witnessed so many conversations where someone who does not identify as being part of "guys" asked not to be referred to by that word and got a harsh response. They're usually told how wrong they are and that they should just suck it up.

There are a couple of sides to this conversation. People are very protective of the language they're using - and at the same time, the language we use shapes the reality around us. And then there's the thing I keep wondering: if someone says they feel excluded, why is the reaction to tell them that they're wrong and their feelings are not valid?

It's About Language

The words we use matter to us. I've had and followed so many conversations where people try to justify the usage of racist, ableist, sexist, homo-, and transphobic words just because they've been using those words in the past. And this has happened even with people I know who are all in for equality.

And it kind of makes sense - language is a massive part of our identity. And if we use words that cause feelings of exclusion, and someone calls us out on that, it can feel like they're talking about us as persons, not our actions.

But even a well-meaning person can hurt. I often hear the phrase "Assume good intentions", and to some extent, I agree. It would be hard to communicate if others weren't assuming good intentions despite clumsy words. But there's a certain point where we should consider impact over intent.

Language holds a lot of power and can shape the reality around us. One great example is the Swedish gender-neutral pronoun "hen" (in addition to "hon"/she and "han"/he). It was (re)introduced to the Swedish vocabulary in 2012, and it has shaped how people think. (ref: Tavits, M. & Pérez, E. O. - Language influences mass opinion toward gender and LGBT equality)

I've Had to Fight to Get Here - a Personal Perspective

You might wonder why this is so important to me. Why just not let it go?

It's personal. I'm someone from underrepresented genders in tech and who has faced a lot of biased opinions because of my gender. I've seen how big of a role it can play.

I've also tried to be one of the guys. I always felt out of place and that I didn't belong. And now you might mention something about men being different from each other - yes, that's true. But when it comes to "being one of the guys", it usually means just a really small subset of things.

So, I know I've been at a disadvantage throughout my career because of my gender and biases towards it. I've gone through a lot and don't want to hide who I am. I want to be recognized for the gender identity I have. And I'm not one of the guys.

If It's Exclusive for Someone, There are Other Words to Use

If someone comes to you and has the courage to say that the word you're using makes them feel excluded, why not just use another word? Good options are "folks," "all," "everyone," or "team," to name a few.

And I'm not saying that if there is, for example, a group of women (or other genders) who don't have any issues with the word "guys", you can't use it to describe them. The point is about people who feel excluded by using that word.

One last thing I want to mention is microaggressions. They're small actions that communicate some sort of bias towards a minority group. They're often unintentional (but sometimes intentional), like asking someone where they're actually from or calling only male employees to the meeting. If you're interested in reading more, I wrote a blog post "Sometimes I Feel Like I'm Invisible - Experiences of a Woman in Tech" that explains microaggressions a bit more.

Microaggressions are something we, who are minorities in tech, face regularly. Personally, it's often been about actions that subtly suggest that men are better or more important - like being left out of a meeting or when my man-colleague is assumed to know better, even if I'm actually the expert on the topic. Or it's been about the language where men are the default, like with the word "guys".

Wrapping Up

What am I trying to say with this blog post? The gist could be that if someone comes to you and tells you your word choices are exclusive, please listen to them. They're not there to criticize you as a person; it's about the words you use.

And for those of us who face these situations and feel excluded, we have the right to feel what we feel and to be treated in a way that we're not excluded. When we're asking for language that doesn't exclude us, we are right to do so. Let's not let anyone tell us otherwise.

Links in the Blog Post

Accessibility Checks with Jetpack Compose Previews

2024-03-16T04:38:46.034Z

Now that Android Studio Iguana is out and stable, I wanted to write about one feature it provides and I'm excited about: Accessibility checks with Compose previews. This feature is part of the new UI checks for Jetpack Compose, and in this blog post, I'll introduce you to how to use it and provide examples of the issues it finds.

Compose UI Checks

UI Checks is a new feature shipped with Iguana. It provides a visual way of auditing your app with different screen sizes, font sizes, dark and light themes, and testing accessibility. It works similarly to how visual linting and accessibility checks integrations work for views.

Previews have this "Start UI Check Mode"-button at the top right corner:

After turning the feature on, it runs the checks and shows all the configurations with problems. If no issues are present, the preview UI doesn't show anything. Here is a picture of what the UI checks mode shows for me from one of the example checks I'll talk about in a bit:

It's an overview picture on purpose, so the quality is not good enough to see the details if you try to zoom in.

You can find the problems the checker finds in the "Problems"-panel:

Accessibility Checks

The accessibility checks the UI checks mode runs are the same as, for example, Accessibility Scanner and Accessibility checks integration for views.

It checks content labeling, implementation, touch target size, and low contrast categories. You can find more information about each category and its contents in Android Accessibility Help's article Accessibility Scanner results. The contents on that page are pretty much view-related, but each item in the categories has a "learn more" link, and many of them have examples with Compose as well.

One note, though: I was trying to reproduce some of the problems the checks should catch, and it didn't flag them. I think I've seen these false negatives (and some false positives) with the Accessibility Scanner app, which makes sense as they use the same API.

Let's dive deeper and discuss some example findings from the accessibility checks and how to fix them.

Examples

Duplicate Speakable Text Present

The first problem we will look at is "Duplicate Speakable Text Present". To demonstrate it, I've created a small component. It has two rows with a text and a button with text "Read more". The component is visible in the picture showing where you can turn on the UI Checks.

The description for the error is:

This clickable item's speakable text: "Read more" is identical to that of 1 other item(s).

Why is this a problem? Different assistive technologies and their users rely on content labels to navigate and understand the content. I'll give two examples of having two (or more!) duplicate clickable items and how they can be a problem.

First, a user who uses Voice Access for navigation would probably say "Tap Read More" when they want to activate that "Read more" button. But if there is more than one "Read more" button, Voice Access will ask which one. The user would need to pick the one by saying the number with which Voice Access has annotated it. Every time there is a similar situation, it slows the user down and decreases the user experience. Also, it means that they need to speak more to control the device, which might not be a problem when it's one time, but if that is repeated multiple times, it might become a problem.

Another example is screen reader users. They often navigate either linearly or use Touch to explore with TalkBack. If the user interface contains multiple elements with the same text label, distinguishing between the elements can be challenging.

So, how do we fix it? The answer is technically simple but might not be straightforward: The text in clickable elements must differ.

In this case, a solution could be to change the texts from "Read more" to "Read more about A" and "Read more about B". I mentioned that the solution may not be straightforward because it touches the copy, and we, as developers, don't always have control over it.

No Speakable Text Present

The next example I'm giving is an example of no speakable text present. The error description is:

This item may not have a label readable by screen readers.

One way to reproduce the problem and trigger this warning is to have an image or icon with an empty string in the content description:

Icon(
  ...
  contentDescrption=""
)

The problem is that if there is no speakable text present, then there is no text label for that element. Let's say this is an icon button with just this one icon element as a child. A screen reader user would hear that there is a button, but it doesn't have a label. They would not know what to do with that button because they wouldn't see the visual cues.

Fixing this depends on the icon - if it's purely decorative (for example, it accompanies an action to illustrate it), the content description can be null. But if it's the only thing, for instance, in a button (so, an icon button), it needs to have a descriptive label that communicates the action for the button.

If you're interested in reading more about content descriptions, I've written a blog post about content descriptions and how to write them: How to Add Content Descriptions in Compose - A Guide for Android Devs

Insufficient Color Contrast Ratio

The third check is about color contrast. This check is actually twofold - image contrast and text contrast. The error description for the text-related issue is:

The item's text contrast ratio is 4.16. This ratio is based on an estimated foreground color of #8E7098 and an estimated background color of #FFFBFF. Consider using colors that result in a contrast ratio greater than 4.50 for small text, or 3.00 for large text.

So, I have a component with regular-sized text on a background, with colors that don't have enough contrast.

Why is this a problem? It's because of visibility. If there is not enough contrast between the background and the text or image, some users might not be able to read the text or see the image. This problem concerns people with different vision-related disabilities and people with cognitive disabilities, to name some groups. Furthermore, it can affect every single user. Have you ever tried using your phone in direct sunlight, and an app didn't have enough contrast to see the text?

Images should have a minimum contrast ratio of 3.0:1 between the image and the background. Text, on the other hand, should have a minimum of 3.0:1 for large text and 4.5:1 for small text. You can read more about color contrast and requirements from WebAIM's article Contrast and Color Accessibility

It's common to come across cases where there isn't enough contrast in the actual themes, especially when the app has both light and dark themes and has not been tested well enough. Some color combinations might work well with light themes, but their dark-theme counterparts don't have enough color contrast, or vice versa.

To fix the issue, the contrast between the background and texts or images must be increased. However, increasing the contrast may not be straightforward, as developers don't always have control over the color choices for the UI elements.

Touch Target

The final check I'm writing about is for touch targets. The error description is:

This item's height is 35dp. Consider making the height of this touch target 48dp or larger.

In this case, I've created a button with a fixed height, which is why the touch target size is not high enough. The recommended touch target size minimum is 48dp x 48dp to ensure it's easier for anyone to press that touchable item. If, for example, a user has tremors in their hands, the bigger the touch target, the easier it is to tap it.

So, to fix the issue, you'll need to ensure that the touch target size is at least 48dp in width and 48 dp in height. Material Theme components should provide this out of the box - but if you're required to create custom implementations of buttons and other elements, remember to make sure they're at least 48dp x 48dp in size.

Wrapping Up

In this blog post, we've looked at Compose UI Checks and how they can help with catching some accessibility issues in your app. While they are useful, it's important to remember that using them does not guarantee that your app is fully accessible. They might render some false positives or negatives, meaning that they either find issues where there are none or don't find issues that are present. And they catch only a small subset of accessibility issues, so more extensive testing is needed.

That being said, I'm happy about this new tool for finding accessibility issues during development without any additional tools like Accessibility Scanner (which is a great app!). It's usually more probable that the tools get used if they don't need extra effort.

Have you tested the UI Checks yet? How was it? Did you find something expected or unexpected?

Links in the Blog Post

Personalizing Accessibility with Settings

2024-03-29T06:52:00.880Z

When users have different, even conflicting, needs for access, what should you do? For example, if one user needs less contrast while the other needs more, how do app developers provide the best experience for all? The truth is that it's often not possible without some personalization options.

In this blog post, I'll share some thoughts about personalization and accessibility, provide ideas on adding personalization options, and discuss setting up dedicated accessibility settings. In the following blog posts, I'll show concrete ways to personalize your app's accessibility.

Let's first examine the possible drawbacks of personalization and then dive deeper into accessibility settings.

Possible Drawbacks with Personalization

While I'd love to just say that "Personalization is easy! You should do it!" I recognize that there might be some disadvantages to it. Sometimes, personalization can add more work and complexity to the code, as developers must remember to check if conditions apply for certain things every time they develop a feature. So yes, it adds some additional work.

But on the other hand, isn't the goal of an app to be usable for its users? Sometimes, one solution doesn't fit all, and with personalization we can solve problems with conflicting user needs. We, as developers, sometimes go to great lengths to get some animation or piece of UI just right, which might take as much time as adding personalization options.

Of course, personalization is not the best approach for every situation. But I would argue that for many apps, providing options for users to personalize their experience would break down access barriers and make their experience more enjoyable, so it's time well spent.

Accessibility Settings as a Form of Personalization

One way to give the user control is to add settings to handle the different aspects of the application. Some applications have done this well. For example, Slack has an accessibility section in their application preferences. It's a bit different for desktop and mobile, but this is how it, at the time of writing, looks like for their Android app:

Personally, I'm really grateful for two settings: The animation setting and the underlined links setting. The first one helps me avoid any symptoms, as animations can trigger them. The setting also helps me concentrate. I tested to enable the animations, and phew, there was a lot of movement with the emojis! On the other hand, the second one reduces cognitive load when I can easily see that a link is a link in the middle of a sentence in a message.

Slack also has an option to change the app's theme. It's part of another set of settings, "Look and feel". The setting is called "Dark mode", and it has three options: "System default", "On", and "Off". These options are great, as some users might prefer their phone in dark or light mode, but their apps in the other, for example, to help with legibility.

There are also other apps that provide these three options for Dark mode. For example, Instagram, Duolingo, and Storytel, and probably many others - those were just the apps I first checked.

Speaking of Duolingo, they also have a dedicated accessibility setting section in their app:

They also have this animation-related setting, which is nice. However, personally, I think it would've been great if the setting wasn't on by default—or if it was set by default according to the operating system-level setting of removing animation. If you're now wondering what I'm talking about, I wrote a blog post about the "remove animations"-setting back about a year ago: Android, Animations and Reduced Motion

The Form of Accessibility Settings

While going through various apps in search of accessibility settings, I noticed that some of the apps include accessibility settings but don't annotate them as such. The dark mode example is also an excellent illustration of this behavior. In most apps I checked, turning dark mode on was not part of the accessibility settings if the app had a dedicated section.

I can see this as an advantage and disadvantage. On the other hand, when something is not labeled as an accessibility setting, more people might find it. Many users tend to disregard accessibility settings with the thought, "I don't need any accessibility settings," and do not even look at whether some settings would benefit them. But if they're not labeled as accessibility settings, these users might find them.

But, and here's a huge but: Not having the settings labeled as accessibility settings might mean that users who need those settings don't find them. While I was going through the apps I'm using, I noticed some of them have settings that would belong to accessibility settings, but because they're hidden in other settings, I probably wouldn't find them.

This all comes down to cognitive accessibility: Clear sections with headings help users find what they're looking for. Sometimes, it might be justifiable to have accessibility-related settings as part of other settings. However, in most cases, accessibility settings should be labeled as accessibility settings to be easy to find.

Okay, we've discussed why accessibility settings are a good idea for your app to personalize the experience. Now, you might wonder how to actually do this. You have multiple implementation options depending on your app's architecture, goal, and other factors. To help you with the decisions, I'll first discuss two considerations: supporting operating system-level settings and adding a custom settings section to the app. After that, I'll talk a bit more about the actual technical decisions.

Operating System Level Settings

Android's operating system provides a collection of accessibility settings. You can find them in Settings -> Accessibility. From a developer's point of view, these settings are one of two types: They either work out of the box, or developers need to implement the support for them.

The first type, out-of-the-box-working settings, don't usually require (much) work from the developer. A good example is the "Remove animations"-setting, which sets the ANIMATOR_DURATION_SCALE global constant to 0. Animator-based animations use this same constant, and animations are gone when it's set to 0. There are some exceptions where this setting is not respected out of the box, and if you're interested in learning more, the blog post I linked above has more info. Just remember to test that the app works correctly, even without animations.

For some other accessibility settings, app developers need to explicitly add support. One example is the "Time to take action"-setting, which controls the amount of time the user has to take an action. Android Accessibility Help's article "Change time to take action" mentions, "Note: Not all apps support this setting." This disclaimer is there precisely because it doesn't work out of the box, and the app developers need to add support for it. If you're interested in learning more about supporting that setting, I'm planning to write a blog post about it and how to support it in your app.

Custom Accessibility Settings for the App

The other option would be to add custom accessibility settings for the app. In the previous sections, I've discussed in what form these settings should be presented to the user, and I've suggested adding a dedicated section for accessibility in the settings. In the following blog posts, I will demonstrate how to integrate these settings into concrete use cases.

Some Technical Considerations

Android provides a nice tool for saving settings values: Preferences DataStore. In some cases, saving these settings to a database (like Room or SQLDelight) could be an option. It all depends on your app architecture and what you're trying to accomplish.

In my examples, I will use DataStore. There will be a settings screen with controls for different accessibility settings, and a way to toggle the selection on and off, or select from a broader set of options.

I will demonstrate the technical aspects more in the upcoming blog posts.

Wrapping Up

In this blog post, I've discussed personalization via accessibility settings, some possible drawbacks (but I would argue they are worth it), and ways to implement and support these settings in your app. While this blog post didn't go deep into technical aspects, others will follow. In the upcoming weeks (or months, depending on my life), I will at least write a blog post about adding a setting to toggle labels with icons, and adjusting the color scheme to a high-contrast one.

Do you use accessibility settings in apps? What are the good examples of these settings for you? What about the bad? Or, as a developer, have you ever implemented such settings?

Links in the Blog Post

Toggle Labels With Icons - Personalizing Accessibility

2024-04-21T06:11:56.182Z

As mentioned in my previous blog post, Personalizing Accessibility with Settings, accessibility for the broadest group of users often requires some personalization. What is accessible for one might not be accessible for another.

In this blog post, I will discuss one example of accessibility issues that could be solved with the help of settings: Icons and the need for text labels accompanying them. As you can see from the next section, this particular issue is personal to me, and I wanted to give an example of how to solve it.

Why?

Icons are not universal. I can't tell you how many times I've opened an app, seen icons (without labels), and wondered what the heck they mean. Where do they lead me? What happens if I press the button with an icon? Do I get to the place I'm looking for? Or does my phone explode? Who knows. The UI is not communicating it to me.

I know UX people say that it's about learning. "If you just use the app for long enough, you'll learn". But the thing is, I've had a TBI, which has affected... You guessed right, my memory. So, I find it super frustrating when there are all kinds of symbols I don't understand without text labels, and I have no idea what to do with them. These apps make me frustrated. And that's not the goal of an app, right?

On the other hand, I know some people benefit from not having those labels present. Also, almost every designer I've talked to about this topic seemed to think that having text in the UI is ugly (yes, I'm exaggerating a bit.) So, I'm coming up with a solution to help both groups - those who need the labels and those who don't need them: Personalization — a setting in the app to toggle showing labels with icons.

How?

This section will present one way to add this toggle in settings. It's not a complete solution, as the actual implementation varies based on your app's architectural patterns. It aims to provide guidelines on how to do things by showing one example.

Settings Data Store

The first step is to add settings where the user can toggle whether labels are shown in the app UI. Adding settings has two parts: the settings screen and storing the setting value.

Let's start with the latter. I'm using Preferences DataStore in the example app I'm building, as it's perfect for storing simple data, such as setting values. Let's first add the dependency (check the latest version from the link):

// build.gradle.kts

dependencies {
    implementation("androidx.datastore:datastore-preferences:1.1.0")
}

Then, the data store needs to be initialized. As the example app uses dependency injection with Hilt, let's do that in a SettingsDataStoreModule where we define the datastore provided for Hilt.

First, let's initialize the data store:

// SettingsDataStoreModule.kt

private val Context.datastore: DataStore<Preferences> 
    by preferencesDataStore("settings")

And then provide it:

// SettingsDataStoreModule.kt

@Singleton
@Provides
fun provideSettingsDatastore(
    @ApplicationContext context: Context
): DataStore<Preferences> = context.datastore

Now that the data store has been initialized and can be accessed via dependency injection, we need to add the actual setting storing. In this example application, we're reading the values from the data store in the repository to make this demo straightforward.

The data store is injected into SettingsRepository, where we define the flow the app will observe and a function to toggle the value. First, let's define the key for storing the setting value for showing the labels:

// SettingsRepository.kt

private object PreferencesKeys {
    val showLabels = booleanPreferencesKey("show_labels")
}

Next, let's define the flow:

// SettingsRepository.kt

val showLabelsFlow: Flow<Boolean> = dataStore.data
    .map {
        it[PreferencesKeys.showLabels] ?: true
    }

We read the data from the data store and get the showLabels-preference. If the value from the data store is null, we set the default to true, like the first time the value is accessed. Why true, you might ask? Well, it's both a personal choice, but it's also because I believe that the more accessible value should be the default because there is a lot of power with the default. If you want to learn more about that theme, I've written a blog post: The Power of Default.

There's one more thing: The user must be able to toggle the value. Let's add a function for that:

// SettingsRepository.kt

suspend fun toggleShowLabels() {
    dataStore.edit { preferences ->
        val oldVal = preferences[PreferencesKeys.showLabels]
        preferences[PreferencesKeys.showLabels] = 
            (oldVal ?: true).not()
    }
}

It's a suspend function, as the data store's edit function takes in a transform suspend function, where the values can be updated. We then get the old value and set the opposite boolean as the value - so, if the old value is true, then false, and vice versa. Here again, we use true as the default value if oldVal is null.

Settings in `ViewModel`

The next place in the flow is the ViewModel, which is used to get the stored values to the UI. Again, to keep this simple, we're using as simple a ViewModel as possible, and your project's implementation might differ.

As I'm using Hilt in my project, SettingsRepository is injected into the SettingsViewModel so the function and flow we defined in the previous section are available. Let's first define the state variables:

// SettingsViewModel.kt

private var _showLabelsEnabled = MutableStateFlow(true)
val showLabelsEnabled = _showLabelsEnabled.asStateFlow()

Then, we add a function to collect the value from showLabelsFlow and call it in the view model's init-function.

// SettingsViewModel.kt

init {
  getShowLabelsEnabled()
}

private fun getShowLabelsEnabled() {
    viewModelScope.launch {
        settingsRepository.showLabelsFlow.collect {
            _showLabelsEnabled.value = it
        }
    }
}

Finally, we add a function to toggle the setting and use the function from the repository:

// SettingsViewModel.kt

fun toggleShowLabelsEnabled() {
    viewModelScope.launch {
        settingsRepository.toggleShowLabels()
    }
}

All right, the next thing to do is add the actual UI and use these state values and functions we defined.

Settings Screen

The settings screen is simple. At this time, there is only one switch to toggle the setting value:

I won't go through the whole code for the screen here, but I want to point out one accessibility detail from it. When adding a switch, it needs a couple of lines of modifier magic to make it more accessible:

// SettingsScreen.kt

@Composable
fun ToggleSwitch(
    checked: Boolean,
    label: String,
    toggleValue: () -> Unit
) {
    Row(
        modifier = Modifier
            ...
            .toggleable(
                value = checked,
                role = Role.Switch,
                onValueChange = {
                    toggleValue()
                }
            ),
    ) {
        Text(label)
        Switch(
            modifier = Modifier.clearAndSetSemantics {},
            checked = checked,
            onCheckedChange = { toggleValue() },
        )
    }
}

I've left some unrelated code out, but the main point is that the text label is not associated with the switch for Accessibility APIs unless we wrap them both with a Row (or other layout component), add a toggleable modifier for it, and then set clearAndSetSemantics for the Switch component. You can read more about why in a blog post I wrote: Improving Android Accessibility with Modifiers in Jetpack Compose.

Check for Settings Value

Okay, now that we have added the ability to toggle the setting, the final thing is to use the setting value in our UI. What we are building here is a simple UI, which has a couple of message cards for the internet that look like this:

As you might have guessed, we want to toggle showing labels for the pen- and trash can icon buttons. The screen uses the same view model as the Settings screen (SettingsViewModel) for simplicity. In a non-demo application, each feature would most likely have its own view model.

So, there's the CardsScreen to which we're passing the view model:

// CardsScreen.kt

@Composable
fun CardsScreen(viewModel: SettingsViewModel) {...}

Inside CardsScreen, we want to collect the showLabelsEnabled value from the view model as a state:

// CardsScreen.kt

val showLabels = settingsViewModel
    .showLabelsEnabled
    .collectAsState()

And finally, we want to use that value to determine if we're showing the labels or not. The icons in the picture above are IconButtons, and we want to use OutlinedButtons for the labeled ones. To make the code more modular, there are different components for buttons. For the labeled version, we have the following:

// CardsScreen.kt

@Composable
fun ButtonsWithLabels() {
    Row(...)
    ) {
        OutlinedButton(onClick = { /*TODO*/ }) {
            ButtonContent(
                text = "Edit",
                icon = Icons.Filled.Edit
            )
        }
        OutlinedButton(onClick = { /*TODO*/ }) {
            ButtonContent(
                text = "Delete",
                icon = Icons.Filled.Delete
            )
        }
    }
}

And ButtonContent looks like this:

// CardsScreen.kt

@Composable
fun ButtonContent(text: String, icon: ImageVector) {
    Row(...) {
        Icon(
            imageVector = icon,
            contentDescription = null,
            tint = MaterialTheme.colorScheme.primary
        )
        Text(text)
    }
}

The code for the non-labeled version is:

// CardsScreen.kt

@Composable
fun ButtonsWithoutLabels() {
    Row(...) {
        IconButton(onClick = { /*TODO*/ }) {
            Icon(
                imageVector = Icons.Filled.Edit,
                contentDescription = "Edit",
                tint = MaterialTheme.colorScheme.primary
            )
        }
        IconButton(onClick = { /*TODO*/ }) {
            Icon(
                imageVector = Icons.Filled.Delete,
                contentDescription = "Delete",
                tint = MaterialTheme.colorScheme.primary
            )
        }
    }
}

The main difference (apart from the labels) is that the icons' content descriptions are null for buttons with labels, as the text is part of the button content and doesn't need to be repeated.

Next, let's check the value of enableLabels and set the component accordingly:

// CardsScreen.kt

if (showLabels)  
    ButtonsWithLabels() 
else 
    ButtonsWithoutLabels()

And that's it. When the setting is toggled on, the cards look like this:

Wrapping Up

In this blog post, we've looked at one way to store an app's accessibility settings and personalize the UI accordingly. The examples have been, well, examples to demonstrate ideas, and on a production-level app, you probably have a bit more fine-tuned setup.

The next blog post about accessibility and personalization will be about adjusting the app's theme by providing an option for selecting either the system default theme, dark theme, light theme, or a high-contrast theme.

Links in the Blog Post

Change App Theme - Personalizing Accessibility

2024-05-21T03:12:59.413Z

I'm continuing the theme of personalizing accessibility, which I've started with my two posts. You can find them from the following links:

As a quick recap, in the previous posts, I've discussed how personalization can generally be the key to improving accessibility, and given a concrete example of adding a setting to hide or display labels with icons.

In this blog post, I will continue with concrete examples. We will add a setting to change the app's theme. The user will have four options: follow system settings (the default), light, dark, and high-contrast color theme. Let's dive in.

Why?

Sometimes, users want to use their apps with a different theme than what their phone has as its theme. Personally, I use everything in dark mode, but I've encountered some apps with dark themes with colors that are unusable for me. They either have too much contrast, or sometimes, too little. In those cases, I wanted to change to a light theme. Usually, there has been no such option, so I've either abandoned the app or used it as little as possible if I needed to use it.

So it's all about giving users the control. The minimum options for this type of setting would be the system default, light, and dark. But what about the high-contrast theme? Why would you want to add that? Who even needs it?

High-Contrast Theme

A high-contrast theme has a limited color palette with higher contrast colors. One concrete example is Windows High-Contrast Mode, which was developed for Windows 7 and later. Android provides a setting for high-contrast text, but it only applies to text, not graphics.

WebAIM surveyed low-vision users in 2018, showing that 51.4% of the respondents (n=248) used a high-contrast mode. Low-vision users are a large group needing high-contrast themes, but there are others as well. For example, people with migraines, Irlene syndrome, or some people with dyslexia might benefit from high-contrast themes. High-contrast modes can be useful in direct sunlight for anyone, too.

How?

The flow for adding a possibility to change the app's theme is similar to the labels and icons in the previous blog post: We add a setting to the settings screen, store the value in a data store, and then use that value in the app to decide which theme to display.

Let's start with the settings screen. We want to add a section for selecting the theme and options to choose from. The list contains four options: System default, dark theme, light theme, and high-contrast theme. In the example, the colors are shown:

Storing the Data

First, continuing with the setup we had in the previous blog post, we want to add a key-value pair to the data store we were using for storing the settings. As mentioned in the previous blog post, for the sake of straightforwardness for the blog posts, the data store is defined and interacted with in the SettingsRepository.

As we have four options to choose from, a simple boolean value does not work in this case. In the code, we want to use predefined values for themes, so we create an enum class for the theme with all the options and use null for the system default.

// ThemeExt.kt

enum class Theme {
    Dark,
    Light,
    HighContrast;
}

The data store can't store enum values, so we need to have a way to convert the enums to strings and back. The to string-part is easy - we can just use the toString()-function. For the other conversion, we need to define a helper function. Let's add it to the enum class:

enum class Theme {
    ...

    companion object {
        fun from(value: String?): Theme? {
            return when (value) {
                Dark.name -> Dark
                Light.name -> Light
                HighContrast.name -> HighContrast
                else -> null
            }
        }
    }
}

In this method, we check which of the theme's names matches the value we're passing in. Also, we have the default case of null - if nothing matches, we assume it's the system default and set the value to null.

Okay, now we have everything to store the theme in the data store. First, let's add a flow to read the value:

// SettingsRepository.kt

private object PreferencesKeys {
    ...
    val colorTheme = stringPreferencesKey("color_theme")
}

val colorThemeFlow: Flow<Theme?> = dataStore.data
    .map {
        Theme.from(it[PreferencesKeys.colorTheme])
    }

So, we first add a preferences key to the preferences key object. For the flow, we read the value from the data store, and then use Theme.from(), which we defined earlier, to parse the string to Theme-enum.

For editing the value, we define a function:

// SettingsRepository.kt

suspend fun setColorScheme(theme: Theme?) {
    dataStore.edit { preferences ->
        preferences[PreferencesKeys.colorTheme] = theme.toString()
    }
}

In the function, we set the string value of the enum to the data store using the preference key we defined.

The next thing to do is to update the SettingsViewModel. First, we add a mutable state flow to store the theme's value and use it in the UI:

// SettingsViewModel.kt

private var _colorScheme = 
    MutableStateFlow<Theme?>(Theme.Dark)
val colorScheme = _colorScheme.asStateFlow()

Then, we define functions to read the value from the repository and use the repository's setColorScheme function:

// SettingsViewModel.kt

private fun getColorScheme() {
    viewModelScope.launch {
        settingsRepository.colorThemeFlow.collect {
            _colorScheme.value = it
        }
    }
}

fun setColorScheme(theme: Theme?) {
    viewModelScope.launch {
        settingsRepository.setColorScheme(theme)
    }
}

The last thing is to call getColorScheme() in the init block so that we get the initial value when opening the app:

// SettingsViewModel.kt

init {
    ...
    getColorScheme()
}

Settings Screen

As with the last post, I'm not going to demonstrate how to use the values from the SettingsViewModel but I'm just going to mention that from accessibility and semantics point of view, there are a couple of things to note: Each of the color options need to have selectable-modifier, and the component wrapping the color options needs to have a selectableGroup()-modifier. How these look like in my code:

// SettingsScreen.kt 

@Composable
fun ColorOption(
    option: ColorOptionData, 
    isCurrentTheme: Boolean, 
    setColorScheme: (Theme?) -> Unit
) {
    ...

    Row(
        modifier = Modifier.selectable(
        selected = isCurrentTheme, 
        role = Role.RadioButton
    ) {
        setColorScheme(option.theme)
    },
        ...
    ) {
        ...
    }
}

In the parent component, we have the following:

// SettingsScreen.kt 

Column(
    modifier = Modifier.selectableGroup(),
) {
    colorOptions.map { option ->
        ...
    }
}

If you want to know more about why this is done, my blog post Improving Android Accessibility with Modifiers in Jetpack Compose explains the reasons.

Changing the Theme for UI

The final step is to use the stored value for the theme and update it accordingly. We'll need to add logic to set the theme according to the stored value.

Note that the actual theme definition is out of scope for this blog post - I have colors defined for dark, light, and high-contrast themes, and I'm going to use them in the code.

In Theme.kt, let's add additional checks to the default implementation of the application theme:

// Theme.kt

@Composable
fun AppTheme(
    useDarkTheme: Boolean = isSystemInDarkTheme(),
    theme: Theme? = null,
    content: @Composable () -> Unit,
) {
    val colors = when (theme) {
        Theme.Dark -> DarkColors
        Theme.Light -> LightColors
        Theme.HighContrast -> HighContrast
        null -> if (!useDarkTheme) {
            LightColors
        } else {
            DarkColors
        }
    }
    MaterialTheme(
        colorScheme = colors,
        content = content,
    )
}

We add an optional parameter of type Theme to the AppTheme composable and then use it to decide which colors we're setting to the MaterialTheme component. If the theme is not null, then we set the colors per the value, and if it's null, then we should use the system's default colors. For this, we check the isSystemInDarkTheme value and set the colors accordingly.

Finally, in MainActivity, where our app's root is defined, we read the value of the stored theme and then pass it to the AppTheme-composable:

// MainActivity.kt

val theme = settingsViewModel.colorScheme.collectAsState()

AppTheme(theme = theme.value) { ... }

And with these changes, we will get the following themes visible when they're selected from the settings:

Wrapping Up

In this blog post, we've looked at how to let users decide which theme they want to use in the app by adding a setting for it. The provided themes are either light, dark, or high-contrast themes - or follow the system default theme.

Have you implemented a theme selector in your app? Have you encountered the high-contrast theme before? Do you have ideas for which type of accessibility settings I could cover next?

Links in the Blog Post

Accessibility Tests in Compose - Name, Role, Value

2024-06-03T03:31:45.745Z

When writing tests for your app, you should also consider testing for accessibility-related things. And I get it; it can be challenging to know where to start. So, I decided to write this blog post about how to test some accessibility aspects.

In this post, we will add some accessibility-related tests for three custom components constructed with the help of clickable, selectable, and toggleable modifiers. These components were built in a blog post I wrote: Improving Android Accessibility with Modifiers in Jetpack Compose.

What Are We Testing?

The tests we're writing verify that the components have names, roles, and values. But where does this group come from? The background is that Web Content Accessibility Guidelines (WCAG) has a success criterion, "Name, Role, Value", which ensures that every element has a programmatically determinable name and role. Also, states, properties, and values that users can change are programmatically changeable.

And now, if you wonder why I'm mentioning something named "Web," the WCAG is also used to determine the minimum level of accessibility for mobile apps as well, despite the name.

Name, in this case, means the accessible name—so, the textual representation of the element. It can be, for example, a button's text, an icon button's content description, a label for a switch, or similar. It's what anyone using a screen reader hears. Voice access users use it to activate interactive elements.

Role, on the other hand, is the role of the element. It can be, for example, a button - which tells the user that, hey, this is a button, and it should behave as a button. A role is a promise of how things should work, so if you add a role, be sure to add the correct interactions as well. However, roles are used less on Android than on the web.

Value can refer to an element's state, property, or value. The exact thing is different per element. For example, with a checkbox, the value tells if it is checked, or with an accordion, it's the state that tells if it's opened or closed.

In the next section, we'll examine concrete examples of how to test the "Name, Role, Value" success criterion for a couple of custom components mentioned in the intro.

Writing the Tests, an Example

As mentioned in the beginning, these tests are written for components for a blog post I've written previously. We'll look into how to test three components: A switch, a radio button group, and a clickable row.

As the components in the blog posts were simplified for the sake of an example, these tests are also streamlined. With production-grade code, you usually have a bit more sophisticated strategies for, for example, finding the components that are being tested.

Toggleable

The first component we're testing is a switch like in the picture:

We want to test three things: First, we want to ensure the component has an accessible name (so, the label of the switch). Second, the role should be correct—it should be a toggleable component. Third, the value should be correct before and after toggling the switch, so whether the switch is on or off.

Let's write a test:

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

    @Test
    fun hasRoleNameValue() {
        composeTestRule.setContent {
            ModifiersExampleTheme {
                ToggleableScreen()
            }
        }

        val toggleableElement = 
            composeTestRule.onNode(hasTestTag("accessible-toggle"))

        // Assert accessible name
        toggleableElement.assertTextEquals("Toggleable")
        // Assert role
        toggleableElement.assertIsToggleable()
        // Assert value
        toggleableElement.assertIsOff()
        toggleableElement.performClick()
        toggleableElement.assertIsOn()
    }
}

First, the test needs a setup, so we need things like the composeTestRule and setting the content. Then we get the testable component with a test tag accessible-toggle. Finally, we have the tests for name, role, and value.

The test for checking the name is straightforward: We want to ensure that the element's text content equals the word on the label. We can assert that with assertTextEquals. To test the role, we can use a useful assert function, assertIsToggleable. Finally, to check if the value (so, the checked state) is correct, we can also use the utility functions assertIsOff and assertIsOn and, for toggling the state, performClick.

Selectable

The next component we're testing is a radio button group, as seen in the picture:

For this component, we ensure that both of the options have a name (so, the labels "Option A" and "Option B"), role as selectable, and value if the item is selected.

The test for this component is:

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

    @Before
    fun setup() {
        composeTestRule.setContent {
            ModifiersExampleTheme {
                SelectableScreen()
            }
        }
    }

    @Test
    fun hasRoleNameValue() {
        val selectableElements = 
            composeTestRule.onAllNodes(hasTestTag("accessible-selectable"))

        // Assert accessible name
        selectableElements[0].assertTextEquals("Option A")
        selectableElements[1].assertTextEquals("Option B")
        // Assert role
        selectableElements.assertAll(isSelectable())
        // Assert value
        selectableElements[0].assertIsSelected()
        selectableElements[1].performClick()
        selectableElements[0].assertIsNotSelected()
        selectableElements[1].assertIsSelected()
    }
}

The structure is very similar to the previous test; first, the setup, then getting the elements, and then asserting name, role, and value. We're using the same assertTextEquals to check the elements' labels (so, names). Similarly to the toggleable, there are functions for asserting the role and values for the selectable: isSelectable(), assertIsSelected(), and .assertIsNotSelected().

Clickable

The final custom component for this blog post is a custom button that can be used to bookmark an item:

We want to ensure that it has a name (so, the text "Bookmark this item"), the role of a button, and a state that communicates whether the item is bookmarked or not.

The following tests ensure that:

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

    @Test
    fun hasRoleNameValue() {
        composeTestRule.setContent {
            ModifiersExampleTheme {
                ClickableScreen()
            }
        }

        val clickableElement = 
            composeTestRule.onNode(hasTestTag("clickable"))

        // Assert accessible name
        clickableElement.assertTextEquals("Bookmark this item")

        // Assert role
        clickableElement.assert(
            SemanticsMatcher("has correct role") {
                it.config.getOrNull(SemanticsProperties.Role) == Role.Button
            },
        )

        // Assert state description
        clickableElement.assertStateDescription("Not bookmarked")
        clickableElement.performClick()
        clickableElement.assertStateDescription("Bookmarked")
    }

    private fun SemanticsNodeInteraction.assertStateDescription(
        stateDescription: String
    ) =
        assert(
            SemanticsMatcher("has correct state description") {
                it.config.getOrNull(SemanticsProperties.StateDescription) == stateDescription
            },
        )
}

Again, the setup and checking of the name are similar to the other two components. But to check if the component has a role of the button, we need to use a SemanticsMatcher.

SemanticsMatcher is a wrapper for matching semantic nodes. We want to ensure that the element's semantic property Role matches Role.Button. We can do it by wrapping our check with a SemanticMatcher, and getting the element's SemanticProperties.Role from the element with it.config.getOrNull(SemanticsProperties.Role) and checking its value.

The same pattern works for testing the element's state description. To avoid code duplication, I've created an extension function, assertStateDescription, which is used to check the state description of the element.

Wrapping Up

In this blog post, we've discussed writing accessibility tests for the WCAG success criteria 4.1.2: Name, Role, Value. While they're not always relevant to mobile accessibility, this blog post aims to give an example of how to write accessibility tests.

Have you written tests for accessibility on Android? Please, share what you've learned!

Links in the Blog Post

Pride in Your App - Trying Out GraphQL on Android

2024-06-14T02:56:23.859Z

It's Pride month, y'all! As someone who is part of the LGBTIQA+ community, this month is both great and stressful at the same time. You never know what some people come up with - somehow, this month draws some really nasty people out. And with the rise of far-right in Europe... I'm not even going to get started.

I have wanted to try out GraphQL with Android for quite a while, and when I came across this Pride Flag API, I thought that now was the time. What a great way to celebrate Pride by trying out the API (and GraphQL) and writing a blog post about it!

A bit of background about me and GraphQL: I started my public speaking career talking about GraphQL (and JavaScript. That's my dark secret.). It was fun, and I liked it a lot. Of course, there are always pros and cons when thinking about using any technology, but nevertheless, I liked it a lot. I even got this "Ask me about GraphQL" T-shirt from one meetup, and that was probably the coolest t-shirt I've gotten.

When I switched to Android, there were no use cases for me to learn how to integrate GraphQL with Android. So, I've wanted to try it for a while now, and I'm glad I found a great way to test it. Let's get started!

GraphQL

If you've never heard the word GraphQL, it's a query language and an alternative way of building APIs in the form of graphs - hence the name.

GraphQL APIs let you ask for what you need - and only that. So, compared to REST APIs, which always return everything, GraphQL APIs return only the values you've asked for. And as it's graph-based, you can get nested data with one query. An example would be authors, their books, and the characters in the books - with REST API, you'd need to make three requests (depending on the API, naturally).

GraphQL offers three actions: querying, mutating, or subscribing to data. Compared to REST, querying matches the GET requests, mutating matches all the others that mutate data, and subscribing is a two-way street - like, for example, WebSockets.

In the context of this blog post, we're going to query data. To learn more about the operations available and GraphQL in general, head over to GraphQL's documentation.

To use GraphQL, we're going to use Apollo Kotlin (formerly Apollo Android). The library is type-safe and compatible with Kotlin Multiplatform.

Dependencies and Getting the Schema

To get started with Apollo Kotlin, we need to add some dependencies to the project:

// project-level build.gradle.kts 

plugins {
  id("com.apollographql.apollo3").version("3.8.4")
}

and

// module-level build.gradle.kts 

dependencies {
  implementation("com.apollographql.apollo3:apollo-runtime:3.8.4")
}

Note that the version numbers for these packages must be the same.

In addition to dependencies, we need to add a package name addition task for the generated models:

// module-level build.gradle.kts 

apollo { 
    service("service") { 
        packageName.set("com.example") 
    } 
}

With many projects, syncing gradle files would happen right here. However, this project is different; we still need the schema for the GraphQL queries. There are several options, but with an external API, downloading the schema with introspection is the easiest. We need to save the schema to src/main/graphql, and in the case of this small project, we do it with the following command:

./gradlew :app:downloadApolloSchema --endpoint='https://pride.dev/api/graphql' --schema=app/src/main/graphql/schema.graphqls

Once we have the schema, it's time to sync the gradle files and continue to querying the data.

Querying Data

For this small app, we want to read the data - so, in GraphQL's terms, we want to query it. We don't need every property for the flags, so we define a query with just what we need:

query FlagQuery {
  allFlags {
    name
    year
    svgUrl
  }
}

With Apollo Kotlin, all queries need to be named queries. You'll run into an error if you have an unnamed query - trust me, I know.

This query gets all the available flags from the API. We need the flag's name, year, and SVG URL, so we write those properties in our query.

To add the query to the Android project, we first need to create a file in the src/main/ folder, which is the very same folder where the schema lives. Let's call the file FlagQuery.graphql and add the query there. Apollo generates the model for the query through an automated task that runs when the app is built. So, let's build the app, and then query's model will be available.

At this point, I want to remind you to add the internet permission to AndroidManifest. If you don't, well, the following steps will become more complicated. Trust me, I know.

Here's a reminder on what to add, so you don't need to use a search engine to find it, like I did:

// AndroidManifest.xml

<uses-permission android:name="android.permission.INTERNET" />

Okay, now we have the query, but how do we connect it to the UI? The answer is a GraphQL client, which we can use to query the data. I'm making things straightforward for the purposes of this demo, so we only define a GraphQL client and then query the data in a view model. In a production-grade app, you'd probably have a more layered architecture.

First, we define the client:

// GraphQLClient.kt

const val API_ENDPOINT = "https://pride.dev/api/graphql"

val apolloClient = ApolloClient.Builder()
    .serverUrl(API_ENDPOINT)
    .build()

In the view model, we first define a state to use in the UI:

// FlagsViewModel.kt

data class FlagsUiState(
    val loading: Boolean = true,
    val flags: List<FlagQuery.AllFlag> = emptyList(),
    val currentFlag: FlagQuery.AllFlag? = null,
)

class FlagsViewModel : ViewModel() {
    private var _state = MutableStateFlow(FlagsUiState())
    val state = _state.asStateFlow()
    ...
}

We want to store all the flags we get from the API and display the current flag on a detail page, so we have properties for flags and currentFlag in the state. The type (FlagQuery.AllFlag) for both is generated by Apollo Kotlin.

To query all the flags, let's define a function inside the view model:

// FlagsViewModel.kt

suspend fun getFlags() {
    val flagsQuery = apolloClient
        .query(FlagQuery())
        .execute()

    _state.update { currentState ->
        currentState.copy(
            loading = false,
            flags = flagsQuery.data?.allFlags ?: emptyList(),
        )
    }
}

So, to get the flags, we need a suspend function, inside which we call the apolloClient.query(...).execute() with the FlagQuery we defined previously. On success, it returns data in the data property, which we can then use to update the state with.

I mentioned that we also want to store the current flag in the state. Setting it is a straightforward function without any GraphQL-magic:

// FlagsViewModel.kt

fun setFlag(flag: FlagQuery.AllFlag) {
    _state.update {
        it.copy(
            currentFlag = flag,
        )
    }
}

A Couple of Words About the UI

On the UI side, we're doing pretty simple things: displaying a list of the flags and then navigating to a detail view. As it's not related to GraphQL, meaning it's just passing data as state, it's out of the scope of this blog post.

Here's a video of how the experience looks like:

If you're interested in checking the UI code out, head over to the repository: Flag Explorer

Wrapping Up

In this blog post, we discussed GraphQL and how to use it in an Android project. As an example, we built a small app that fetches Pride flags from the Pride Flag API.

In the end, adding GraphQL to the project was surprisingly straightforward. For some reason, I had thought it'd be much more complicated. As mentioned in the beginning, I have warm feelings towards GraphQL, so it'd be great to use it in some real projects. We'll see what the future brings!

What do you think of GraphQL? Have you tried it out?

Links in the Blog Post

The Worst Case of Imposter Syndrome

2024-06-26T03:06:30.434Z

I wrote most of this blog post in the spring, a bit after my burnout sickness leave. I'm still recovering, but I'm in a way better place. I found this draft a couple of days ago, and after reading it, I decided I'd finish it and publish it. Why? I think it speaks for itself. It contains the words I'd wanted to say back then but didn't have the strength to say, even to finish the blog post and share it.

And if you recognize yourself from the words, I see you. You are enough and have what it takes, even if it doesn't feel like it.

The Worst Case of Imposter Syndrome

I think I'm experiencing the worst case of imposter syndrome in my career. It's so bad that I've started considering switching careers because I can't stand this deep feeling. And when I say switching careers, I'm not joking the way I usually joke when something mysterious happens with the code. No, this time, I've been considering leaving tech behind.

It all started... Where it all started? I don't even know. For a long time, I've been really confident. Not in an arrogant way, but in a way that I know what I know, and I definitely know what I don't know. And sure, I've had setbacks, but I've always bounced back.

Now it just feels like I'm going deeper and deeper into understanding how much I suck. And how little I know and how I shouldn't even work in this position. How everyone knows that I'm a fraud.

I can start dissecting this. And actually, that's what I'll do. I'll tell you about some things that have led to this situation. It's not because I blame someone (or actually, I do - myself), but I want to bring light to things that have caused my journey to end up here.

Oh, and in the end, I won't tell you how to get better. This is not one of those blog posts. I'm still on my way to getting out of the woods with all this. But I hope reading what has affected me might help you recognize some things on your journey that might lead to where I am and avoid them. This is most definitely not a fun place to be.

Burnout Leads to Questioning Yourself

Burnout can cause low professional self-esteem, so it's no wonder it can be one of the building blocks for imposter syndrome. It's sneaky and builds over time, so the change is not always easy to spot.

My advice: Don't get burnt out. Do something before it's too late. I know it's not always easy to recognize that you're on the path to burning out. Heck, I've been here many times, and I still don't always recognize it well enough.

The Words of Others Can Do a Lot of Harm

To add to this burnout-related low self-esteem, hearing words like "this is what senior developers should know" and realizing you don't know all that doesn't help. I was part of a hiring committee for a senior Android developer role a while back, and at some point, I realized how others described what a senior Android developer should know.

It was all technical details - trivial things I realized I didn't know to describe on the spot. And the way they talked about the candidates and their skills, I just felt like I should get a demotion because I don't have all the technical knowledge for a senior developer. Maybe not even for a mid-level developer.

Hearing those conversations, I was ready to quit. I felt like I'm not good enough (despite being in a senior Android role for more than a year, so I had literally proven myself already). I felt like every single one of my Android colleagues must see me in a way that I don't deserve to be a senior developer, and that I was just lucky to get promoted.

That feeling is paralyzing. You start to question your every decision and every line of code. You start waiting for something bad to happen, and every time there is a crash or bug that's reported, you're sure that it's because of you (even if you haven't merged any code for the past weeks because you were on a sickness leave).

I'm getting better now, but this feeling and those thoughts are still nagging me. I can fight them, but I realize they affect the things I do a lot. Luckily, I have a colleague who keeps cheering me on and reminding me that I am skilled and good enough (thank you, Marianne ❤️). But I really hope that no one needs to go through those emotions I've gone through. So, let's remember that our words affect people around us.

Constant Fighting for Your Seat at the Table Does Not Help

The other thing that contributes to this feeling is the constant fight to be heard and seen. I've been in countless meetings where I've been forgotten - like, let's have a facilitated round of introductions, but let's forget Eevis. At the time, I was so exhausted that when that happened, I was just silently crying and could not open my mic to say, hey, I'm here; please don't forget me again.

I often have felt like I'm speaking to walls. Or maybe something else, walls often don't answer with "Oh that's a good point" and then forget it all when it's time to incorporate the feedback.

I could also talk about the countless times when I've been the person who knows the answer to something because I've been the one working with the thing. And then, in some meeting, I'll need to first wait for some man, who has just a vague idea of that thing, to explain what's going on - and then start correcting them. Yes, I'm too nice to just cut there when they start. No, I won't change that; it requires even more strength. I've been raised to be nice, polite, and not cut when others speak.

I fully believe that none of these people do these things because they hate me or consciously think I'm lesser. But nevertheless, they keep repeating these actions, and it tires me out. I hate the constant fighting. I'd like to have a seat at the table because I've already earned it (because, trust me, I have). I hate playing this constant chair game where I need to prove myself over and over again, more than many of my colleagues do.

I've described this all working twice as much as many others. And in fact, I do. So, it is no wonder I am burnt out and exhausted. And no wonder I have this feeling that even if I work twice as much, I'll never be good enough as the others who don't need to work that much.

Wrapping Up

If you're my colleague reading this and recognize yourself from what I've written, I'm not blaming you. I fully believe you have good intentions in every instance. I'm just asking that you pay attention to the impact your actions might have — not just on me but on anyone around you.

And if you're experiencing similar things, I'd love to say things get better, but I have to be honest: I don't know if they do. I know it's possible to reach this state of mind where you're confident and small things don't affect you. I've been there. And I hope I'll reach that state some day again.

But before that, I hope I won't end up switching careers.

Stacked Cards Layout With Compose - And Cats

2024-07-11T11:02:39.052Z

I was writing a completely different blog post about playing around with Glance and app widgets, and I needed an example app. None of the existing ones served me, so I needed to build a new one. And I completely overdid it—I would have needed just something really simple, but I ended up creating a more polished app with some new concepts.

The app I built has cats — a lot of cats— and you can get even more. It has cat pictures as cards. I wanted to stack the cards in a pile just because I thought I could probably do it — and I could! So this blog post is about building that stacked card layout — and a bit about cats.

If you ever need cats, there's this awesome API: Cats as a service. I think it's one of the most important ones out there. Just saying.

Yes, I might end up being the cat lady in the future.

But okay, back to the coding. In the next sections, I'll first explain the stacked cards layout in more detail, then discuss custom layouts in Compose, and finally talk through the code for my version of the stacked cards layout.

Stacked Cards with Cats

The app's idea is to fetch a cat picture, and then get more cat pictures once you've seen one. Nothing complex, just cats. The app fetches a random picture's JSON data from Cataas-API and stores the picture's ID in a data store. Why a data store instead of, for example, Room? Well, this is a simple example app, never intended for production use, and it needs really simple data—a set of strings.

Further, it renders pictures with Coil's SubcomposeAsyncImage based on the URL, so it doesn't load the images to the device. Again, it's not a production app, and there is no need for offline support or similar things. For a more production-grade app, a lot of things should be improved. I've tried to make the code (a link at the end of the post!) as straightforward as possible, so I've cut some corners.

So, if you're someone recruiting Android devs, please don't look at this code as my masterpiece and the proof of all I can do. Trust me, I write more robust code in production. I promise!

The app UI shows the latest picture at the top of the screen and then the others stacked on the bottom of the screen. Users can remove the topmost picture from the stack by clicking the X-button that each card has in the top-right corner.

Now that I've been just hinting about cat pictures and the stacked card layout, let's finally see some pictures. Or a picture, to be more precise. Here's what the stacked cards look like when there are a lot of cards in the pile:

How did I accomplish this layout? I used the custom Layouts Compose provides. Let's talk about that a bit next.

Custom Layouts

Compose has some built-in layouts, such as Columns and Rows, but often custom layouts are needed. You can read more about custom layouts in Compose from the Android documentation: Custom Layouts.

There are two ways of creating custom layouts with composable components: with a layout- modifier or with a Layout composable. The layout- modifier modifies only the composable it's called on, so it's not an option in our case.

As this layout is about more than one component, we want to build the layout with a Layout composable. A Layout composable allows us to measure and lay out multiple composables. The process for creating the layout consists of three phases (quote from the Custom Layouts documentation):

Each node must:

Measure any children

Decide its own size

Place its children

We'll get to a concrete example of all these in a bit, but this is the process for most custom layouts out there.

Show Me the Code

Okay, so to create the stacked cards layout, we'll need a custom component that takes modifier and content as parameters. Of course, this composable could take in other things as well, but for this example, just those two are needed.

// CardStack.kt

@Composable
fun CardStack(
    modifier: Modifier = Modifier,
    content: @Composable () -> Unit,
) {
    ...
}

Then, inside the CardStack-component, we'll define a Layout, which takes in the same content and modifier-parameters. The third parameter is a MeasurePolicy lambda, responsible for all the action and layout creation. The lambda has two params: measurables, which is a list of Measurables, which all correspond to a layout child element. The other parameter is constraints, the constraints for the layout. The following code shows all this more concretely:

// CardStack.kt

Layout(
    content,
    modifier,
) { measurables, constraints ->
  ...
}

Inside the Layout-composable, we'll need to do the three steps mentioned in the previous section. We first measure the children, then decide the size, and then place the children.

The first step is to measure the children. For that, we'll use the measurables-parameter, map through it, and for each Measurable item, call the measure-function. We then store all of these into a variable called placeable:

// CardStack.kt

val placeables =
    measurables.map { measurable ->
        measurable.measure(constraints)
    }

The next step is to decide the size. As the cards are stacked on top of each other, the screen estate we need for the cards is pretty much the size of one card with some extra padding. Of course, we don't want the cards to be exactly on top of each other to have the effect of piled cards, so the amount of extra padding needs to depend on how many cards there are.

For the height of the layout, we want to check the height of one card, so we take the first card on the measured children variable (placeables) and its height. In this example, the size of the cards is always the same, so setting the height is straightforward. For cards with differing sizes, some more calculations for the height would be needed.

Then, we add some extra padding (in this case, 10 pixels) and multiply it by the children's size. As the layout can take zero or more children, we want to account for the case when there are no children - so if the placeables list is empty, we set the height to 0.

For the layout's width, we use the width of the first child if there are children and 0 if there are none. Then, we define layout with these height and width. This all looks the following in code:

// CardStack.kt

val height = if (placeables.isNotEmpty())
        placeables.first().height +
            (CardStack.EXTRA_PADDING * placeables.size)
    else 0

val width = if (placeables.isNotEmpty())
        placeables.first().width
    else 0

layout(width = width, height = height) {
    ...
}

The final step is to place the children. That happens inside the layout we defined. We want to map through the children (placeables) and then call the place-method. It takes in x and y coordinates, and we want to use those coordinates for a bit of misalignment to create a more realistic look.

So, for the x-value, we either place it at coordinate 0 in the parent's coordinate system or put it to x-position of 5 (defined outside the code snippet). The decision depends on if the value is odd or even - if it's even, then we use 0. Otherwise, we use 5. The isEven-function is an extension function I've defined to reduce repetition for checking if an integer is even.

For the y-position, we want to multiply the y-position (5, defined outside the code snippet, see the full code below) with the index of the current element to create the stacked effect showing cards underneath the topmost card. This all translates to code the following way:

// CardStack.kt

layout(width = width, height = height) {
    placeables.mapIndexed { index, placeable ->
        placeable.place(
            x = if (index.isEven())
                0
            else
                CardStack.X_POSITION,
            y = CardStack.Y_POSITION * index,
        )
    }
}

The final code for the custom layout looks like this:

// CardStack.kt

@Composable
fun CardStack(
    modifier: Modifier = Modifier,
    content: @Composable () -> Unit,
) {
    Layout(
        content,
        modifier,
    ) { measurables, constraints ->

        val placeables =
            measurables.map { measurable ->
                measurable.measure(constraints)
            }

        val height = if (placeables.isNotEmpty())
                placeables.first().height +
                    (CardStack.EXTRA_PADDING * placeables.size)
            else 0

        val width = if (placeables.isNotEmpty())
                placeables.first().width
            else 0

        layout(width = width, height = height) {
            placeables.mapIndexed { index, placeable ->
                placeable.place(
                    x = if (index.isEven())
                        0
                    else
                        CardStack.X_POSITION,
                    y = CardStack.Y_POSITION * index,
                )
            }
        }
    }
}

object CardStack {
    const val EXTRA_PADDING = 10
    const val Y_POSITION = 5
    const val X_POSITION = 5
}

But we still need to do one thing to accomplish the UI we saw. Right now, the stacked layout looks like this:

The cards are laid out on top of each other, aligning pretty well. However, we want a bit of randomness and rotation, like real, physical cards when they're piled. We'll add this effect to the cards themselves with a modifier.

In MainScreen, we map through cat picture ids and then show the CatCard component with the id. This is where we add the rotate modifier with a random amount of degrees for rotation.

Inside the mapping, we define the degrees- variable, remember it between recompositions, and then pass that value to the rotate-modifier. For the value of degrees, we want to have a number within a range from -2 to 2. As Random.nextFloat() doesn't allow us define the range, we'll use Random.nextInt() and then convert the value to a float.

You might ask now why we need to remember the variable. Otherwise, this random number would be regenerated on every recomposition (when an item is either added or removed from the list), causing the cards to change their positions on every recomposition.

// MainScreen.kt

CardStack {
    catIds.value.mapIndexed { index, id ->
        val degrees = remember {
            Random.nextInt(-2, 2).toFloat()
        }

        AnimatedCatCard(
            modifier = Modifier.rotate(degrees),
            ...
        )
    }
}

After these changes, we have a stacked card layout, shown in the Stacked Cards with Cats section.

Wrapping Up

In this blog post, we've looked into custom layouts with Compose by building a stacked cards layout for cat photos. We accomplished this with the Layout-composable, and some calculations. To finalize the layout, we added a bit of random rotation with a rotate-modifier.

The full code for this app can be found in the Cats-repository.

Have you built custom layouts? Anything fun to share? Or any learnings?

Links in the Blog Post

Don't Lock the Screen Orientation! Handling Orientation in Compose

2024-07-18T03:57:44.737Z

Yes, your app should work in both portrait and landscape modes - unless locked orientation is essential for functionality, like in a piano app. However, for most apps, locked orientation is not an option. Oh, and yes, the functionality should be similar in both modes, not hiding anything when the orientation changes.

In this blog post, I'll cover the topic of locked orientation. It's mainly concentrated on Compose things, but there might be something useful for Views, too. I've also included some good articles in the Read More section of the blog post, explaining, e.g., more about orientation locking themes on Views.

This blogpost was updated on 22nd of July to add example of using WindowWidthSizeClass.

Why Locking Orientation is a Problem?

When discussing locked orientation and its problems, we usually refer to locking the orientation to portrait mode. Unfortunately, this is a typical case among Android apps.

Why is this a problem, then? Some people prefer to use their phones in landscape mode because it gives them more screen width. A wider screen can make it easier for people who use, e.g., larger font sizes of screen magnification. And some people might have their phones mounted on, e.g., a wheelchair in landscape mode, and can't rotate the phone at all.

In these cases, if the app's orientation is locked in portrait mode, using the app might be more complicated or even impossible. That is not what any developer behind the apps wants, right? So, let's talk about how to support different orientations on your app.

It's Straightforward

From a purely UI point of view, supporting landscape mode is pretty straightforward. You just don't do anything - like prevent the screen rotation. This way, the landscape mode is available.

Of course, you need to test that the layouts actually look okay in landscape orientation. With Compose, the layout mostly works if you don't use exact widths for different elements and don't have sticky items that take up some vertical space on the screen. However, in case you notice some problems, I've described one way to handle different layouts for landscape and portrait modes later in this post.

But You Need to Remember Configuration Changes

But there is one thing: You need to remember configuration changes. Switching the screen orientation is a configuration change, which can then trigger all kinds of things.

Android developer documentation has an extensive page on reacting to configuration changes and the logic behind them: Handle Configuration Changes. In the following subsections, I'm going to concentrate on Jetpack Compose-related things. We'll first discuss UI-related changes and then data-related changes.

Handling UI Changes

Although I mentioned that the UI usually looks pretty okay in landscape mode if there are no sticky elements or fixed widths for elements, the experience could often be better.

Let's say we have a button with a short text like "Save" that takes the full width in portrait mode. In landscape mode, we would like to keep the button's width at 75% of the screen width. We have two ways to do this: Orientation and WindowWidthSizeClass. I'll first give an example with orientation, then discuss WindowWidthSizeClass.

Orientation

One way to accomplish this is to get the current orientation and then act on its value. We can get it from LocalConfiguration composition local. Let's look at an example:

@Composable
fun OrientationExample() { 
    val orientation = LocalConfiguration.current.orientation
    when (orientation) {
        Configuration.ORIENTATION_LANDSCAPE -> {
            // Version for Landscape orientation
        }
        else -> {
            // Version for Portrait orientation
        }
    }
}

Here, we first read the orientation from LocalConfiguration.current and then do something based on its value. So, for the example of our button, we could use this to save the value modifier uses for the width:

val buttonWidth = when (orientation) {
    Configuration.ORIENTATION_LANDSCAPE -> 0.75f
    else -> 1f
}

And then use it in the code:

Button(
    modifier = Modifier.fillMaxWidth(buttonWidth)
    ...
)

This way, our UI can react to screen orientation changes to provide a better user experience.

`WindowWidthSizeClass`

There's another, a bit more flexible way to handle different screen widths as well: WindowWidthSizeClass. It's a class that represents breakpoints and helps to build flexible layouts. As the documentation describes:

Each window size class breakpoint represents a majority case for typical device scenarios so your layouts will work well on most devices and configurations.

Appt.org gives an example of handling screen orientation in Jetpack Compose with WindowWidthSizeClass:

// Appt.org's Jetpack Compose code example

@Composable
fun WindowSizeExample(widthSizeClass: WindowWidthSizeClass) {
    when(widthSizeClass) {
        WindowWidthSizeClass.Expanded -> 
            // orientation is landscape in most devices including foldables (width 840dp+)
        WindowWidthSizeClass.Medium -> 
            // Most tablets are in landscape, larger unfolded inner displays in portrait (width 600dp+)
        WindowWidthSizeClass.Compact -> 
            // Most phones in portrait
    }
}

This way, the UI would be even more flexible, handling landscape and portrait modes and different screen configurations, such as foldable phones.

Handling Data with Configuration Changes

The other issue with non-locked screen orientation is data loss. If we store something on a composable, it will be recreated on each recomposition unless we wrap it to remember, which saves things over recompositions. remember, however, doesn't store its value through activity recreation, which happens with configuration changes.

If you need to store something inside a composable through configuration changes, you can use rememberSaveable. It works well with primitive data types, but if you need to store some more complex data, you'll need to utilize different state-saving methods listed in the Android documentation: State and Jetpack Compose - Ways to store state.

There's one more thing I want to talk about: Business logic. If you're storing your data to a ViewModel, orientation changes are handled on that side automatically. However, note that ViewModels don't survive system-initiated process deaths. For that, Android documentation suggests using SavedState APIs, and if you want to read more about that, the information is in Save UI state in Compose - SavedStateHandle APIs.

Wrapping Up

In this blog post, we've discussed screen orientation changes, how a non-locked screen orientation is an accessibility requirement, and what aspects you should consider when developing applications related to screen orientation.

What's your experience with locked screen orientations, either as a user or as a developer?

Accessibility Considerations with Stacked Cards Custom Layout

2024-07-25T03:26:41.374Z

A couple of weeks ago, I published a blog post Stacked Cards Layout With Compose - And Cats. The layout has some accessibility issues, and I aim to fix some of them in this blog post. There are a couple of issues I'm not fixing here because of the scope of this blog post; instead, I'm discussing the problems they're causing and possible solutions.

This time, I will also be pointing out some things that are good about the layout. I feel like I'm often just talking about problems and trying to find them, but this time, I'll share something that's working well, too.

Before we dive into the different aspects I chose for this blog post, here is a fair warning: This list is not extensive and doesn't contain all possible accessibility problems that this kind of layout might have. I didn't test with every possible assistive technology or setting. My goal was progress over perfection, and I believe that the modifications I'll list are already significant improvements to the accessibility of this layout.

Switch Access

The first assistive technology I'm going to talk about and improve the app for is Switch Access. It's a service that lets the user navigate their phone with one or more switches. If you want to learn more, the Android Accessibility Checklist I've created has a section about Switch Access: Test with Switch Access.

When testing with Switch Access, there was one problem I could find: When removing a card from the stack, the focus didn't go anywhere. It just disappeared. The reason for that is that the component on which the focus was had been deleted, and the accessibility service lost the focus.

One way to fix this issue is by moving the click event to the stack-component instead of the card itself. We can do this by adding a semantics-modifier with an onClick-lambda to the CardStack's modifier-property. Let's also move the lastItem outside the CardStack so that we can use it in the function we add:

// MainScreen.kt

val lastItem = catIds.value.last()

CardStack(
    Modifier.semantics {
        onClick {
            deleteCat(lastItem)
            true
        }
    },
) { ... }

The onClick function returns a boolean value because, under the hood, it's an AccessibilityAction. Accessibility actions return a boolean indicating whether the action was successfully handled.

This solution is not perfect - but it's progress. This way, the focus stays in place, and the user doesn't need to navigate back to the stack to be able to delete the next card.

Voice Access

One thing that could be improved for Voice Access usage is enhancing the content labels for the delete buttons. Even if we disable the buttons under the topmost card, there are two delete buttons: the topmost card and the single card at the top of the screen.

Why is this a problem? When a Voice Access user says "Tap Delete," there are two options for deleting. How Voice Access works is that when there is more than one available action with the same label, it displays numbers for each action, and then the user can select from them. So, in this case, to delete the card from the stack, the user would need to say something like "Tap Delete. Two."

That all works and doesn't sound like much of a problem, but if you're navigating with your voice all day, any way to save using it would be preferable. To be honest, I'm not sure if there is a good way to solve this issue for this particular case and if it's a priority to solve it (compared to some more obvious cases), but this is good to keep in mind.

There are a couple of problems for screen reader users. The most clear one is that this application displays images, and no content descriptions are available for any of the pictures. As the app uses images from an API, the responsibility of writing the content descriptions would fall under the API developers, and the app should just be able to use the descriptions.

Of course, if we wanted to improve the experience, we could think about some AI solutions to write text alternatives for the images. This solution could be an improvement, especially if the text is more descriptive than "Can be an image of an animal," as Facebook did (does? I'm not on FB anymore) automated captions. However, there are always risks, too - there is no human control over the generated texts, and they could end up being anything. That's why I'm advocating for the responsibility of the ones providing the images to write the text alternatives for them.

Another issue for screen reader users is related to the same thing as with Voice Access users: Delete buttons and their labels. Right now, especially without the content descriptions, screen reader users just have two delete buttons, with no context on what the heck they delete. To be honest, this UI right now (without the content descriptions) really sucks for anyone who can't see and relies on a screen reader for navigation.

Another problem I discovered was the same as for Switch Access: The focus disappeared after pressing the Delete button. Luckily, the same code also fixes the issue for a screen reader user, so we can mark that issue resolved.

The last improvement for screen reader users we're going to do is that we'll add semantic information for headings to help with navigation. We'll do this by adding a semantics modifier to the Title-component:

// MainScreen.kt 

@Composable
fun Title(text: String) {
    Text(
        modifier = Modifier.semantics { heading() }, 
        text = text,
        style = MaterialTheme.typography.titleLarge,
    )
}

This way, the title is annotated as a heading.

Keyboard

The following accessibility consideration relates to keyboard navigation. When testing the app with a keyboard, I found two issues: First, all of the cards' delete buttons in the stack were focusable, and when a card was deleted, the focus was lost.

A note before continuing: If you're wondering why I'm mentioning the focus issue again, the reason is that focus works differently for keyboards and accessibility services like screen readers and switch devices. That's why the problem needs to be handled twice.

Focus Only on Visible Buttons

First, we should make only the topmost card's delete button focusable and remove the focusability from the others in the stack. We will need a couple of things for this: First, the card should know if it's the topmost card, and we should set the focusProperties based on that.

Let's pass the last id on stack to CatCard, check if the current card is the last one, and set the focusability based on that:

// CatCard.kt

@Composable
fun CatCard(
    ...
    lastIdOnStack: String,
    ...
) {
    val isLastOnStackPerIds =
        remember(id, lastIdOnStack) {
            id == lastIdOnStack
        }

ElevatedCard(...) {
    IconButton(
        modifier =
            Modifier
                .focusProperties {
                    canFocus = isLastOnStackPerIds
                },
    ...
    ) { ... }

This way, we remove the focusability of the delete buttons under the topmost card, as they're not focusable if the id is not the same as the last card.

Recovering Focus After Delete

The second thing we'll need to do is fix the disappearing focus after deleting a card. The solution sounds straightforward: We'll need to make the previous card's delete button focusable and move the focus to it. In code, this requires a bit more work.

We'll need a function to handle the deletion of the card. We'll need to wait a bit after calling the ViewModel's delete function to allow the second item in the stack to be focusable. After that, we'll need to use FocusManager to move focus to the previous item. In code, this would look like this:

// MainScreen.kt

val scope = rememberCoroutineScope()
val focusManager = LocalFocusManager.current

fun deleteCat(id: String) {
    scope.launch {
        viewModel.deleteCat(id)
        delay(1000)
        focusManager.moveFocus(FocusDirection.Previous)
    }
}

We'll need to switch to using this function instead of calling the viewModel's function we did before:

// MainScreen.kt

CardStack {
    ...
    AnimatedCatCard(...) {
        deleteCat(id = id)
    }
}

After these changes, the focus goes to the previous item after card deletion.

Cognitive Considerations

While the app is simple, it does have some cognitive accessibility considerations. One thing that I noticed is that the delete button only has an icon — not any text accompanying it. Not everyone recognizes or remembers that the X-icon means deleting (or closing) something. They might feel confused when seeing that and not know what to do with it or how to remove an item from the card stack.

We could improve this by introducing accessibility settings for the app and adding a toggle to show the labels with icons. I've written a blog post about how to do that: Toggle Labels With Icons - Personalizing Accessibility.

Screen Orientation

I also tested the app with landscape mode, an important accessibility feature. As I did not lock the orientation to portrait mode, and as the data is stored in data store instead of state within a composable, everything works well, as you can see in the video:

If you want to learn more about supporting both landscape and portrait modes for your app, I've written a blog post: Don't Lock the Screen Orientation! Handling Orientation in Compose.

Larger Font And Increased Display Sizes

As the app doesn't have much text, increasing the font size works rather well, and the text scales. Also, the layout is flexible in size, so it works with increased display sizes. Here's a screenshot from when the font size is on the biggest one and the display size is on the largest selection:

Wrapping Up

In this blog post, we've looked into ways to improve accessibility of a stacked cards layout. We've discussed Switch Access, keyboard, Voice Access, and screen reader accessibility, as well as screen orientation, larger font sizes and increased display sizes, and cognitive considerations.

This commit contains all the changes mentioned in this blog post. It also contains some other minor changes, as the app has a bit more than just the stacked cards, so I had to modify other aspects to work with these changes as well.

Did you learn something from this blog post? Have you improved the accessibility of custom layouts in some ways? Please share!

Links in Blog Post

Android Accessibility Checklist

2024-08-07T02:56:34.666Z

I'm studying for my second master's degree (for fun) and finished with my thesis in the spring. As part of my thesis, I developed an accessibility checklist for Android developers. While completing all the checks doesn't guarantee that your app is 100% accessible, the checklist aims to help catch many possible accessibility problems.

In this blog post, I'll first share a bit about the development process and then share the checklist. If you're curious, the whole checklist with accompanying material is behind the following link: Android Accessibility Checklist.

Background

As mentioned, developing the checklist was part of my Master's thesis, which has been published, and you can find it from the following link: Towards More Accessible Android Applications: An Actionable Accessibility Checklist for Android Developers.

I conducted the research with the help of Design Science Research (DSR). I collected material for the initial checklist from prior research and available Android accessibility guidelines, evaluated it with five interviews with Android developers, and then constructed an improved checklist. Then, I created the website with the improved checklist and collected feedback and material for the last analysis with a Google Form. I analyzed the answers from both interviews and the questionnaire with the help of content analysis. The result of the research is the Android Accessibility Checklist, or as DSR calls it, an artifact.

The checklist itself consists of two sections. The first contains the checks that every Android developer should do, and the findings should be fixable by the developer. The second section includes checks that might not be fixable by the developer alone and might either require help from other functions or be a huge change. I'll explain the reasoning for some of these checks later in the blog post.

Now that the work with the thesis is over, and I don't need to think about the thesis' scope anymore, I will update the page and the checklist occasionally. I already have some things in mind from both learning and checking perspectives. Also, if you want to contribute, the checklist website's front page has a link to a form, which you can answer.

Before sharing the checklist, I'll say a few words about two checks/categories I had to make hard decisions about and the reasoning behind the decisions.

Some Thoughts on Text Alternatives and Screen Orientation

The first check I'm going to discuss is related to visual elements and text alternatives. Why is there no check for visual elements having a text alternative? The reason for this is that quite often the actual copy of the text alternative (or content description) is not within the developer's control. They might not know the intended purpose of the visual, or there might be a copywriter responsible for all the texts in the app. That's why I've included the check for text alternatives in the "Checks that might be out of your control"-section and not the actual checklist.

The other category I'm discussing is the orientation. I had to think about it a lot. Should I include a check to ensure the orientation is not locked? I wanted to, but I had to keep in mind the fact that the checklist aims to be as easy as possible to integrate, and most Android apps don't support both portrait and landscape modes. So, I decided not to include that check but rather have it in the "Checks that might be out of your control"-section.

The Checklist

Alright, let's get to the checklist! It's also available in the Checks-section of Android Accessibility Checklist.

Automated Tools

Ran Accessibility Scanner for the feature
- Read instructions for testing with Accessibility Scanner

Images and Other Visual Elements

Purely decorative images have content description set to null

The feature works with keyboard and D-pad
- Read instructions for testing with a keyboard
The feature works with Switch Access
- Read instructions for testing with Switch Access
The feature works with Voice control
- Read instructions for testing with Voice Control
The feature works with a screen reader
- Read instructions for testing with a screen reader
Focus order matches visual representation
Added accessibility actions for gesture based actions (e.g. swipe or drag and drop), or there is another way to interact than the gestures (e.g. buttons)
- Read instructions for building custom components

Orientation

Experience is similar for landscape and portrait modes

Semantics and Structure

Semantics (e.g. headings) are identified
- Read instructions for building custom components
Form elements (such as text fields, radio inputs and switches) have a text label
Custom components have correct semantics, state information and interaction patterns
- Read instructions for building custom components

Magnification

The feature works when using magnification
Read instructions for testing magnification
The feature works with font size set to the biggest size
- Read instructions for testing font size

Checks That Might be Out of Your Control (But Worth Checking!)

Images and Other Visual Elements

Every visual element that conveys meaning has a descriptive text alternative

Use of Color

The app/feature works even if user can't see colors

Orientation

Orientation is not locked to either mode

Audio and Video

Audio and video clips have captions

Wrapping Up

In this blog post, I've introduced an Android Accessibility Checklist I developed when writing my Master's thesis. The checklist and learning materials are available on the Android Accessibility Checklist site, which also contains a link to a survey if you want to help with further research.

What's your relationship with accessibility? Do you consider it when developing?

Beyond the Binary - More Inclusive Gender Options with Compose

2024-09-02T03:38:22.011Z

If your gender matches the one that was assigned to you at birth, you probably don't notice flaws in application design that enforce the gender binary. But if it doesn't, and especially if your gender is beyond the woman-man binary, you constantly notice user interfaces that exclude you.

For example, what should you select if you aren't a man or a woman, and those are the only options in a form? In some cases, forms might include the option "other". But... It underlines that you're something other and don't even have a category. As someone who has felt their entire life like an outsider and the other in many ways, I can tell you that it doesn't do good things to your mental health.

So, in this blog post, I'll discuss the concept of gender a bit and then demonstrate one way to build a more inclusive gender selection with Jetpack Compose. Finally, at the end, I'll list some resources related to this topic.

Gender Beyond the Binary

Let's start with the basics: Gender and sex are separate things. In some languages, like Finnish, the word for both is the same - "sukupuoli" - but, for example, English differentiates them. And neither of them is binary.

Gender is a social construct, and each culture has its own norms for genders. There are multiple genders, and a person might describe themself with one or more. Some examples include woman, man, non-binary, agender, genderqueer, demigender (e.g., demigirl or demiboy), or genderfluid.

If you want to learn more, I've listed some resources in the Resources-section.

Asking User's Gender

Gender is asked in many locations - it might be surveys, settings for an app, and many other places. I'll concentrate on app development as I write about app development, and the specific case of app settings because that's where I've seen this gender selection pop up the most frequently.

Before diving into the technical implementation of more inclusive gender options, I want to discuss whether there is a need for gender data and making the selection optional. Ruth Dillon-Mansfield discusses these topics, and more, in her article How to Ask About Gender in Forms Respectfully, which I recommend checking.

Do You Actually Need That Information?

The first question related to asking the user's gender is whether you really need it. Is the form asking it just because it's customary to do so, or because the company wants more data for marketing purposes, or is the data used for something the user benefits from?

When this information is asked, the reasons for requesting it should always be explained. Why is it asked? How is the data used? How it's stored? So remember to include that information easily available next to the form where this is asked.

Make It Optional

Not everyone is comfortable sharing their gender identity in all instances, even if you have good reasons for asking it. There might be a lot of reasons for that, and those reasons should be respected.

More Inclusive Gender Options

Let's look at one way to build a more inclusive gender selection component on Android.

The component we're going to build will have the following:

Multiple options beyond the "Man/Woman" binary
Possibility of not disclosing gender
A text field to type the gender if the given options don't match
Possibility to select more than one option

The component looks like this:

This list could include more genders, but as this is a demo, I decided to have it as short as possible while still allowing the user to input their gender.

We will need two UI components: A checkbox and a checkbox with a text field. Let's build the checkbox first, and then we can use it with the text field:

@Composable
fun CheckboxWithLabel(
    checked: Boolean,
    label: String,
    onCheckedChange: (Boolean) -> Unit
) {
    Row(
        modifier = Modifier.toggleable(
            value = checked,
            role = Role.Checkbox,
            onValueChange = onCheckedChange
        ),
        verticalAlignment = Alignment.CenterVertically
    ) {
        Checkbox(
            modifier = Modifier.clearAndSetSemantics {},
            checked = checked,
            onCheckedChange = onCheckedChange
        )
        Text(label)
    }
}

This component takes in the value for the checkbox checked-state, a function to toggle the value, and a label for the checkbox. Inside the component, we're wrapping the label and the checkbox together with a Row, adding a toggleable-modifier to the parent Row, and then clearing semantics from the Checkbox.

We're doing this for increased accessibility so assistive technology users can use the checkbox more easily. It also extends the touch area to cover the label, too, not just the checkbox component. If you want to read more, I've written a blog post about improving Android accessibility with modifiers in Jetpack Compose, which explains these decisions more.

The second component, a checkbox with a text field, takes in the same parameters as the previous component and two additional parameters: Value and value setter for the text field. The code for the component looks like this:

@Composable
fun CheckboxWithTextField(
    checked: Boolean,
    label: String,
    textValue: String,
    onTextChange: (String) -> Unit,
    onCheckedChange: (Boolean) -> Unit
) {
    Column {
        CheckboxWithLabel(
            checked = checked, 
            label = label, 
            onCheckedChange = onCheckedChange
        )
        if (checked) {
            OutlinedTextField(
                modifier = Modifier
                    .fillMaxWidth()
                label = {
                      Text("Type here")
                },
                value = textValue,
                onValueChange = onTextChange
            )
        }
    }
}

We're using the CheckboxWithLabel component and passing in the required parameters. In addition, if the checkbox is checked, we show an OutlinedTextField, for which we pass the additional parameters.

Finally, we use both of these components to display the options. A list of options with the label and field type mapped together is used in this case. The field types are defined as an enum, which is then used in the list:

enum class OptionType {
    Boolean,
    String
}

val options =
    listOf(
        "Woman" to OptionType.Boolean,
        "Man" to OptionType.Boolean,
        "Non-Binary" to OptionType.Boolean,
        "Let me type" to OptionType.String,
        "Prefer Not to Disclose" to OptionType.Boolean,
    )

Oh, and it should go without saying: Trans-women are women, and trans-men are men. If you want to list them separately, the other options would be "Cis-woman" and "Cis-man". A cis-person is someone whose gender conforms to the one assigned at birth to them.

In the parent component, we're mapping through the options and then setting the correct component:

options.map { (label, type) ->
    when (type) {
        OptionType.Boolean ->
            CheckboxWithLabel(...)
        OptionType.String ->
            CheckboxWithTextField(...)
    }
}

In the example, I've used a component-level state to store the selected values and the text value. In an actual application, the values would be stored somewhere permanently (like a database), so I'm leaving that part out of this blog post.

The complete code I've used is in this Github gist.

Wrapping Up

In this blog post, we've discussed making gender options more inclusive beyond the binary. I hope that after reading this blog post, you'll remember at least these things:

Gender options should be more diverse than just "Man" and "Woman".
Disclosing gender should be optional.
The reason why gender information is asked should always be explained.
It should be possible to select multiple options, and there should be option for self-description.

Thank you for reading!

Resources

Testing Android App Accessibility: Clue

2024-09-15T03:27:11.064Z

In Droidcon Berlin, I gave a talk titled "Is This App Accessible? A Live Testing Demo," in which I tested one app from an accessibility perspective. The audience voted for the app from three options and selected Clue, a period tracking app. The other two were the Droidcon app and Provinssi's (a Finnish music festival I attended in June) app.

In this blog post, I'll summarize the talk and probably add some things I was supposed to say on stage but forgot. So note that this post might slightly differ from the actual talk I gave. If you want to watch the talk, it's available on the Droidcon website: Is this app accessible? A live testing demo

Note that as the talk was 40 minutes long, I did not do that extensive accessibility testing, and the app may have more issues than I found.

Why I Chose Clue?

When I was thinking about the possible apps for testing, I wanted to include an app that's not the most typical example in developer conferences and learning materials. I can't count how many examples of different vehicles I've seen (hello, inheritance!). Or examples having something related to movies.

As the gender balance in tech is skewed towards those who don't have cycles, I wanted to bring this topic in. I also think that periods should be talked about way more in different settings - that would help to dismantle the taboo around them, as well as all those stupid stereotypes and jokes around menstruating people.

And why Clue, why not some other app? It's because their app is the best one. Their app is the least heteronormative I've encountered out there. It doesn't assume my gender, nor does it assume the gender of the partner if I wanted to share my cycle data with someone.

And speaking of the partner mode... I haven't used it, but I haven't also seen any creepy "we will let your (man) partner know that based on your cycle, you want to have sex"-messages. I'm not naming names, but some other period-tracking apps do this.

Note! Clue didn't pay me to advertise them! These opinions are purely based on my own experiences and thoughts. I just really like the application.

I was (positively) surprised that the audience selected Clue for testing. I was pretty sure everyone would have wanted to see me break the conference app. Maybe next time?

About the Tests

The tools and settings I used during the talk were the following:

Accessibility Scanner
Switch Access
Larger font size and display
Remove animations setting

For those of you who are not familiar with these tools and settings, here's a short description of each of them:

Accessibility Scanner is an app for semi-automated accessibility testing, and it can detect accessibility issues in the following categories: Content labels, Touch target size, Clickable items, and Text and image contrast. It's available in Google Play, so you can test any Android app with it - even without access to source code. I have written a blog post on how to test with Accessibility Scanner: Testing with Accessibility Scanner.

Switch Access is a service that lets a user use their phone with one or more switches. Usually, when two switches are in use, one is used for navigating forward, and the other is used for completing actions. Google has released a video on how to set up Switch Access, so if you want to check it out, it's available in YouTube: Switch Access for developers - Accessibility on Android

Larger font size and display are both set from the phone's accessibility settings. You can control both font and display sizes, which is useful, especially when testing for accessibility issues with larger phones, while many users have smaller ones. For the testing purposes, I usually crank them both to the largest to find the most of the problems.

Remove animations-setting is an accessibility setting, which removes animations as the name states. On some operating systems, the setting is called "Reduce motion", and I often keep referring to it as such. I've written about the setting for Android developers: Android, Animations and Reduced motion.

From these four, I actively tested the first three; for the remove animations-setting testing came sort of for free, as I always have it on.

Accessibility Scanner

When testing with the Accessibility Scanner, I tested three screens: The main screen with the main view showing the current cycle data, then the menu, and finally, the Analysis-page. The app took the screenshot from the Analysis-page before the page had loaded, so there was not much useful findings, but the other two revealed some issues.

Here's a screenshot of the main screen with annotated issues. Note, that my font size was already a bit bigger than the default, so that's why the "Try now for free"-button looks a bit odd. We'll get back to that in the font size section.

The picture displays an orange rectangle around the text, like the button mentioned above, and the text "Subscribe to Clue Plus and support our mission" is next to it, as well as the "Day"-text above the current cycle day and the text "About the follicular phase". The drop of blood-icon also has an orange rectangle around it.

On the Accessibility Scanner app, I can click each of these items to get more information. For example, the drop of blood-icon reveals the following screen, describing that that item may not have a label readable by screen readers:

Why is it a problem? This element is interactive (a button, even though it doesn't really look like one), and if a person who navigates with a screen reader focuses on it, they hear that it's an unlabeled button. They probably have no idea of what they can do with that element.

The Accessibility Scanner app also lets us see all the issues from different screens, categorized by screen or category. For this test run, we can see that there were five categories:

Most issues were with text contrast; for example, all of the annotated texts on the main screen had some level of text contrast issue.

Switch Access

I also tested the app with Switch Access. I found two main issues during the short testing: I couldn't switch days from the visualization with the current cycle day visible, and the "Track"-button in the bottom bar didn't work.

The first issue has probably something to do with the fact that it's most likely built with canvas. Adding navigation to the canvas is not straightforward because you can't make individual items inside the canvas, e.g., focusable. You can add pointer tracking easily, but you can't add focusability, etc.

I suggest adding controls, like buttons, that would control the currently visible item so that anyone who can't use a pointer input could control the visible item with those. I've explained this topic in my blog post More Accessible Graphs with Jetpack Compose Part 4: On-Screen Control Buttons, so if you want to read more, head there.

The other problem is the "Track"-button not being reachable with switch access. While the drop of blood icon leads to tracking, the same place where the unreachable "Track"-button does, it's not clearly marked as a button, and it doesn't have a label, so it can be hard to know where it leads.

Solving that would require finding out why it's not reachable and making it accessible with a switch device.

Largest Font Size and Display Size

My last test was turning font and display sizes up to the maximum. As you can see from the picture, not everything worked:

The screen above has multiple problems. The biggest, I'd say, is that in many places, texts are cut out, and it's not clear what they say. For example, the bottom bar texts are far from clear - and if you don't do well with iconography (meaning, you don't always understand what each icon means), it might be hard to navigate in this app without knowing where the bottom bar item leads.

How do we fix these problems? Usually, components are not scaling because some elements are fixed in size or position. It leads to either the fixed size/position component not scaling well or affecting other components around. So, the actual fix depends on the underlying problem. The ultimate goal is to have all the information available for users who turn the font and/or display sizes up.

Remove Animations -Setting

I did not actively try to find anything related to the Remove animations setting. My strategy was that if I encounter animations, then I know this setting is not working. I did not notice anything when testing different app screens, so I'd say Clue passed this test very well.

Wrapping Up

In this blog post, I've discussed accessibility testing of the Clue app. While there were problems, I must say that I've seen way worse apps out there from the accessibility point of view.

The tests I did were something we, as developers, can (and should!) do while developing. Once you start testing and do it a couple of times, they become straightforward - the most challenging part is actually remembering to test for accessibility.

Do you test for accessibility? Or have you learned something from this blog post?

Links in the Blog Post

Paint the Stars - Drawing with Compose and Canvas

2024-09-26T06:30:01.926Z

I've always struggled with drawing in Canvas, not just with Compose's Canvas but with any technology. I've understood enough to be able to do the tasks I needed to do, but at the same time, I've tried to avoid working with it.

On one Sunday, I wanted to do something creative. I also wanted to code, so I started with the idea of creating a loading spinner with Canvas. One thing led to another, and I made a nice animation, that's more of a piece of illustration than a loading spinner:

In this and the following blog post, I'll share how I did it and some things I learned along the way. The first blog post is about drawing the elements on canvas, and the following is about animations.

The Idea

The initial idea for the space-themed illustration came from a t-shirt I have. It's this I Need Space t-shirt from the Spark Company. I initially thought I could try to reproduce the same picture, but once I was done with the Saturnus, I decided to go rogue.

I chose to add other elements and make the stars differently. I'm delighted with how it turned out! Let's dive into creating the illustration next. You can find the complete code for this blog post from this code snippet.

Components

Before talking about the components, I want to note something: The exact numbers I'm showing here fit this particular drawing and can't be generalized for the most part. I've calculated the positions and sizes based on the defined canvas, not for a resizeable canvas.

The first component is the background and canvas itself. There's a Column as the parent component and then Canvas as a child. This lets us define the animations and other properties you can't define in Canvas.

For drawing the background, we'll use a drawBehind-modifier in the parent Column, draw a round rectangle and define a radial gradient brush with some colors:

Modifier.drawBehind {
    drawRoundRect(
        size = size,
        cornerRadius = CornerRadius(44f),
        brush =
        Brush.radialGradient(
            colors = listOf(
                Color(0xFF02010a),
                Color(0xFF04052e),
                Color(0xFF140152),
                Color(0xFF22007c),
                Color.Transparent,
            ),
            radius = size.width * 0.75f,
        ),
    )
},

At this point, the drawing looks like this:

Saturn

The first planet we're going to add is Saturn. To draw it, we'll need three elements: The outline of the planet, the rim, and the line inside the planet. Let's define an extension function, drawSaturn, which takes in the center offset of the planet and the outline style and draw the outline:

fun DrawScope.drawSaturn(
    center: Offset,
    outlineStyle: Stroke,
) {
    drawCircle(
        center = center,
        color = Colors.white,
        radius = 100f,
        style = outlineStyle,
    )
}

It's a circle, which utilizes the center coordinates and outline style (which is, by the way, a stroke with a width of 4f). We also set a radius for it; in this case, it's a hardcoded value of 100f.

Next, we draw the line inside the planet:

drawArc(
    topLeft = Offset(
        center.x - 80f, 
        center.y - 80f
    ),
    color = Colors.white,
    startAngle = 180f,
    sweepAngle = 90f,
    useCenter = false,
    style =
        Stroke(
            width = 2f,
        ),
    size = Size(160f, 160f),
)

For that, we use the drawArc-function. It's a bit different from the drawCircle-function, which takes in the center coordinates and radius. For an arc, we need to define the top left coordinate for the rectangle area around the arc and the size of the arc.

The startAngle defines the angle where the drawing starts, and the sweepAngle for how long it continues. Position 0 for the angles is at three o'clock, so we want to start at 180f degrees, and the sweep angle is 90f to accomplish the look we want.

We must also set the useCenter to true; otherwise, it would draw an extra line through the center.

The last element to complete the Saturn is the rim. As it's not a complete circle, we're using drawArc. The code looks like this:

rotate(40f, center) {
    drawArc(
        color = Colors.white,
        startAngle = 217f,
        sweepAngle = 285f,
        useCenter = false,
        topLeft = Offset(
            center.x - 50f, 
            center.y - 150f
        ),
        style = outlineStyle,
        size =
            Size(100f, 300f),
    )
}

Note that the size of the area where the arc is drawn is not square - because of the shape of the rim, we need to use a non-square size to make it more like an ellipsis than a circle.

At this point, the drawing looks like this:

Planet

The next element to add is another planet. I didn't want to name the planet, and I wanted to make it more generic, so we'll just call it a planet.

The planet has two elements: The planet itself and the moon orbiting around it. Let's start with the planet's outline, which is a circle:


drawCircle(
    center = center,
    color = Colors.white,
    radius = 80f,
    style = outlineStyle,
)

This code is straightforward; we draw a circle into the position defined by the center-variable, and with a radius of 80. Next, we draw the lines in the planet. For that, we use three paths, two of which have a dashed path effect, and one is a solid line. The code for the first line (the topmost) looks like this:

drawPath(
    path =
        Path().apply {
            moveTo(center.x - 82f, center.y)
            quadraticTo(
                center.x - 45f, center.y + 5f, 
                center.x, center.y
            )
        },
    color = Colors.white,
    style =
        Stroke(
            width = 3f,
            pathEffect = PathEffect.dashPathEffect(
                floatArrayOf(60f, 10f, 50f, 10f), 
                0f
            ),
        ),
)

The others are similar; the numbers and path effects are slightly different. You can find the link to the complete code at the start of the blog post.

So, we're drawing a path from the edge of the circle towards the center. As the line needs to be slightly curvy, we're using quadraticTo to accomplish the effect.

The other component of the planet is the moon. First, it has the moon drawn as a circle:

drawCircle(
    center = Offset(
            center.x - 100f, 
            center.y + 80f
     ),
    color = Colors.white,
    radius = 15f,
    style = outlineStyle,
)

And then, for the line that makes it look like the moon is orbiting around the planet, we use drawArc:

drawArc(
    topLeft = Offset(center.x - 125f, center.y - 125f),
    color = Colors.white,
    startAngle = 160f,
    sweepAngle = 200f,
    useCenter = false,
    style =
        Stroke(
            width = 2f,
            pathEffect =
                PathEffect.dashPathEffect(
                    floatArrayOf(160f, 70f, 50f, 80f, 40f, 40f),
                    0f,
                ),
        ),
    size = Size(250f, 250f),
)

There's nothing new with the arc - it takes in the top left coordinates relative to the moon. The start angle is 160 degrees, and it goes around 200 degrees. It doesn't use the center to avoid the third line through the center, and it has dashedPathEffect to create the look.

At this point, the drawing looks like this:

Stars

The final elements of the illustration are the stars. Let's create an extension function for DrawScope to draw a star and then use it to draw all the stars.

The function takes in the size of the star, center offset, color of the star, and outline style. Let's define it:

fun DrawScope.drawStar(
    starSize: Size,
    center: Offset,
    color: Color,
    outlineStyle: Stroke,
) {
   ...
}

We're using a path with quadratic bezier curves from one point of the start to another. The star has four points, and if we imagine the space for a star as a square, the points are in the middle of the outlines. Let's start from the middle of the top side:

val path = Path()

path.moveTo(center.x, center.y - starSize.height * 0.5f)

After that, we want to draw a quadratic bezier curve from one point to another and use the center of the area for the star as the curve point. For the line from the top side to the right side, it would look like this:

path.quadraticTo(
    center.x,
    center.y,
    center.x + starSize.width / 2,
    center.y,
)

The first two parameters are the coordinates for the control point, and the latter two are the point where the line ends. The other three lines look the same - just the end coordinates change based on the target coordinates.

After drawing those four lines, we just need to draw the path:

drawPath(
    path = path,
    color = color,
    style = outlineStyle,
)

Now that we have the drawStar-function, we can draw the stars. We want to place them around the planets, and we want them to have different colors. We'll also need to store the size of the star. Let's define a data class to handle all this:

data class Star(
    val size: Float,
    val topLeft: Offset,
    val color: Color,
)

Then, we can define a list of stars. It would look something like this, with an example of one star in a list:

val starsList =
    listOf(
        Star(
            size = 30f,
            topLeft = Offset(size.width * 0.5f, size.height * 0.5f),
            color = Colors.stars[0],
        ),
    ...
)

We can define different star sizes and have a couple of different colors. The position for each star is calculated manually.

We can then use the list of stars and draw them with the function:

starsList.forEach { (starSize, offset, color) ->
    drawStar(
        starSize = Size(starSize, starSize),
        color = color,
        center = offset,
        outlineStyle =
            Stroke(
                width = 2f,
            ),
    )
}

After these code changes, the illustration looks like this:

Wrapping Up

In this blog post, we've created an illustration with Canvas. It is currently static, but in the following blog post, we will animate the items in the illustration.

How do you feel about your skills with Canvas? Are you confident, or is it something you're avoiding altogether?

Links in the Blog Post

Floating in Space - Animations with Compose and Canvas

2024-10-06T10:17:03.902Z

In my previous blog post, Paint the Stars — Drawing with Compose and Canvas, I shared how I wanted to be better with Canvas and Compose and created an illustration with planets and stars. This blog post shares how to animate those elements. In the end, the result will look like this:

Full code is available in this snippet.

Animations

Stars

Let's start with the stars. In the previous blog post, we defined the Star data class like this:

data class Star(
    val size: Float,
    val topLeft: Offset,
    val color: Color,
)

From these values, we want to animate the size of the stars. We'll do it by defining a multiplier that we will use with the star sizes to create the effect of the stars twinkling. We do this with infiniteTransition and animateFloat:

val infiniteTransition = 
    rememberInfiniteTransition(label = "infinite")

val starSizeMultiplierOne by infiniteTransition
    .animateFloat(
        initialValue = 1f,
        targetValue = 1.5f,
        animationSpec =
            infiniteRepeatable(
                animation =
                    tween(
                        durationMillis = 3000,
                        easing = animationEasing,
                    ),
                repeatMode = RepeatMode.Reverse,
            ),
        label = "starSizeMultiplierOne",
    )

For the starSizeMultiplierOne, we give the initial value of 1, meaning that as it will act as a multiplier, the size would be 1 * size. The target value is 1.5, and as the repeat mode is Reverse, the float will animate between the size multiplied by 1 and 1.5. This transition creates a growing and shrinking effect.

As we want the stars to look realistic and not animate at the same speed, we need to define two animated multipliers. Let's define another one:

val starSizeMultiplierTwo by infiniteTransition
    .animateFloat(
        initialValue = 0.7f,
        targetValue = 1.7f,
        animationSpec =
            infiniteRepeatable(
                animation =
                    tween(
                        durationMillis = 2300,
                        easing = animationEasing,
                    ),
                repeatMode = RepeatMode.Reverse,
            ),
        label = "starSizeMultiplierTwo",
    )

This one has a bit shorter animation duration, and the initial and target values are different, so the twinkling happens at a different rate from the first multiplier.

Now we'll just need to pass these multipliers to stars:

val stars =
    starsList.mapIndexed { index, star ->
        val multiplier = if (index % 2 == 0) 
            starSizeMultiplierOne 
        else 
            starSizeMultiplierTwo

        star.copy(
            size = star.size * multiplier,
        )
    }

We map through the list of stars defined previously, return copies of the star with the multiplier attached, and store them in a new list. Later, when drawing the stars, we use this new list.

In the case of the code snippet, this mapping through the list might feel redundant - why just not put the multipliers in when defining the stars? Well, in this case, it would work. But if we defined the stars outside the component, animated values can be hard to attach, so this would be the strategy.

Planet

The next thing we want to animate is the planet - or the moon orbiting around it, to be exact.

In the previous post, we defined how to draw the planet and the moon, and the source code showed an extension function called drawMoon. Let's extend it and pass in a parameter called degrees:

fun DrawScope.drawMoon(
    center: Offset,
    outlineStyle: Stroke,
    degrees: Float,
) {
...
}

Then we wrap the contents of drawMoon with a rotate, which uses the degrees for rotation and center for pivot so that the rotation happens around the center of the planet:

rotate(degrees = degrees, pivot = center) {
...
}

In the top-level component, we define the degrees, which is an animated float value:

val degrees by infiniteTransition
    .animateFloat(
        initialValue = 360f,
        targetValue = 0f,
        animationSpec =
            infiniteRepeatable(
                animation =
                    tween(
                        durationMillis = 3000 * 6,
                        easing = LinearEasing,
                    ),
            ),
        label = "degrees",
    )

For the initial value, we use 360f, and as the target value, 0f. These values create the effect that the moon orbits counter-clockwise around the planet.

Saturn

The last item we animate is Saturn. Its movement is subtle - slightly moving up and down to create a floating effect.

In the previous blog post, we defined an extension function, drawSaturn, that takes in top-left coordinates and outline style. We can use the top-left coordinates for the effect.

First, let's define center offset, an animated float value we're going to use:

val centerOffset by infiniteTransition
    .animateFloat(
        initialValue = 0f,
        targetValue = 2f,
        animationSpec =
            infiniteRepeatable(
                animation =
                    tween(
                        durationMillis = 3000,
                        easing = EaseIn,
                    ),
                repeatMode = RepeatMode.Reverse,
            ),
        label = "centerOffset",
    )

As you can see, the initial value is 0f, and the target value is 2f. We can then use this and change the parameters we pass to drawSaturn by adding the centerOffset to the top-left coordinates:

drawSaturn(
    center =
        Offset(
            size.width * 0.25f + centerOffset,
            size.height * 0.25f + centerOffset
        ),
    outlineStyle = outlineStyle,
)

This way, the x and y coordinates have an extra amount of animating from 0f to 2f, creating the floating effect.

Wrapping Up

In this blog post, we've covered animating drawings on Canvas. All the animations used animated floats in different ways. And as we can see, small changes add a lot of movement to the Canvas.

I hope you've enjoyed this blog post and learned something!

Links in the Blog Post

First Impressions of Compose Multiplatform

2024-10-17T13:43:23.746Z

I finally had the time to dive into Compose Multiplatform - and this was also my first experience with Kotlin Multiplatform. I'll share my first impressions from using this technology in this blog post.

Some words from my background: I'm an Android developer who's confident with Kotlin and Compose. I've been working with different languages and frameworks before switching to Android development, so I could say learning new things is easy. However, I've never done any iOS development, so that part is entirely new to me.

The app I'm working with is currently just UI, and I have yet to dive into any architectural components, such as working with databases or view models. So, that's the context for these thoughts, and it's likely that once I get deeper into the development and concepts, I'll have more opinions and thoughts.

The App I'm Building

The moment I started writing the blog post, I realized that it might be helpful to talk about the app I'm building here. So here we go.

It's an app version of neule.art, a color picker for knitted sweaters I created a few years ago. In the first version, there's just the picture of the sweater (the same as on the website) and modals opening for choosing the color from the list of colors. The colorways are based on the colors of Istex Lettlopi, a yarn often used for Icelandic sweaters.

When I created the website, I hand-drew the picture on top of an image of my friend wearing a sweater and then turned it into an SVG. In the app, I used Canvas to replicate the illustration. Here's what the app looked like at one point of development:

Now that you have an idea of what I was building, let's get into my thoughts about Compose Multiplatform.

Some Things Just Work

After I had created the first version of the app, there was one thing I was really surprised about: On the UI level, things just worked.

One of these working things was the illustration. I first drafted the illustration for another project with Compose (as part of my explorations with Canvas) and wanted to port it to a Kotlin Multiplatform app. What did I do? I copy-pasted the code and built it, and it just worked on both Android and iOS. I don't know why, but I expected some problems at that point.

Other UI components I used at this point also just worked. Sure, I was building with the familiar elements, so everything looked like Android apps, even on iOS, but nothing crashed. I could run the application on both platforms.

Once I ensured nothing crashed, I wanted to make the color picker modals more native-like for iOS. That leads to the next thing I realized - there aren't that many resources available yet.

Lack of Resources

So, when I started investigating how to create the iOS-like color picker, I did not find that much material out there. Yes, there are the official docs (both for Compose Multiplatform and for iOS), but I feel like as someone who has never done iOS development, the bridge between these concepts is still missing. The technology is still so new and evolving, that there are a lot of blank spots, and it can be hard to find any blog posts, videos, or any other resources to understand how to apply the basic concepts to action.

And this is normal for new technologies - it takes time to build the community, and for developers to experiment and find these things, and start writing about more complex use cases. That's something I've seen with Android accessibility topics as well.

In this particular case, if I had more experience with iOS development, I think I could apply that knowledge pretty straightforwardly. But I don't, so it will take time, asking around from more knowledgeable people, and some trial and error. And once I get there, I will, naturally, create some of those resources I'm looking for now.

Also, it's worth noting that Compose Multiplatform for iOS is still in Beta, so it's also natural that there aren't too many resources around.

However, not everything is lacking resources. Some things are documented well, and I really enjoyed learning about the expect / actual -pattern used to bridge the gap between native implementations and shared code. Let's talk about that next.

Expect / Actual Pattern is Awesome

So, in Kotlin (and Compose) Multiplatform, shared code is written for all platforms, and platform-specific code can be written for individual platforms. It also has this pattern to write a function in the shared code, annotate it with expect, and then create the actual implementations in native platform code to work in different environments. And I love it.

I think these kinds of patterns make multiplatform development a compelling option when you can actually write the code for the platforms in native languages if needed. It also allows flexibility - if some shared implementation doesn't work, or if you want to build apps to match the expected experiences on different platforms, it's possible this way.

I am comparing this experience with coding with React Native and using apps that have been coded with React Native, and I am excited. I keep telling everyone that switching to Android and Kotlin from JavaScript (and TypeScript) has been the one thing that has improved my life quality, and being able to build cross-platform apps with Kotlin is just awesome.

In addition, with Kotlin and Compose Multiplatform, maybe the apps would not always look like iOS apps. For some reason, all the React Native apps I've used are more iOS-y than I'd like to see on my Android device.

Wrapping Up

So, all in all, my experiences with Compose Multiplatform (and Kotlin Multiplatform) have been positive so far. I recognize that the technology is still evolving, but I see a lot of potential for streamlining app development. As an Android developer, I really hope that it will get adopted more and more. I enjoy building apps with Kotlin.

Links in the Blog Post

Not a Phase - Text with Compose and Canvas

2024-11-10T13:10:55.040Z

I've continued my journey with Compose and Canvas! After exploring drawing and animating shapes, I wanted to learn more about text. Bi-visibility Day was coming, so I drew a small animation to publish on Instagram. The final animation looks like this:

In this blog post, we will look at how to add text to Canvas and position and animate it. We're also utilizing custom Google Fonts in the drawing.

If you're interested in reading the first two posts, here are the links:

Before We Start

Before we start drawing, I want to say a few words about the design. It has the moon in the waning crescent phase, with a dashed line to complete it to the full moon shape. The text says, "Not a phase".

Now, if you're familiar with the discrimination and stereotypes bisexuals face, you probably already know what all of this means. But for those who are not, one of the stereotypes is that bisexuality is "just a phase on the way to being straight/gay".

But it's not - it's an (umbrella) term for people who feel attraction towards their own and other genders. And even if a bi person is in a monogamous relationship with a person from one gender, it doesn't make them straight/gay. They're still bi.

So yeah, we're here. We exist.

Now, let's get to the coding part.

Drawing the Text

Measuring

Drawing text on Canvas is a two-step process: First, measure the text and then draw it. To start with measuring, we'll need a TextMeasurer, and with Compose-code, we have this neat remember-function we can use:

val textMeasurer = rememberTextMeasurer()

For measuring, TextMeasurer has a function measure, which takes in the text as either AnnotatedString or String, and a bunch of other (mainly) optional parameters that affect the size of the text. Things like density, layoutDirection, style, fontFamilyResolver, and others.

We will divide the text into two strings, as we want to animate and position them a bit differently. As both of our texts are just simple strings with one style, we can use the String-version for both. The first version of the "Not"-text looks like this:

val notText =
    textMeasurer.measure(
        text = "Not",
        style =
            MaterialTheme.typography.titleSmall.copy(
                brush = Brush.linearGradient(
                    colors = Colors.biFlag
                ),
            ),
    )

For the measure-function, we pass in the text and then styles. We want to use the theme typography here for straightforwardness, so we copy the small title styles and add a brush to have a linear gradient as the text color. Here, we're using the bi-flag colors pink, purple, and blue.

The second text is pretty similar:

val phaseText =
    textMeasurer.measure(
        text = "a phase",
        style =
            MaterialTheme.typography.titleLarge.copy(
                brush =
                    Brush.linearGradient(
                        colors = Colors.biFlag,
                    ),
                fontSize = 30.sp,
            ),
    )

For this text, we're utilizing the large title styles from the theme. In addition to gradient colors, we're setting the font size to 30 sp to make the text bigger.

Alright, now we have everything we need from the measuring step. Next up is drawing the texts on canvas.

Drawing

Compose Canvas has a method called drawText for drawing text. It takes in a TextLayoutResult, which is the type that measure function returns. In addition, it takes other parameters meant for styling and positioning the text on Canvas.

For the notText we defined in the previous subsection, the drawText would look like this:

drawText(
    textLayoutResult = notText,
    topLeft =
        Offset(
            size.width * 0.25f,
            size.height * 0.6f,
        ),
)

We pass in the text layout result, and then we define the topLeft offset to position the text correctly.

The other text is a bit different. We want to position it relative to the notText, so we use notText for calculating the correct position:

drawText(
    textLayoutResult = phaseText,
    topLeft =
        Offset(
            x = size.width * 0.35f,
            y = (size.height * 0.6f + notText.size.height * 0.7f),
        ),
)

So here, we define the y-offset to be the same as for the notText, and then we add 70% of the height of the notText. This could be the whole height, but I wanted to keep less break between the texts.

After these steps, our text looks like this:

There is just one thing left for the drawing - using custom fonts. Let's talk about that next.

Adding Fonts

For this animation, I wanted to have custom fonts. After playing around with Google Fonts, I decided that the two fonts I'm using are Poppins and Damion.

Android documentation has a page about adding fonts to your project: Work with fonts. However, I accidentally found that Android Studio lets you add Google Fonts as XML files straightforwardly. Here's how it happens:

Go to Resource Manager and select the "Font"-tab.
Click the "+" button to add new resource.
Select "More Fonts...".
Find the Google Font you want to use, select weights, and press OK.
Let Android Studio add everything needed, like the certification for fonts.

However, previews don't work correctly if you do it this way and don't import the ttf-files for fonts. So, if you rely on previews when developing, importing those files should resolve the issue.

After the font is available, the next thing to do is to use it in the styles. Here's the code for the font families we're going to use:

val PoppinsFontFamily =
    FontFamily(
        Font(R.font.poppins_bold, FontWeight.Bold),
    )

val DamionFontFamily =
    FontFamily(
        Font(R.font.damion, FontWeight.Normal),
    )

Then we add the font families to both texts - Damion for the "Not" text and Poppins to the "a phase"-text:

val notText =
    textMeasurer.measure(
        text = "Not",
        style =
            MaterialTheme.typography.titleSmall.copy(
                ...
                fontFamily = DamionFontFamily
            ),
    )

And

val phaseText =
    textMeasurer.measure(
        text = "a phase",
        style =
            MaterialTheme.typography.titleLarge.copy(
                ...
                fontFamily = PoppinsFontFamily
            ),
    )

After these changes, the drawing looks like this:

Animating the Text

The last step we'll need to take is animating the text. We will do that by animating colors and floats. To set things up, let's define infiniteTransition, which we're going to use later:

val infiniteTransition = rememberInfiniteTransition(
    label = "infinite"
)

We also want to show the color animation first on the "not"-text and only after that on the "a phase"-text. One way to accomplish that is to define a helper float, based on which we use to animate the words. We'll get back to the implementation later.

We'll define a variable called animationPosition, an infinitely transitioning float from 0f to 4f, which restarts from 0 when it reaches 4. These values could be anything, but after testing, I found that these values worked best when combined with other things in this drawing.

The code for animationPosition could look like this:

val animationPosition by infiniteTransition.animateFloat(
    initialValue = 0f,
    targetValue = 4f,
    animationSpec =
        infiniteRepeatable(
            tween(
                durationMillis = 10000,
                easing = EaseIn,
            ),
            RepeatMode.Restart,
        ),
    label = "animationPosition",
)

In addition, we will define a helper function for animating the colors. Let's call it biColorsAnimated, define it to take in a Boolean parameter animated, and return a list of colors:

@Composable
fun biColorsAnimated(animated: Boolean): List<Color> {
    ....
}

Inside the function, we define our animated colors. We first create a list with the colors, and then map through it. For each color, we return animateColorAsState's value, which has the type Color, and finally, we return the list of colors:

val colors = listOf(
    biFlag.pink,
    biFlag.purple,
    biFlag.blue
)

return colors.map {
    animateColorAsState(
        targetValue = if (animated) it else white,
        animationSpec =
            tween(
                durationMillis = 1000,
                easing = EaseInBounce,
            ),
        label = it.toString()
    ).value
}

This way, we have the bi flag's colors as animated values and can use them with our text.

Finally, we get to tie everything together. For both of the texts, we change the brush gradient's color parameter to use this new function:

val notText =
    textMeasurer.measure(
        text = "Not",
        style =
            MaterialTheme.typography.titleSmall.copy(
                brush =
                    Brush.linearGradient(
                        colors = biColorsAnimated(
                            animated = animationPosition in 0.5f..1.5f
                        ),
                    ),
            ...
            ),
    )

val phaseText =
    textMeasurer.measure(
        text = "a phase",
        style =
            MaterialTheme.typography.titleLarge.copy(
                brush =
                    Brush.linearGradient(
                        colors = biColorsAnimated(
                            animated = animationPosition in 2f..3.5f
                        ),
                    ),
            ...
            ),
    )

We use the animationPosition value to define if the colors for that text are animated. For the first text, we change the colors from white to the bi flag colors if the animationPosition is between 0.5f and 1.5f, and for the second, if the value is between 2f and 3.5f.

These changes get us the animation you can see at the beginning of this blog post. You can find the complete code in this code snippet.

Wrapping Up

In this blog post, we've looked into adding text to Canvas, using custom Google Fonts, and animating colors. There was a lot to cover, but the end result is pretty nice!

I hope you've enjoyed this blog post and learned something. If you want to share your learnings, post on the social media of your choosing, or let me know in the comments if you're reading this on Dev or Medium.

Links in the Blog Post

Testing Different Navigation Options with Compose

2024-12-04T03:34:59.673Z

One part of creating accessible Android apps is to provide alternative navigation options. Some examples include touch (or pointer) input, keyboard navigation, switch navigation, and screen reader navigation. But how can you write tests for these different ways of navigation?

In this blog post, I'll share some examples of how to do that. I'm using an old demo project about making graphs more accessible and demonstrating how to write tests for the different elements I've explained with that demo project.

About the Code We're Using

As mentioned, I'm using an old demo project as the basis for the tests. In short, it contains a graph displaying data and is navigable with touch input, keyboard, switch device, and screen reader. The additional buttons for changing the highlighted sections in the chart also work for someone who has, for example, tremors in their hands or reduced dexterity.

If you want to learn more about how I built the UI and the reasons behind the decisions, I've added links to all the blog posts in the Related Blog Posts section.

Alright, let's get to writing tests!

Setting Up The Tests

Let's first set up the tests by creating a test class in the androidTest-package, defining composeTestRule, and adding a setup function that runs before each test:

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

    @Before
    fun setupTests() {
        composeTestRule.setContent {
            GraphExampleTheme {
                GraphScreen()
            }
        }
    }
}

Another part of the setup phase is deciding how we will retrieve the elements we use for testing. In this case, I decided to use test tags for simplicity, and I've defined a TestTags-object for sharing between the UI and tests. This solution is straightforward and might not be your choice in a production app, but as this is a demo, it uses the most explicit option.

You can find all the changes from this blog post in this commit.

The first tests we're going to write are about touch interaction. First, here's a short video of how things work in the UI when a user uses their finger to drag over the chart:

So, when a user moves their pointer input around in the graph, a box with values appears in the bottom right corner of the UI, displaying the values for the selected year.

Let's first get the elements we're going to use in the test:

@Test
fun touchInteractionsWorkCorrectly() {
    val labels = 
        composeTestRule.onNode(hasTestTag(TestTags.labelsTestTag))
    val chart = 
        composeTestRule.onNode(hasTestTag(TestTags.chartTestTag))
}

Why these two? First, the labels variable is the one we're using to check if things work correctly. It contains the information that changes, so by checking the year, we can ensure that navigation works correctly. Second, the chart is the one we're interacting with.

The actual tests look like this:

@Test
fun touchInteractionsWorkCorrectly() {
    ...

    labels.assertIsNotDisplayed()

    // Navigate forward
    chart.performTouchInput {
        swipeRight(startX = 0f, endX = 30f)
    }

    labels.assertIsDisplayed()
    labels.onChildren().assertAny(hasText("2015"))

    // Navigate forward
    chart.performTouchInput {
        swipeRight(startX = 30f, endX = 70f)
    }

    labels.onChildren().assertAny(hasText("2016"))
}

We first assert that the labels are not visible because that's how the UI is before navigation actions. After that, we perform touch input by swiping right, asserting that the correct year (in this case, "2015") is displayed in the labels component.

The numbers we use for swipeRight are based on the code, and the 35-pixel swipe is still inside the area used in the code for deciding what year is shown. In the same way, the second swipe from 30 to 70 moves from the first year to the second year.

Alright, we've written a test for touch/pointer input navigation. Next, we want to write tests for keyboard navigation.

The following video demonstrates what the keyboard navigation looks like on the graph when a user presses the "next" button (right arrow in this case) to navigate forward in the graph:

To test the keyboard navigation, we'll need a similar setup as for the touch/pointer interactions:


@Test
fun keyboardNavigationWorksCorrectly() {
    val labels = 
        composeTestRule.onNode(hasTestTag(TestTags.labelsTestTag))
    val chart = 
        composeTestRule.onNode(hasTestTag(TestTags.chartTestTag))

    labels.assertIsNotDisplayed()

}

For this test, we define the same variables (labels and chart) and then assert that the labels component is not displayed.

Next, we'll need to perform some keyboard input actions. We can do that with performKeyInput and pressKey:

chart.performKeyInput {
    pressKey(Key.DirectionRight)
}

Key.DirectionRight is the key for the right-pointing arrow. For the test, we want to first navigate forward some years, assert that the position is correct, and then navigate back and assert the year:

@Test
fun keyboardNavigationWorksCorrectly() {
   ...

    // Navigate forward
    chart.performKeyInput {
        pressKey(Key.DirectionRight)
        pressKey(Key.DirectionRight)
        pressKey(Key.DirectionRight)
        pressKey(Key.DirectionRight)
        pressKey(Key.DirectionRight)
        pressKey(Key.DirectionRight)
    }

    labels.onChildren().assertAny(hasText("2020"))

    // Navigate back
    chart.performKeyInput {
        pressKey(Key.DirectionLeft)
        pressKey(Key.DirectionLeft)
        pressKey(Key.DirectionLeft)
    }

    labels.onChildren().assertAny(hasText("2017"))
}

These lines assert that the keyboard navigation works correctly. The last thing to test in the context of this blog post is the on-screen button navigation.

The previous videos didn't display the on-screen buttons because they were recorded before adding them. Here's a video with the buttons and how the navigation works:

So, to test, again, we'll have similar - but not exactly the same! - setup:

@Test
fun buttonNavigationWorksCorrectly() {
    val labels = 
        composeTestRule.onNode(hasTestTag(TestTags.labelsTestTag))
    val leftButton =
        composeTestRule.onNode(hasTestTag(TestTags.leftButtonTestTag))
    val rightButton = 
        composeTestRule.onNode(hasTestTag(TestTags.rightButtonTestTag))

    labels.assertIsNotDisplayed()
}

This time, besides getting the labels, we don't need the chart component at all. Instead, we'll get a reference to both buttons on the screen.

Next, we want to navigate forward by clicking the button and asserting that the year on the label is correct. After that, we do some forward and backward navigation to ensure both buttons work correctly:

@Test
fun buttonNavigationWorksCorrectly() {
    ...

    // Navigate forward
    rightButton.performClick()

    labels.assertIsDisplayed()

    labels.onChildren().assertAny(hasText("2015"))

    // Navigate forward
    rightButton.performClick()
    rightButton.performClick()
    rightButton.performClick()
    rightButton.performClick()

    // Navigate back
    leftButton.performClick()
    leftButton.performClick()

    labels.onChildren().assertAny(hasText("2017"))
}

And this is how we can test the on-screen button navigation in the graph.

Wrapping Up

In this blog post, we've written tests for three different navigation styles: Touch/pointer input, keyboard navigation, and on-screen button navigation. This way, we've tested that users using different navigation methods and tools can use the app.

Do you test for these interactions and navigation alternatives? If so, do you have any tips on testing them?

Links

Links in the Blog Post

Support Time to Take Action with Compose

2024-12-28T09:31:16.891Z

While working on my master's thesis and the Android Accessibility Checklist, one of the answers to my survey mentioned an accessibility setting called time to take action. Since then, I've been curious about it and wanted to write a blog post as I feel it's one of the undersupported accessibility settings and really useful for those who utilize it.

So, what is time to take action, and why would someone use it? And why should we, as developers, care? Let's talk about that first.

Time to Take Action

Time to take action is a setting that controls the minimum time in which temporary messages asking a user to take action are shown. So, for example, when you press the volume buttons on your Android phone, you should see the volume controls next to the volume buttons, and this setting controls how long they're visible.

This setting has different options: Default, 10 seconds, 30 seconds, 1 minute and 2 minutes. You can find them from Settings -> Accessibility Settings -> Timing controls -> Time to take action (Accessibility timeout). The screen looks something like this, depending on your phone's version and manufacturer:

And why would someone need this setting? Well, the source code and documentation for a method we're going to use in a moment puts it pretty well:

Some users may need extra time to review the controls, or to reach them, or to activate assistive technology to activate the controls automatically.

Okay, now we've established what the time to take action is. However, the question of relevance remains: Why should we care as developers? Isn't it something that the operating system handles automatically?

The answer is yes and no. Most components on the operating system level and Material3 components respect this setting. However, when you're building a custom component, it's not automatically respected, and you'll need to add support for it. That's why the settings page mentions that not all apps support the setting. The thing is, developers usually don't know about it.

Let's next talk about how to support time to take action-setting with a custom component.

How to Respect Time to Take Action?

For the sake of example, we'll build a small tooltip component with a button to close it. The tooltip disappears after the minimum time to take action if the user does nothing. The default value, in our case, is set to 10 seconds.

Before diving into code, here's a video where the tooltip is first shown with the time to take action setting with a default value, and then it's set to 30 seconds:

This example doesn't contain all the code (like the tooltip content), just the relevant parts. As seen in the video, the tooltip becomes visible after the user clicks an "Info"-button, then is visible for the required time, depending on the time to take action-setting, and finally, disappears. The tooltip contains a button to hide the tooltip faster.

We're adding the support for time to take action in two steps:

Calculate the delay for hiding the tooltip
Hide the tooltip after the calculated time has passed

The first step is to calculate the delay, or tooltipTimeout, as we're calling it in the code:

@Composable
fun Tooltip(
    tooltipVisible: Boolean,
    hideTooltip: () -> Unit,
    modifier: Modifier = Modifier
) {
    val tooltipTimeout = LocalAccessibilityManager.current?
        .calculateRecommendedTimeoutMillis(
             originalTimeoutMillis = TOOLTIP_DEFAULT_TIMEOUT_MS,
             containsText = true,
             containsControls = true,
         ) ?: TOOLTIP_DEFAULT_TIMEOUT_MS

    ...

    TooltipContent(...)
}

// 10 seconds
const val TOOLTIP_DEFAULT_TIMEOUT_MS = 10000

LocalAccessibilityManager composition local provides a neat function for calculating the timeout, so we use that. The first parameter for calculateRecommendedTimeoutMillis is the original timeout milliseconds, which applies when there are no accessibility timeout needs. The other parameters are a bunch of boolean values informing about the element's contents for which the timeout value is being calculated. These are about whether the element contains text, controls, or icons.

The calculateRecommendedTimeoutMillis returns the recommended timeout time as Long. As the AccessibilityManager might not be available in some operating systems or OS versions and thus is nullable, we also need a default value. This value is the TOOLTIP_DEFAULT_TIMEOUT_MS in our code - the same one we use for the original timeout. In the example, the value is 10 seconds.

Next, we'll use the freshly calculated timeout:

@Composable
fun Tooltip(...) {

   ... 

    LaunchedEffect(tooltipVisible) {
        if (tooltipVisible) {
            delay(tooltipTimeout)
            hideTooltip()
        }
    }

    TooltipContent(...)
}

So, what happens in the code snippet is that whenever the tooltipVisible-value changes, we check if the change was for making the tooltip visible, and if so, then we first delay for the number of milliseconds we calculated in the previous step and then hide the tooltip.

This way, we can respect the user's settings for elements that they might need more time to interact with.

Wrapping Up

In this blog post, we've discussed the time to take action setting, what it is, why developers should know about it, and how to respect it. We've done this by building a tooltip component, which hides after a certain amount of time.

Did you know about this setting? Have you ever implemented support for it? If so, what kind of UI components were they?

Links in the Blog Post

Android Accessibility Checklist

Year in Review - 2024 Edition

2024-12-31T09:23:47.195Z

It's time for some yearly reflections again. What a year 2024 has been! Both in good and in bad. This yearly review is my fourth, and you can find the previous ones from these links:

Okay, let's dive in.

Accomplishments

A lot has happened, and looking back, I've accomplished a bunch. Here are some of the highlights from the past year.

I become a GDE (Google Developer Expert). That was a tremendous thing for me, getting recognition for my community contributions over the years. Also, after a huge case of imposter syndrome I had in the spring, getting the email welcoming me to the GDE program felt just incredible.

Other accomplishments from 2024 relate to my studies - first, in the spring, I completed my master's thesis about Android developers and accessibility. It was a fun project, and I've written about the checklist I developed during the process in this blog post: Android Accessibility Checklist.

I also graduated in December, and can now proudly say that I'm, in addition to my previous master's degree in Russian language and culture, Master of Science in Economics and Business Administration, with a major in Information Systems (and the master's program was technical communication).

The final accomplishment I want to highlight is that I released Neule.art Android app in December. It's a Compose multiplatform app, and I'm learning as I go - but it's been super fun! And sometimes frustrating because I'm a total iOS noobie, and when I need to add something in native code, I sometimes don't even know the right words to search for answers. Nevertheless, I've learned a ton in the process. I've written about the initial thoughts in this blog post: First Impressions of Compose Multiplatform

Speaking

In 2024, I did some public speaking. I also had to cancel some things due to booking flights on the wrong days and realizing it only right when I was supposed to leave, and getting sick, which was a pity. But anyway, here are all the conferences and meetups I spoke at in 2024:

Conferences and Webinars
- Android Worldwide (online)
- Accessibility in mobile apps - IAAP Nordic (online)
- Droidcon Berlin
- Quality Forge (online)
- Droidcon London
- We Are Developers Live - Accessibility Day (online)
Meetups
- Turku <3 Frontend
- Turku Mobile

I was about to write that I didn't do that much public speaking this year, but looking at the list and comparing it to last year, I actually spoke in more events than in 2023. Oh wow. That's nice.

Writing

In 2024, I improved my writing game. I wrote more, and I feel like the quality of my posts has increased. In total, I've published 27 blog posts (this being the 28th), and six of them got boosted by the Medium team. The topics of the blog posts were related to Android, Android accessibility, career and inclusion, and burnout.

Also, most of my blog posts were featured in multiple newsletters, which always feels great. So, a big thanks to everyone behind those newsletters! Some of these newsletters include Android Weekly, Jetpack Compose Newsletter, Software Testing Notes, and Software Testing Weekly.

I'll also list some of my personal favorites from 2024:

Another Year Of Being in Gender Minority in Tech

Published at March 1st

Read the post Another Year Of Being in Gender Minority in Tech

This blog post is part of Dev.to's #WeCoded campaign, which started as She coded, sharing stories from women in tech around International Women's Day, and has evolved to a month-long celebration of gender minorities in tech. It was hard to write, and at the same time, I knew it had to be written. Normally, I would share the link to the original post in Dev, but to be honest, the comments I've received there (and on Medium) are why I wanted to share this piece from my website, without comments.

So yeah, in the post, I share my experiences of being in gender minority in tech from the previous year (at the time of writing), and some of them are super misogynist. With this post I also got my first experience of being harassed on other platforms by someone who was blocked on Dev. But more about that in next March's #WeCoded-post.

Stacked Cards Layout With Compose - And Cats

Published at July 11th

Read the post Stacked Cards Layout With Compose - And Cats

I loved writing this blog post - it has two elements I really like: cats and custom layouts. In the blog post, I explain how to create a custom stacked card layout to display cat pictures in those cards. As often happens, this blog post was a byproduct of another blog post (which I haven't yet published), and I had so much fun writing it.

Not a Phase - Text with Compose and Canvas

Published at November 10th

Read the post Not a Phase - Text with Compose and Canvas

In the second half of 2024, I've been writing about Compose and Canvas, and this blog post is one in a series of those blog posts. This one discusses adding text and different text styles and fonts to Canvas. In addition, it highlights a theme dear to me: Bisexual visibility and existence.

Other Things

This year was a hard one. I mean, look at the world burning - that alone makes everything hard. But I also have been burned out pretty much the whole year - that seems to be my state of existence now. It got better in the summer and beginning of fall, until everything started falling apart in ways I never would have imagined them to do.

But at the same time, 2024 was a year of me finding myself. It was the year when I've finally been able to do some things and live as myself. You see, I spent my youth and early adulthood in charismatic Christian circles, and only now, almost 10 years after leaving (or being forced out, because divorce is one of the biggest sins you can commit), I can finally come out as a nonbinary woman. Bisexuality was somehow an easier thing; I don't know why.

Also, I've finally done something I had planned for more than 10 years: I've got tattoos! They're adorable and so freaking cool. And they won't be the last ones. I'm so glad I work in tech and can afford such things.

So, 2024 was not all bad. How about 2025?

What About 2025?

Yeah, I'm not going to promise anything. But I have one wish - I wish that a year from now, I wouldn't have to think or write about burnout so much. So, if you have a job opportunity where burnout is not that likely, I'm all ears. But I do want to do Android development and/or accessibility-related things.

I wish you a better year in 2025!

Links in Blog Post

2025, Please, Be Gentle

2025-01-06T11:00:18.723Z

This was originally written for Dev.to's New Year writing challenge.

2025 has started, and while I'm actually skeptical of anything good happening (just look at the world burning), I decided to give some thought to what I hope to accomplish this year. You know, the good things, as an ask for the universe.

I could describe this all as a roadmap for 2025. But I've learned over the years that my plans usually don't come true, and something unexpected happens. So, instead of compiling a complete roadmap, I call these things wishes.

I assembled them in the form of a bingo card. You know, the game where you mark something when it happens (or, in the original thing, when the bingo host announces the number in the card). And when the things you've marked create either in horizontal, vertical, or diagonal lines, you yell "Bingo!" and win something.

I really wish I'd get a "Bingo" this year. I would really need it after the past *mumbles a number* years. Like, really, really need it. Of course, I'm putting in the work towards all of that stuff - but with many things, it's not only about me.

However, I wouldn't be me if I wasn't realistic. So, I also compiled another list of events I predict to happen this year. Heck, I expect that most of them will happen before March, and I will get back to them in my #WeCoded post. Unfortunately, coming from a minority position, I need to be prepared for a lot of negative stuff.

Let's start with the good stuff.

2025, Please, Bring Some Goodness

So, here are my wishes for 2025:

The same bingo as a text version for better readability:

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	Learn a new skill	More non-binary representation in conferences
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!)	Blog post gets boosted or selected to Dev's top 7	#WeCoded without jerks commenting
Conference swag socks in my size	Someone says my work inspired them	A new tattoo	A genuine apology from someone after being a jerk	Get a book deal
Get promoted to Tech Lead position	100K views in Dev	Not burning out during the year	Build a new, useful feature for Neule.art-app	Finish building a keyboard

I think they're pretty self-explanatory. In general, some are about work stuff, some are about non-work-but-tech stuff, and the rest are just me hoping for some cool things, like a night in nature or a new tattoo.

But they'd make 2025 a pretty decent year. Especially if I don't burn out. Which is an excellent segue to things I wish wouldn't happen, but I predict to happen in 2025.

But I Must Be Realistic

Here's a more realistic bingo card (without the good things):

And the text version of the card:

B	I	N	G	O
Being addressed as a guy	Someone gaslights me	Biased AI-generated content	Man speaks over me	Called "intimidating" for being assertive.
Someone interrupts when I'm presenting	"Gender doesn't matter, just talent"	Man takes credit for what I said	Being left out of an important meeting	"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	"I've never seen anyone being discriminated"	"Intent over impact"	Man needs to repeat what I've said
Invalidation of lived experience	"Women just don't want to code"	Someone else credited for my work	"But they clearly didn't mean it"	Sexist comment in a blog post or talk
"You were hired just for diversity quotas"	Everyone's surprised after something I warned happens	Man splaining my expertise to me	"Equality has gone too far"	Hypothetical developer is referred to as "he" or other gendered noun

I'm exhausted after compiling this list. I wish I could say I had to look for examples elsewhere, but unfortunately, I've seen, heard, or experienced all of these during my career in tech.

I hope I won't get a bingo with this card. Unfortunately, that's more likely than with the first one - or, at least, faster than with the first one.

But I want to end on a positive note. I'm concentrating on the good, my well-being, and making the wishes I described above true. I'm manifesting a good year - a year with less discrimination, bias, and other similar things happening.

Using SVGs on Canvas with Compose Multiplatform

2025-01-15T06:00:02.402Z

One thing that has continued to amaze me with building my Compose Multiplatform app is how easily everything has worked with Canvas. When I started building Neule.art, I assumed that Canvas would cause some problems, but it has worked smoothly on both Android and iOS.

I've been writing posts about creative coding on Canvas (see, for example, Not a Phase - Text with Compose and Canvas), and also about my First Impressions of Compose Multiplatform, and this post combines elements from both themes.

There are different ways to parse an SVG to be used with Compose, and in this blog post, I'm looking into using path data. This approach requires some manual work, but it also allows better flexibility for controlling, e.g., colors of the individual elements within the SVG.

What We're Building

Even though I'd love to show how I've built the shirt I'm using in Neule.art, simplifying the process into the form of a blog post is too difficult a task. I decided to create a smaller SVG, which we're going to convert into Canvas. It looks like this:

The hearts I'm using in the SVG are from Sarah Laroche's Vector Heart Figma resource. And if you've ever seen the colors anywhere, you might recognize them as being from the non-binary flag.

Getting the Paths from an SVG

We first need something from the original SVG to draw it on Canvas: the paths of individual components within the SVG.

In an SVG, the path's d-attribute contains the commands for defining the shape being drawn, and we're using that to parse the SVG to the path on Canvas. If you're unfamiliar with SVGs, I recommend checking MDN's documentation on SVGs, as it contains much in-depth information about SVGs.

So, to prepare for drawing paths on Canvas, we'll need an SVG image as code. Then, we need to copy the path's d-attribute's content and finally store them somewhere inside our code. There are several options for opening the SVG's code - for example, open the file in an IDE or inspect it in the browser's developer tools.

In our example, we store the path strings in a list with a variable called pathStrings. We also want to attach the color information to each path to make the drawing phase easier, so we store the path string together with the color it will be drawn with.

The following example lists only two of the hearts' paths, as the complete list would take up too much space. You can find the complete list of paths in the snippet linked at the end of the blog post.

val pathStrings = listOf(
    Pair("M185.52 80.2313C172.773 67.8803 159.24 53.9097 154.36 36.3463C153.373 32.8076 152.633 29.1043 153.193 25.4737C154.813 14.8697 163.753 16.4547 168.74 23.722C175.593 33.7001 180.946 44.7021 184.58 56.2492C186.3 43.9382 188.04 31.5685 191.666 19.6794C192.786 16.0068 195.16 11.6456 198.98 12.0229C201.993 12.3195 203.8 15.5202 204.526 18.453C205.733 23.2988 205.426 28.3831 204.926 33.3509C202.806 52.8032 201.753 71.7397 198.673 91.1093C193.953 87.8965 189.62 84.204 185.52 80.2313", Colors.white),
    Pair("M32.5198 119.231C19.7732 106.88 6.2398 92.9097 1.3598 75.3463C0.373129 71.8076 -0.366871 68.1043 0.193129 64.4737C1.81313 53.8697 10.7531 55.4547 15.7398 62.722C22.5931 72.7001 27.9465 83.7021 31.5798 95.2492C33.2998 82.9382 35.0398 70.5685 38.6664 58.6794C39.7864 55.0068 42.1598 50.6456 45.9798 51.0229C48.9931 51.3195 50.7998 54.5202 51.5265 57.453C52.7331 62.2988 52.4265 67.3831 51.9265 72.3509C49.8065 91.8032 48.7532 110.74 45.6732 130.109C40.9532 126.897 36.6198 123.204 32.5198 119.231", Colors.black),
)

Now that we have the path string and the color, we can move on to parsing the path strings into Compose's Path objects.

Parsing Paths

Compose has this great thing called PathParser, which is something we can use for, well, parsing paths. Inside a Canvas component's block, we map through the path strings, parse them, and then draw the path on canvas:

Canvas(...) {
    paths.map { (pathString, color) ->
        val parsedPath = PathParser()
          .parsePathString(pathString)
          .toPath()

        drawPath(
            path = parsedPath,
            color = color,
        )
    }
}

PathParser's method parsePathString takes care of the parsing and returns a PathParser-object. Then, we call the toPath conversion method to get the Path out of PathParser.

With these changes, we get the following image:

As you might notice, the image doesn't scale to the entire space available. The reason is that SVG code is hard-coded to fit a specific size. If you look at the path strings above, you can see that they contain numbers as coordinates - they're inside the (in our case) 278 x 270 area defined in the original SVG as size.

To fix this problem, we can add some scaling functions into the mix. Let's talk about that next.

Scaling

We'll need to convert the parsed path to PathNodes to scale the paths. This way, we can scale every moveTo, curveTo, and other SVG drawing functions to the correct size.

We'll need a couple of helper functions to scale the paths on Canvas. One is a function for transforming float values from one size to another, and the other is a function that handles PathNode's scaling.

This is how we define the float scaling:

private fun Float.scaleToSize(
    oldSize: Float,
    newSize: Float,
): Float {
    val ratio = newSize / oldSize
    return this * ratio
}

The function takes in the old size (so, for example, the full old width), and new size (the new full width). With those values, we calculate a ratio to convert the float value by multiplying the value with the calculated ratio.

The PathNode's scaling requires a bit more code:

private fun PathNode.scaleTo(size: Size): PathNode {
    val originalWidth = 278f
    val originalHeight = 207f

    return when (this) {
        is PathNode.CurveTo ->
            this.copy(
                x1 = x1.scaleToSize(originalWidth, size.width),
                x2 = x2.scaleToSize(originalWidth, size.width),
                x3 = x3.scaleToSize(originalWidth, size.width),
                y1 = y1.scaleToSize(originalHeight, size.height),
                y2 = y2.scaleToSize(originalHeight, size.height),
                y3 = y3.scaleToSize(originalHeight, size.height),
            )
        is PathNode.MoveTo ->
            this.copy(
                x = x.scaleToSize(originalWidth, size.width),
                y = y.scaleToSize(originalHeight, size.height),
            )
        else -> this
    }
}

We're scaling the values from the original size to the Canvas size for each type of PathNode. In the when-clause, we're handling only CurveTo and MoveTo, because those are the only commands our path strings contain. If there were others, they should be handled here too.

Scaling of each parameter utilizes the scaleToSize we defined previously. The parameters we're passing to the function depend on if the parameter is on the x or y-axis - if it's on the x, we pass in width (as that's the x-axis), and if it is on the y-axis, then we pass in height.

Now that we have the helper functions let's change the mapping of path strings a bit:

paths.map { (pathString, color) ->
    val parsedPath =
        PathParser()
          .parsePathString(pathString)
          .toNodes()
          .map { it.scaleTo(size) }
          .toPath()

    drawPath(
        path = parsedPath,
        color = color,
    )
}

Here, we first parse the path, then convert the PathParser it returns with toNodes to a list of PathNodes. We then map through each PathNode, and scale it to size. Finally, we turn the scaled PathNode list into Path, which we can then draw.

After these changes, the picture scales nicely:

Wrapping up

In this blog post, we've looked into how to turn SVG into Paths that can be used in Compose's canvas. This approach works for both native Android development, and Compose Multiplatform projects.

You can find the complete code from this Github gist.

Links in the Blog Post

January 2025, You Were Rough

2025-02-02T13:56:28.084Z

The first month of 2025 and its 247 days are behind us. I started 2025 with a blog post participating in Dev's New Year Challenge, sharing some hopes and fears for 2025.

In the post, I shared two bingo cards: One for things I wish would happen, and one for things I think will, unfortunately, happen. The original blog post is behind this link: 2025, Please, Be Gentle.

I decided that after each month, I'd look at how it went in terms of these two cards. This is the first checkpoint, so let's discuss the good stuff first.

The Good Stuff

From January, I can mark one thing as complete on my wishes-bingo card: My blog post, Using SVGs on Canvas with Compose Multiplatform, was selected to Dev's week's top 7 listing. I was so happy when I saw the notification about it!

So, after a month, my "The Good Stuff"-bingo card looks like this:

And the text version:

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	Learn a new skill	More non-binary representation in conferences
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	#WeCoded without jerks commenting
Conference swag socks in my size	Someone says my work inspired them	A new tattoo	A genuine apology from someone after being a jerk	Get a book deal
Get promoted to Tech Lead position	100K views in Dev	Not burning out during the year	Build a new, useful feature for Neule.art-app	Finish building a keyboard

The More Realistic

The title of this blog post is both about the state of the world right now - as a non-binary, disabled woman who is willing to call a nazi salute a nazi salute, everything that's happening is just a lot. But it's also about the bingo - I could mark several of my "More realistic" bingo card items as "This happened".

During January, I saw so much biased AI-generated content enforcing gender stereotypes. I also was addressed as a "guy" many times. And in countless discussions, when talking about a developer, that hypothetical developer was addressed as "he".

I was also told how I would be heard better if I wasn't so negative and angry all the time - "just look at how this one man does it". Side note: I was never angry, and my "negativity" in the situation was me being realistic, not negative.

And finally, there was this one situation where I had told about something needing to be done and was met with "no", but when a fellow developer, who is a man, brought it up a couple of weeks later, there was no discussion if it has to be done, but how we're going to do it. And I bet no one else noticed this happening.

So yeah, after January, my more realistic Bingo card looks like this:

And the text version, with "Happened" before the text.

B	I	N	G	O
Happened: Being addressed as a guy	Someone gaslights me	Happened: Biased AI-generated content	Man speaks over me	Called "intimidating" for being assertive.
Someone interrupts when I'm presenting	"Gender doesn't matter, just talent"	Man takes credit for what I said	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	"I've never seen anyone being discriminated"	"Intent over impact"	Happened: Man needs to repeat what I've said
Invalidation of lived experience	"Women just don't want to code"	Someone else credited for my work	"But they clearly didn't mean it"	Sexist comment in a blog post or talk
"You were hired just for diversity quotas"	Everyone's surprised after something I warned happens	Man splaining my expertise to me	"Equality has gone too far"	Happened: Hypothetical developer is referred to as "he" or other gendered noun

Wrapping Up

While my more realistic bingo card got more marks than the good stuff one this month, and the state of the world is what it is, January was not all bad. There were a lot of great conversations, accomplishments, and other small, positive things.

Let's hope that February brings more good, both to the world and to my life!

Be Mine and Add Interaction with Compose and Canvas

2025-02-13T05:33:02.206Z

Valentine's Day is approaching, and while I prefer the Finnish version ("Friend's Day"), I was inspired to do some creative coding in the holiday theme.

The Hollywood-centric film industry (in addition to globalization in general) has carried those heart-shaped candies to the North as well. While browsing some images for inspiration, I decided to use them for the next piece I'm writing.

And that's not all! I also wanted to continue my series of Canvas-related blog posts, so this one walks through another concept with Canvas: How to detect pointer input gestures and add some interaction.

So, what are we building today? Here's a video showing some heart-shaped candies with messages and how they scale bigger when I'm touching them:

Let's get coding!

Drawing the Hearts

This project builds on my previous blog post, Using SVGs on Canvas with Compose Multiplatform, which explained how to draw from SVG's path strings to Compose Canvas. I prepared an SVG image on Figma and then extracted the path strings to draw the hearts.

We will utilize some functions from the previous blog post: Float.scaleToSize and PathNode.scaleTo. I won't explain them in this blog post; just mention them. If you want a refresher on how they work, head to the blog post describing them.

Alright, let's start by drawing one heart on Canvas.

Drawing One Heart

We want to extract the logic for drawing the heart to a function. Let's call it drawCandyHeart, and pass the top-left offset, the size of the heart, and the color we're drawing the heart with to the function:

private fun DrawScope.drawCandyHeart(
    topLeft: Offset,
    heartSize: Size,
    color: Color,
) {

}

I've defined the path strings in a separate list, but I will leave them out from this blog post for brevity. They're included in the final code, which you can find at the end of the blog post.

We can get the path strings with a function pathString(color: Color): Pair<String, Color>, which returns the two path strings with the color with different opacity values to get the look we aim for.

So, using the function to get the path strings with color, let's first parse the strings into Paths:

HeartCandy.Heart
    .pathStrings(color)
    .map { (pathString, color) ->
        val path =
            PathParser()
                .parsePathString(pathString)
                .toNodes()
                .map { path -> path.scaleTo(heartSize.height) }
                .toPath()
                .apply {
                    translate(topLeft)
                }
...
}

Here, we go through each path string and color pair, and using PathParser, we parse the path strings into Paths. Then, we convert the Path into Nodes, so we can scale them to the correct size. Once that's done, we convert them back to Paths, and then move them to correct position.

After that, we can use the parsed path to draw the candy:

drawPath(
    path = path,
    color = color,
)
drawPath(
    path = path,
    color = color,
    style = Stroke(width = 2f),
)

We draw the path twice to get the fill and then to draw the stroke around the shapes. After these steps, our heart looks like this:

The next step is to add some text to the candy.

Adding the Text

To draw the text on Canvas, we need the text as TextLayoutResult, so let's add a new parameter to drawHeartCandy called text, which is of type TextLayoutResult:

private fun DrawScope.drawCandyHeart(
    ...
    text: TextLayoutResult,
) { ... }

This way, we can handle all text-related changes in the parent component without passing a TextMeasurer to the drawing component, as the drawText method needs the text as TextLayoutResult.

We pass in the text we want to display, which we also measure with textMeasurer:

val textMeasurer = rememberTextMeasurer()
...
drawCandyHeart(
   ...
    text = textMeasurer.measure(
        text = "Enby\nLove".uppercase(),
        style = TextStyle.Default.copy(
            fontFamily = RighteousFontFamily,
            textAlign = TextAlign.Center,
            fontSize = 10.sp,
        ),
    )
)

We also style the text here by turning it all uppercase and defining its style. If you're wondering about the font family (Righteous), that's imported to the code as described in Not a Phase - Text with Compose and Canvas.

The next step is to draw the text. Our code looks like this:

rotate(
    degrees = -7f,
    pivot = Offset(
        x = topLeft.x + heartSize.width * 0.5f,
        y = topLeft.y + heartSize.height * 0.5f,
    ),
) {
    drawText(
        textLayoutResult = text,
        topLeft = calculateTextTopLeft(
            topLeft = topLeft,
            text = text,
            heartWidth = heartSize.width,
            padding = 5.dp.toPx()
        ),
        color = color,
    )
}

What's worth noting here is that we need to rotate the text slightly to align with the heart correctly. Also, we calculate the top left coordinates for the text with the following function:

private fun calculateTextTopLeft(
    topLeft: Offset,
    text: TextLayoutResult,
    heartWidth: Float,
    padding: Float
) = Offset(
    y = topLeft.y + (text.size.height * (1f / text.lineCount) + padding),
    x = topLeft.x + heartWidth * 0.5f - text.size.width * 0.3f,
)

After these changes, the heart looks like this:

Drawing Them All

Okay, we have one heart. But the final goal is to have 16 of them. I've defined the color and text pairs outside the component as the type of List<Pair<Color, String>>.

To create the 4 x 4 layout for the hearts, we're going to first chunk the list of items into four sublists and then map through each item in the row:

HeartCandy.hearts
    .chunked(4)
    .mapIndexed { row, colors ->
        colors.mapIndexed { index, (color, text) ->
            ...
        }
    }

Then, extending and generalizing the code we wrote for the one heart, inside the colors.mapIndexed we call:

drawCandyHeart(
    topLeft = Offset(
        x = index * (heartSize.width + horizontalPadding),
        y = row * (heartSize.height + verticalPadding),
    ),
    heartSize = HeartCandy.Heart.size,
    color = color,
    text = textMeasurer.measure(
        text = text.uppercase(),
        style = HeartCandy.Heart.textStyle,
    )
)

We use the index on the column and row to add enough offset to each heart to position them correctly. We also add horizontal and vertical padding, which is calculated based on the remaining space on the screen.

We pass in the color and use the text from the item instead of the hard-coded text we had for the one heart. Finally, the text style has been extracted to an object to save space, compared to the code for drawing one heart.

After these changes, our piece of art looks like this:

Adding Interaction

Finally, we're at the point where we're adding some interaction! First, we need to store one variable and add a modifier in the parent component to enable dragging gestures:

@Composable
fun HeartCandy() {
    var dragPosition by remember { mutableStateOf(Offset.Zero) }
    ... 

    Canvas(
        modifier =  Modifier
            ...
            .pointerInput(Unit) {
                detectDragGestures(
                    onDragEnd = {
                        dragPosition = Offset.Zero
                    },
                ) { change, _ ->
                    dragPosition = dragPosition.copy(
                        x = change.position.x,
                        y = change.position.y
                    )
                }
            },
        ) { ... }
   }

We define a variable to store the dragging position, add the pointerInput-modifier, and then call the detectDragGestures inside the modifier. Then, when a drag gesture is detected, we set the changed position to the dragPosition-variable. When the drag gesture ends, we set the position to default value, so, in this case, Offset.Zero.

We now know where the user's pointer input is moving. Next, we'll want to use that information and transform a heart when the pointer input touches it. First, let's pass the drag position to the drawCandyHeart-method:

private fun DrawScope.drawCandyHeart(
    dragPosition: Offset,
) { ... }

Next, we want to know if the drag spot is within the drawn paths for the hearts. Path provides an excellent method: getBounds, which returns the path's bounds as a Rect. Then, we can check if this Rect contains the current drag position.

There is just one thing: We have two different paths for the heart, so we want to check if the drag spot is within either of them to do transformations. We'll need to refactor our way of drawing a bit by dividing the path parsing from the path drawing:

val paths = HeartCandy.Heart
    .pathStrings(color)
    .map { (pathString, pathColor) ->
         val path = // Parse the path
         Pair(path, pathColor)
    }

val pathBounds = paths.map { it.first.getBounds() }
val isSelected = pathBounds.any { it.contains(dragPosition) }

paths
    .map { (path, color) ->
        // Draw the paths
    }

We first draw the paths as we did before, and from the map, we return the data as Pair<Path, String>. Then, we map through the paths to get the bounds for each path and store the result in pathBounds. After that, we map through it, checking if any of them contain the current drag position.

Now that we know if a heart is currently selected, we can do some transformations. Let's do two things: Scale the heart slightly bigger and change the text color.

First, let's define the variables:

val scaleAmount = if (isSelected) 1.05f else 1f
val textColor = if (isSelected) HeartCandy.highlightColor else color

Then, we want to wrap everything we're drawing with the scale transform function and pass in the scale amount:

scale(scaleAmount) {
    paths.map {...}
}

And finally, change the text color to the newly defined variable:

drawText(
    ...
    color = textColor,
)

And that's it. With these code changes, we've added some interaction to our canvas.

Wrapping Up

In this blog post, we've looked into how to add interaction on Compose Canvas. We drew some Valentine's day themed hearts with a queer twist and added an ability to select each of them with pointer input. The complete code is available in this code snippet.

While this project was fun to create, my inner accessibility specialist is reminding me about a few things: First of all, the text in the candies doesn't have enough contrast between the text and the background to be legible. The other thing is that right now, all the interactions are available only for pointer input, leaving out anyone using assistive technologies that don't support the pointer input.

I might write a blog post about improving these aspects later.

Have you built something exciting and interactive with Compose and Canvas? Or do you have future plans?

Links in the Blog Post

Making basicMarquee-Modifier More Accessible

2025-02-20T07:17:01.787Z

I have this "Remove animations"-setting turned on on my phone because different kinds of movement make me feel physically sick. When the setting is on, animations are usually removed from native Android apps.

And when there are some animations, I notice them. I've started seeing more and more of some horizontally scrolling texts, and I have been wondering why.

Then I came across this basicMarquee-modifier. And it doesn't respect the "Remove animations" accessibility setting. And that's bad - many users (me included) rely on that setting to not see animations. Marquee-styled animations are one of the worst triggers of my motion sickness symptoms.

If you want to learn more about my symptoms and why animations can be super problematic for some, I've written two blog posts, one from Android and one from a web point of view:

But since bringing up solutions is often better received than bringing up problems, this blog post will demonstrate one idea on how to improve the situation for us who rely on that "Remove animations" setting.

The main idea is to read the value of this setting and then use it to decide if the basicMarquee-modifier is used. In this blog post, I'm using composition locals to accomplish it.

Remove Animations Setting

Before we dive into the code, a couple of words about the "Remove animations" setting. It's a global setting, which you can find from the accessibility settings. In my Pixel phone, "Remove animations" is under the "Color and motion"-section.

From a technical perspective, the setting changes the animator duration scale to 0, so, in other words, the animations end right after they start. This accessibility setting is not exposed via accessibility services the same way as, for example, screen reader availability, so we'll need to be a bit creative. The following section explains how we can read the value of this setting.

Composition Local for Remove Animations

We'll want to store the value of the "Remove animations" setting and make it available for the components in the component hierarchy. Custom CompositionLocal is one tool for that. As Android documentation describes CompositionLocals:

CompositionLocal is a tool for passing data down through the Composition implicitly.

Let's start by creating the custom composition local and the data type it provides:

// LocalRemoveAnimations.kt

data class RemoveAnimations(
    val context: Context
) {
    val enabled: Boolean
}

val LocalRemoveAnimations =
    staticCompositionLocalOf<RemoveAnimations> {
        error("No user found!")
    }

Here, we're defining the LocalRemoveAnimations as staticCompositionLocalOf as the value is not likely to change - in fact, the app needs to be restarted to test it. Or at least I haven't found a way to observe the value; just read it synchronously.

We can read the value of the animation duration scale with the following code:

val animationDuration = try {
    Settings.Global.getFloat(
        context.contentResolver,
        Settings.Global.ANIMATOR_DURATION_SCALE,
        1f
    )
} catch (e: Settings.SettingNotFoundException) {
    1f
}

So, we try to read the value of Settings.Global.ANIMATOR_DURATION_SCALE with a default value of 1f. If the setting is not found, Settings.SettingNotFoundException is thrown; we want to catch it and set the default value. One example of when the setting is unavailable is when the phone's Android version is older than 12.

And putting them together, we get:

// LocalRemoveAnimations.kt

data class RemoveAnimations(
    val context: Context,
) {
    val enabled: Boolean
        get() =
            try {
                Settings.Global.getFloat(
                    context.contentResolver,
                    Settings.Global.ANIMATOR_DURATION_SCALE,
                    1f,
                )
            } catch (e: Settings.SettingNotFoundException) {
                1f
            } == 0f
}

Note that for the enabled-value, we add a check if the value from the try/catch-block is 0f to know if the "Remove animations" setting is enabled.

The next step is to provide it in code:

// MainActivity.kt

setContent {
    val context = LocalContext.current

    CompositionLocalProvider(
        LocalRemoveAnimations provides
            RemoveAnimations(
                context = context,
            ),
    ) { 
            // App content goes here
    }
}

Finally, we can read the value of the LocalRemoveAnimations in the components inside the app:

@Composable
fun ComponentSomewhereInTheHierarchy() {
    val removeAnimations = LocalRemoveAnimations.current.enabled
    ....
}

All right, now we have everything to build the safer marquee modifier. Let's do that in the next section.

`safeMarquee`-Modifier

Now that we have the information about the user's "Remove animations"-setting available via LocalRemoveAnimations, we can use it to adjust the text using the basicMarquee-modifier.

If the user hasn't enabled the "Remove animations" setting, we want to show the marquee; otherwise, let the text flow on multiple lines. Let's define a custom modifier with the composable modifier factory and call it safeMarquee:

// MarqueeScreen.kt

@Composable
fun Modifier.safeMarquee(): Modifier {  

}

Next, we want to read the value from LocalRemoveAnimations and, using that information, either add the basicMarquee-modifier to the modifier chain or return the current modifier chain without any additional ones. Here's the code to do so:

// MarqueeScreen.kt

@Composable
fun Modifier.safeMarquee(): Modifier {  
    val animationsRemoved = LocalRemoveAnimations.current.isEnabled()

    return if (animationsRemoved) 
        this 
    else 
        this then basicMarquee()
}

With these code changes, we get the desired result. Here's a video showing a preview of a Text-component with the safeMarquee-modifier:

Wrapping Up

In this blog post, we've looked into how to make the basicMarquee modifier more accessible for users with the "Remove animations"-setting turned on. We checked the value of this setting, stored it as static composition local, and then used it to decide if we add the basicMarquee to the element.

Do you use the "Remove animations"-setting? Or have you encountered problems with it as a user or developer?

Links in the Blog Post

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

2025-03-10T07:37:01.849Z

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

Earth has traveled around the Sun, and it's time for the We Coded again! I've been waiting for this for a year because I have things to say. I planned parts of this blog post a year ago, so it's been a long wait.

Little did I know then how the situation would change in a year. With all the things happening in the US, the fast rise of far-right ideologies in Europe, and the attacks on many minorities, including gender minorities, it's even more important that such campaigns as We Coded exist.

In the past years, I've shared my experiences as someone from a gender minority in tech, and I decided to continue with that this year, too. It's been a heck of a year, and I can share only a fraction of what I've seen, but even that is too much.

Oh, and this year, I decided to try out something new and recorded some of the experiences as a video. It's embedded at the end of the blog post.

Blog Post Comments

So, first, some blog comments I've received. Many are from last year's WeCoded post, and some have already been deleted because of misconduct.

Let's start with this one person who was first commenting on my blog post at Dev, and then, when they got blocked, they reached out to me in Polywork.

So, there's a lot to unpack there, but I'm not going too deep with it. Just note the "other motives"-part. The message from that person on Polywork was this:

Again, they're referring to "false metoo" and "expecting special treatment as on Facebook or Tinder".

I'm just wondering, what are these people doing at work and in professional circles? Are they looking for a partner because they seem to assume that everything somehow relates to "other motives", which I'm innocently interpreting as wanting to have a relationship. But most likely, sex plays a part here, too.

And the thoughts about sex don't stop there. I cross-posted the same blog post to Medium, and it got boosted and attracted many eyes. Blake (this was the name of the commenter) decided to comment on it.

Here again, "Why do you have to shove your sexuality down everyone's throat". And I must remind you - I did not talk about sex in my blog post. Just my experiences in tech, I repeat, nothing about sex. Not even anything about my sexual orientation.

So... My only conclusion is that in Blake's eyes, just by existing as an assumed woman, I'm shoving my sexuality down everyone's throat. And I think that tells a lot about the blakes of this world, not about me.

The blog posts I wrote last year got many other similar comments. They were about "gender wars", how my experiences are invalid, and how I just should accept that this is what it is and leave it be. I'm not going to do that, by the way.

And on a related note, there was one more comment I wanted to include in this post. The blog post was about creating more inclusive gender selection options in forms with Jetpack Compose, and this comment is what I got:

Oh, how I love it when someone tells me to stay in line and not talk about things that matter to me. [/s] Like these inclusive forms. You know, as a non-binary woman, forms asking my gender are most of the time just excluding me.

Naturally, my reaction to this comment was to turn it up a notch. I'm not going to be silent about these things.

Speaking Experiences

I also do public speaking, and while not all conferences or talks attract non-nice things, there are always some. I want to share a couple of experiences from one conference last summer.

I was giving a talk about accessibility. You know, that's my specialty. I've been certified in it, and one could say I know a lot about it. Right before the talk, there was this one person who decided that it was a good idea to explain to me what accessibility is. Or, "splain" would be a better word (I'm not going to use "mansplain" because the last time I used it, someone was so hurt about it that it got nasty).

Well, I was standing there, listening. I was too polite to stop them, and I was also nervous about the talk that was about to start in a couple of minutes, so I just stood there. And when I finally began my talk, I was super stressed. It was an awful feeling to start speaking to hundreds of people.

But the talk went well, and I aced it. After the talk, I took my Q&A privately, so, not from the stage. I enjoy doing it that way because it allows for actual discussions with people, not just answering questions. And there were people! And so great questions!

There was just this one thing - a person I met for the first time that day decided that it would be a good idea to answer the questions on my behalf. So there we were. Someone asked a question, and I tried to start answering faster than this person, and when I did, they had to add something to the answer after me. And this continued until we had to leave the room for the next talk to begin.

I was shocked but didn't want to seem impolite (yeah, I should work on that), so I didn't say anything at the moment; I just tried to get through the situation.

Later, I confronted them, and they told me they had good intentions and thought they would support me because I was speaking for the first time.

I've been speaking since 2020.

So, a tip: If you genuinely want to support someone, ask them what they need and want. Don't assume. Most speakers want to answer the questions themselves that the audience comes to ask them. You know, just themselves, because they're experts on the topic.

After the talk and these incidents, I felt terrible. Like, I've been doing this for a while, and these people assume that I don't know what I'm talking about.

I doubt these things happen to men - or if they do, they're rare. But when you come from a minority in tech, you often need to prove yourself multiple times, while someone from the majority is assumed to know their things right from the start.

Being At Work

Finally, I want to talk about work. Being a non-binary woman in a team where I'm often the only non-man, I see these biased things happening constantly.

And I know no one on the team has bad intentions. They've just been in a man-dominated world and man-dominated field for so long that these biases are built-in. And many of them try to mitigate the bias, I know they do.

I had to write the previous paragraph because I know that some of them will read this blog post, and I wanted to underline that I don't assume that any of the things I'm saying were done because of some evilness, and I have no hard feelings towards them because of these things.

It also tells a lot about the emotional work we women and non-binary people do to ensure we're not misunderstood when speaking up.

The past year has contained some classic biased situations. Like when I brought up a thing we must do and was greeted with, "No, we're not doing it". And then, a couple of weeks later, my man colleague brought it up, and the answer was straight "Yes", without any discussions.

There have been many situations where something has been asked about a topic I'm very knowledgeable in, and a man colleague, who has almost zero knowledge on the topic, has answered the question before me. I've also been forgotten in meetings - either forgotten to invite, or simply not given a turn to speak when everyone else was given a turn. Of course, I was apologized to later.

These are just some examples, but they take their toll on me, year after year.

Final Words

So yeah, In the blog post, I've shared some of my experiences from the past year as someone from a gender minority in tech. I would love to say that it gets better, but on some things, it feels like it's getting worse because of the general attempts to turn the clock many years back on the human rights front.

I also want to make this all visible and say to anyone in this position that you're not alone, and it's not you. And you're not imagining it.

I could have listed some advice on how to be an ally - but I decided that this year, it's about sharing my experiences and just painting the picture of what tech can look like for an outspoken, non-binary woman in tech. Also, my previous blog posts give tips on being better ally - you can find the blog posts as part of the series at the beginning and end of the blog post on Dev.

Video

Does Gemini Generate Accessible Android Apps?

2025-03-31T06:30:01.943Z

The AI is here, and we all are going to lose our jobs. Or that's what I've been hearing for a while now, and I don't believe in it. I've had this skepticism towards AI-generated code for many reasons, and the biggest of them all is accessibility.

I don't believe AI can create fully accessible applications just yet. Why? The training material is usually the code that is out there, and it is not accessible. I love to cite myself here, so if you want to find some stats about Android apps not being accessible, I wrote a master's thesis on the topic: Towards More Accessible Android Applications: An Actionable Accessibility Checklist for Android Developers.

But as I don't just want to state things without any backing on them, I decided to test if AI assistants can create accessible code. My hypothesis was that the code won't be fully accessible, and it will mirror the apps developed by humans.

This blog post is the first in a series of testing different AI assistants to create a small Android app, and how accessible it will turn out with each of them. I will start with Gemini, as it's available via Android Studio, and I have easy access to it. In the next posts, I'll try a couple of other tools to compare, and then I will write a summary post from all the tests.

The App

Let's first look at the app that I'm testing. I did two rounds, and it was good that I did - the output changed quite a lot.

I used stable Android Studio Meerkat for the first version, and at the time of writing this blog post, I realized I did not mark the exact version number. The second round was with Narwhal 2025.1.1 Canary 2.

Prompt

The prompt I gave to Gemini both times was:

Can you generate UI screens for an app, 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.

After Gemini was done with code generation, I also asked it to summarize how the app's accessibility was considered. The answer for the first time was:

Content Descriptions: All interactive elements (the OutlinedTextField acting as the dropdown trigger, the dropdown items, the save button) have appropriate contentDescription values for screen readers.

Focus Management: The dropdown works correctly with keyboard and switch navigation.

Keyboard Support: The dropdown can be opened and closed using the keyboard.

Button: Button has focusable functionality.

And, oh boy, did it have content descriptions and focusable buttons. But more about that later in the blog post.

The second answer was:

Semantic Structure and Content Grouping: The app uses Compose components in a way that establishes a clear UI hierarchy, making it easier for assistive technologies (like screen readers) to understand the relationships between elements and to navigate content.

Text Alternatives and Content Descriptions: All non-text elements (icons, images) have descriptive text alternatives (contentDescription), and all visible text is sourced from string resources (stringResource), allowing screen readers to convey the meaning of these elements and making the app localizable.

Keyboard and Voice Navigation Support: The app is designed to be fully navigable using a keyboard, and is compatible with voice navigation systems, thanks to the logical tab order and the clear labels provided for interactive elements.

Visual Accessibility: The use of Material 3 ensures sufficient color contrast for users with low vision, and the use of sp units for text sizes allows users to adjust text scaling according to their preferences.

Screen Reader Compatibility: Compose automatically generates an accessibility tree, and the app's design uses components and modifiers correctly to make that tree accurate and helpful for screen readers, allowing users to easily understand and interact with all parts of the app.

The second answer was already more extensive and considered more aspects.

The UI

Here's a short video of how the app turned out, this is the second version:

Testing Process

After building the app, I ran a limited set of manual accessibility tests on the app. I used my Pixel 7 Pro, 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 Things I Caught on the First Run

When testing the first version, I found problems. Oh boy, did I find problems. I'll share about them next, explaining why they are problems.

Content Descriptions Everywhere

I first noticed that it added contentDescriptions pretty much everywhere because it said that they're important for accessibility.

While content descriptions are important for some elements, like non-decorative graphics, adding them to every single button and text (yes, it added that to text as well) makes the UI either annoying, or, in some cases, impossible to use with assistive technology.

Let's look at a couple of examples.

First, the home screen. The code for each button looks like this (I've omitted the nonessential parts):

Button(
    onClick = { .. },
    modifier = Modifier
        .semantics { 
            contentDescription = "View yarn stash" 
        }
        ...
) {
    Text(text = "View Yarn", style = ...)
}

So, what's the problem here? When a screen reader or text-to-speech user arrives at these buttons, instead of "View Yarn", they hear both the "View Yarn" and "View yarn stash". The content description doesn't give any new information; it's just redundant repetition. If you're navigating by listening, you most likely don't want to hear anything redundant.

Then, there was the example of the yarn (and needle) detail screens. The code generated looks like this:

Text(
    text = "Brand: ${yarn.brand}", 
    modifier = Modifier
        .fillMaxWidth()
        .semantics { 
            contentDescription = "Yarn brand"
        }
)
Text(
    text = "Name: ${yarn.name}", 
    modifier = Modifier
        .fillMaxWidth()
        .semantics { 
            contentDescription = "Yarn name" 
        }
)

In the previous example with the button, contentDescription just added extra information to the button. With Text-component, however, it overrides the contents of the text. So, instead of "Brand: Malabrigo, Name: Rios", screen reader users would hear "Yarn brand, Yarn name", which makes the screen practically useless for them.

Not Scrollable

The next issue I ran into was that some screens don't scroll if the content takes more height than the viewport. It becomes a problem fast with larger font sizes - if the page doesn't scroll, and content takes more space than available, then the rest of the content is unreachable.

Clickable And Focusable

When I asked for a summary of the accessibility improvements, one of them was that the "Button has focusable functionality". And yes, buttons should be focusable. And you know, if you're using the native Button-elements, they are focusable out of the box.

But as we're working with AI, it's not that simple. The code for clickable elements (the needle and yarn list items) and buttons looks like this everywhere:

Card(
    modifier = Modifier
        ...
        .clickable { 
            onItemClick(needle.id)
        }
        ...
        .focusable()
) {
   ...
}

and

Button(
    onClick = { ... },
    modifier = Modifier
        ...
        .focusable(),
) {
    ...
}

Do you spot the problem? Both components are clickable (Button has it under the hood, and the Card has the clickable-modifier), which already adds the element to the focus order. There is no need to add the focusable-modifier.

And if you're wondering if there is no harm in adding it, from an accessibility perspective, there is. If you have both clickable and focusable modifiers, they both add a tab stop, which, for example, for someone navigating with a keyboard, means the following:

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

The expected behavior is that step 2 should not happen.

The Second Run

For the second test app, most problems were gone, but the buttons still had the text present twice. This time, however, the reason was more understandable - A descriptive icon had the content description set, while it should be set to null, as the button already has a text.

Button(onClick = onShowYarnListClicked) {
    Icon(
        Icons.Filled.List, 
        stringResource(R.string.show_yarn_list)
    )
    Text(
        stringResource(R.string.show_yarn_list)
    )
}

If you're wondering how to correctly add content descriptions, I've written a blog post about it: How to Add Content Descriptions in Compose - A Guide for Android Devs.

Other than that, my tests didn't find any significant issues that would entirely prevent the app's usage for some groups of assistive technology users. However, I must note that I did a limited set of tests, and the app is rather simple, so this is not me saying everything's accessible, but at least the big problems with the first version were gone.

In Summary

After two rounds of testing with Gemini, I was surprised about the accessibility of the generated code. I mean, on the second run. The first one was pretty disastrous.

What bothers me is that I don't know why the quality improved so much for the second round. Was it luck? Was there some version change in Gemini? I tried looking for version mapping but did not come across any. So, if someone has any inside knowledge (or just a version mapping I missed), I'd love to hear!

I'm interested in seeing how accessible code is generated by the other available AI tools. After testing with different tools, I will write a separate recap post and summarise my thoughts more.

If you want to see the code for the second app, it's available in Github: Gemini Test App.

Links in Blog Post

The Problem of Trun...

2025-04-26T07:31:42.351Z

Imagine that you're in an unfamiliar location. You can see a signpost, but it's old, and most of the letters of the words have been scratched off. The names in the signs all seem similar, given the couple of letters you can see.

And you need to get somewhere, but the signpost is not helping at all. You're lost.

As the title gives away, I'm writing about something starting with "trun". I could be writing about the problems of trunkfish. They seem a bit lost, so the topic could be that. Or I could be writing about truncheons and the issues caused by them.

But no, this time, it's about truncation, specifically when truncation has not been implemented correctly.

Texts in applications are like those signs in a signpost. They most often lead to somewhere, give some instructions or necessary information, or are otherwise relevant. Texts wouldn't be in the app if they weren't meaningful.

Problem of Truncation Done Wrong

We have this widely spread pattern on Android, where the words are truncated with an ellipsis if they don't fit the container, without any way to expand the missing part of the text.

For example, when you have a font size that is big enough, app names are truncated. The following image shows an example from accessibility settings and font size selection in Pixel:

And okay, one could argue that if you install an app, you should be familiar with it and be able to recognize it even when you just get three letters from the name with the icon.

But it's not that straightforward - what if it's an app you've used a year ago? Or what if you have memory issues due to something permanent or due to stress? Or any of the number of reasons why recognizing the app only with a partial name and an icon is not possible - let alone the cognitive load it creates.

And it's not just the app icons; it's everywhere in the apps: The bottom navigation, buttons, links, titles... All these are places where the user would need the context of "What will happen if I press this item?" or "What is this section about?" or similar questions.

The problem of truncation done wrong is about preventing access to information for users who use, for example, larger font sizes, smaller display sizes, or a combination that makes text truncate.

And when we're building apps, we're thinking about the users, right? And building the apps for them?

Material Design 3 Perspective

But if this "truncate text with ellipsis and leave it at that" is so widespread pattern, it must be part of Material Design specifications, right? Let's look at what Material Design 3 says about text and truncation. You can find all this information in Accessibility writing & text - Text truncation.

The page referred to before mentions:

Information should always be available to readers, even if text is truncated or wrapped.

And

If there's an ellipsis, but no way to show the truncated text, it is not accessible

There you have it. Even Material Design agrees with me - if there is no mechanism to see the text without truncation, it's not accessible. And in this case, I would equate it to not being usable.

So, What's the Option?

Yes, the long text can still be a problem that needs to be solved somehow. So here are some options listed - first, some recommended ones, and then some I don't recommend doing.

Don't Truncate the Text with Ellipsis

My first advice is - don't truncate the text with ellipsis. Just let it take the space it needs and make your overall app UI responsive so that the text is not cut in any way.

In many places, this strategy would work perfectly, and the only reason why it's not used is that someone decides that "this text needs to be on one line, and the UI can't be responsive". The decision is often unconscious, just not realizing that not truncating the text is an option.

Add "Expand"-option

There are cases when the whole text can't be visible. One option for this case would be to add an "Expand" button, which then displays the whole text - either as a modal or by displaying the rest of the text by expanding it. This strategy is also recommended by Material 3.

Use `basicMarquee` - But Make It Accessible

What about the basicMarquee-modifier? Wouldn't it be a perfect way to display shorter texts which don't fit on one line?

Now, if you haven't encountered the basicMarquee modifier before, it works so that when a text is wider than its container, it scrolls horizontally, displaying the whole text that way. You can define how many times it does the scroll; the default is three. After iterations, it displays as much from the title as the container's width allows, hiding the rest.

Sounds great, right? For many, it is. But basicMarquee doesn't respect the "Remove animations"-setting. That can cause a lot of problems for folks who use that setting - for example, for me, these marquee-styled animations are the worst triggers for my symptoms.

There are ways to make the basicMarquee modifier more accessible, and I've written a blog post about that: Making basicMarquee-Modifier More Accessible.

Non-recommended Ways

There are also some ways to "solve" the problems of truncation that I don't recommend. The first one is not to do anything, but as we care about our users, we're not using that strategy, right?

Another option would be preventing font scaling. While there might be some corner cases where preventing font scaling is acceptable, from an accessibility perspective, I'd say never do that. Users who use larger fonts use them for a reason, and if you prevent font scaling, it means that the text is way smaller than they can, for example, see. That, in turn, means that your app (or part of it) might become unusable for them.

Wrapping Up

This blog post looked into the problem of truncation and how to solve the issues text truncation might present. I presented a couple of recommended ways and then two non-recommended ones.

Have you run into problems with text truncation?

Links in the Blog Post

Does Junie Create Accessible Android Apps?

2025-05-10T06:37:02.018Z

I'm continuing my tests with AI-generated Android code and how accessible these generated apps are. This time, the tool of choice is Junie, the coding agent by JetBrains.

If you want to know why I'm doing this or want to read my take on how accessible code Gemini creates, the first post is available at Does Gemini Create Accessible Android Apps?.

So, I got into the Early Access Program (EAP) before Junie was generally available and generated the first app. I had all these plans to proceed to the second run and write this blog post sooner, but then life happened, and I founded my own company. Suddenly, time passed, and Junie is now generally available.

Before we dive into the application generation and accessibility testing, I'll share a couple of words about Junie I wrote right after the first try, with some additions after the second run.

Junie

As mentioned, I got access to EAP and was curious to try Junie out, as it differed from the AI solutions for coding I'd used before. Particularly, it also changed the files and didn't just give me the code, and I could skip all the hard work of creating files and copy-pasting the code into those files.

Some thoughts I had:

I was impressed by the structured approach for doing things. It was easy to follow what was happening next and what was coming after that.
When creating the first app, Junie kind of went overboard with adding libraries like Room into the project, but not using them in the code.
With the first app, I had to solve one KSP version issue by hand, because I got tired of Junie trying to find a working library version. It used some non-existent version numbers first. The second app used kapt, which resolved the version right away.
I had to iterate a bit with the first version to get all the features I wanted, like adding yarn. The second app generation was smooth from this point of view.

The App

As with the tests with Gemini, I did two rounds of testing - first, with the Early Access Program version back at the beginning of April, and the second one was with the one available at the beginning of May.

For these tests, I used IntelliJ Idea with plugins for Android development to use Junie, as it's not available in Android Studio.

Prompt

The prompt I gave to Junie both times was:

Can you generate UI screens for an app, 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.

I also asked for a summary of how accessibility was considered. The answer from the first run disappeared into the void (because I messed up with saving it), but the second time, I was wise enough to save the document Junie had created. As a summary, it listed the following things:

The Yarn Stash application demonstrates a strong commitment to accessibility through:

Comprehensive content descriptions for screen reader support

Proper handling of nested content descriptions to avoid duplicate announcements

Use of string resources for all text including accessibility labels

Scalable typography that respects system font size settings

Material Design components with built-in accessibility features

Logical semantic structure for navigation

If you want to read the full summarization, it's available in the ACCESSIBILITY.md-document in the repository. And just to be clear: These are words from Junie, and I disagree with many of them (we're getting into it in a bit).

The UI

Here's a short video of how the app turned out; this is the version from the second run:

Testing Process

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

Things I Caught on the First Run

If you've read my previous blog post about Gemini and accessible app generation, you already know some of the problems I will present.

Content Descriptions

As Junie summarized for the second app, the code contained comprehensive content descriptions. As with Gemini, there were redundant content descriptions - like adding a content description to a button with a text, which means a screen reader user would hear both of the texts.

If you want to know more about the problems with too many content descriptions, Does Gemini Create Accessible Android Apps? explains that in depth.

Home Screen Not Scrollable

When I changed the font size to the biggest, and the content took more height than the viewport height, the view wasn't scrollable. This was also a problem with the Gemini-generated apps - and I'll repeat here that if the page doesn't scroll, and content takes more space than available, then the rest of the content is unreachable.

Larger Font Sizes Not Supported

The other problem with larger font sizes was that the layouts of the yarn and needle screens, as well as the home screen, didn't adjust for the text taking more space. The two-column layout was fixed, so when the text took more space, it just crammed everything into the two-column layout, making it harder to read.

The more accessible solution would be to let the content flow into a one-column layout when there's not enough space for a two-column layout. So, in code, the initial implementation looks like this (I've omitted the non-essential parts):

Row(...) {
    Text(
        text = label,
        modifier = Modifier.weight(1f)
    )
    Spacer(modifier = Modifier.width(16.dp)) 
    Text(
        text = value,
    )
}

One way to solve the issue here would be to use FlowRow instead of Row - that would automatically let the content flow into the next row if there weren't enough space. Of course, some other solutions could work better for more complex layouts and stricter design requirements.

The solution with FlowRow could look like:

FlowRow(...) {
    Text(
        text = label,
        modifier = Modifier.weight(1f)
    )
    Spacer(modifier = Modifier.width(16.dp)) 
    Text(
        text = value,
    )
}

And On the Second Run

As mentioned, the second run happened about a month after the first. All the problems I listed for the first run were present, and there were some extra ones as well. I'll discuss them next.

On the second run, keyboard navigation testing revealed some additional problems. When creating or editing needles, the dropdown for needle type selection didn't work with a keyboard. After some testing, it seems that the problem is a bug in ExposedDropdownMenu and not the code Junie created.

Another thing I noticed was that there's an invisible extra tab stop in yarn and needle screens. After some investigation, it turns out that there is a floating action button, which is not visible - it's probably hidden behind the bottom bar as the app is wrapped with a Scaffold containing the bottom bar, and the floating action button is defined in a Scaffold in each individual screen.

Incorrect Semantics

When I asked Junie to improve the accessibility of the second app, it did do some good. For example, it added heading-semantics to headings, and it got it almost right. Most of the elements it added heading()-semantics were indeed headings. But not all.

It also added some redundant semantics - for example, the bottom bar items got the Tab role and state description. While those are things you should add for custom components, bottom bar items already have these semantics built-in.

Wrapping Up

Compared to Gemini, and especially the second run with Gemini, Junie seemed to generate code that had more accessibility issues. Those issues are something I see in code written by developers, which makes sense, as the material used for training LLMs is real-world apps, so the issues get amplified. You can see it from the not-so-good ways of solving problems, like adding extra content descriptions when not needed.

Testing these two AI tools for code generation has already started to paint a picture, but I want to do some more testing before writing conclusions. Next up, I'm going to try out Cursor.

If you want to see the code for the second run with Junie, it's available in Github: Junie Test App

Links in the Blog Post

Does Cursor Generate Accessible Android Apps?

2025-06-16T05:30:02.393Z

I've been testing the accessibility of Android code created by different AI tools, and this time, it's time to test Cursor. I know it's not the most ideal tool for Android development, but I still wanted to test it.

If you've read the previous posts in the series, you know the drill - I'll generate the app code and then test it. There are links to the blog post at the top of this post if you want to refresh your memory or if you haven't read the previous blog posts. In them, I also explain why I'm doing this.

So, let's get to the actual thing we're here for.

The App

This time, I did only one round of tests. It's not that I got lazy or anything - using Cursor was just so annoying that I decided to do only one test.

I used a combination of Android Studio and Cursor editor to construct the app. I created the project with Android Studio, opened it in Cursor, and wrote the app prompt. Then I moved to AS, tried to build the project, fixed issues with dependencies, and built it again. Then I realized it didn't have proper navigation, so I moved back to Cursor and did some additional prompting. After several similar rounds, I finally got the app to my phone and the testing phase.

There were some good and not-so-great sides to using Cursor from an Android development point of view. The setup was smooth, but once I got to do some actual work with Android, the code had many problems. For example, it didn't add dependencies at all, and I had to add them by hand. It also added some non-existent parameters to Composable functions.

So yeah, compared to Gemini and Junie (tools I've tested so far), I would go with either of those for Android development instead of Cursor.

Prompt

The prompt I gave to Cursor was:

Can you generate UI screens for an app, 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.

I also asked for a summary of how accessibility was considered. Here's a short version without every example it gave.

Content descriptions:

All interactive elements have descriptive content descriptions

Semantic Information

In detail screens, we use semantics modifier to provide additional context. This helps screen readers understand the relationship between labels and values in detail items.

Material 3 Design

Using Material 3 components ensures proper contrast ratios

Surface colors and text colors follow Material 3 guidelines for readability

Proper spacing and touch targets for interactive elements

Navigation

Clear navigation patterns with back buttons

Consistent navigation structure

Auto-mirrored icons for RTL support

Text Hierarchy

Using appropriate typography styles

Clear visual hierarchy helps users understand the content structure

Interactive Elements

All clickable areas are properly sized for touch targets

Cards are used to group related information

Clear visual feedback for interactive elements

I don't agree with all of them being something that improves accessibility, as we'll see later in the blog post, but most are legit things - both from accessibility and this app's code point of view.

The UI

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

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

Once again, there were some accessibility problems. Many of them were similar to what Gemini and Junie created. Let's look at the accessibility problems more closely.

Content Descriptions Are Not Going Anywhere

As with Gemini and Junie, Cursor also added extra content descriptions. While in this case, the content descriptions were the same as the text content, grouping the text with mergeDescendants would have accomplished the same result without adding two ways of going through the content: First as the content description, and then as separate texts.

In practice, that means that the user with a screen reader first navigates through the following texts (content descriptions): "Brand: Brand A", "Yarn name: Yarn 1," and so forth. The next round would be "Brand", "Brand A", "Yarn name", and "Yarn 1", which adds redundant information to the screen. With this amount of information, it would probably be just annoying, but it would become frustrating with more details on screen.

Let's look at the code behind this problem. This code snippet is from the list screen for different yarns. I've omitted irrelevant parts:

Column(
  modifier = Modifier
    .semantics { 
      contentDescription = "$label: $value"
    }
) {
  Text(
    text = label
  )
  Text(
    text = value
  )
}

Better code would be:

Column(
  modifier = Modifier
    .semantics(mergeDescendants = true) {} <-- Change to this
) {
  Text(
    text = label
  )
  Text(
    text = value
  )
}

Scrolling is Not Supported

Increasing font size reveals that the screens don't support scrolling if the content doesn't fit into the view. That's not optimal for the app, as its sole purpose is to list data. These problems become apparent when scaling font size up even sooner than with the default font size, as the content takes more space.

Surprisingly, the app doesn't prevent landscape orientation. However, as scrolling is not supported, every single screen is unusable, as there is less vertical space when orientation is horizontal.

So, the solution here is to add scrollability to all screens - even those that don't require it with the default font size most developers use when developing an app.

Font Scaling Causes Further Problems

When increasing the font size, fonts scale appropriately. However, as usual, the top app bar doesn't stretch to accommodate a big font size with two lines of text. This is a common issue, and it's more of a problem with the TopAppBar-component's default values.

One way to fix the issue would be using TopAppBar's expandedHeight-property together with different heights for smaller and bigger font scales. For this simple app, the straightforward solution could look like the following:

@Composable
fun NeedlesDetailScreen(...) {
    val fontScale = LocalConfiguration.current.fontScale
    val topAppBarHeight = if (fontScale < 1.5)
      TopAppBarDefaults.TopAppBarExpandedHeight
    else 
      TopAppBarDefaults.TopAppBarExpandedHeight * 1.5f
  }

  Scaffold(
    topBar = {
      TopAppBar(
      ....
        expandedHeight = topAppBarHeight
      )
    }
  ) {...}
}

This problem with TopAppBar not scaling with bigger font sizes is not visible with every phone, so in general, this issue might be missed when testing, and thus, there are not many fixes for AI to learn from. For example, with this test app, I could see it with the Pixel 8 Pro emulator but not with the Pixel Fold I'm using.

In Summary

While using Cursor was a pain, the code was somewhat ok. And when I say ok, I mean that it had the usual suspects, so, accessibility problems, but nothing major or additional.

As I mentioned in the previous blog post, it's already starting to paint a clear picture of the accessibility of AI-generated Android code. Still, I will do one more test with Claude Code before writing a summary post.

If you want to see the app code, it's available on Github: Cursor Test App.

Links in Blog Post

Cursor Test App

It's All About (Accessibility) Focus And Compose

2025-07-07T07:14:02.197Z

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.

Links in the Blog Post

10 Tips to Make Your Blog Posts More Accessible

2025-07-18T11:44:16.434Z

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.

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

Does Claude Generate Accessible Apps?

2025-08-22T10:08:32.560Z

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

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.

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

Wear OS Accessibility Considerations

2025-09-06T07:27:30.641Z

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!

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

How to Work With Me?

2025-09-21T10:26:27.982Z

This is a living document, and I try to update it when I learn or realize something new. I didn't want to create a dedicated page for it, at least not just yet, so I published it as a blog post.

About me

Hey, I'm Eeva-Jonna, but everyone knows me as Eevis. I'm not Eeva, but I often let it slide with non-Finnish speakers, and two-part names aren't that common elsewhere. But I'd love for you to use either Eevis or Eeva-Jonna, not Eeva.

I'm a non-binary woman, and my pronouns are they/she. In practice, it means that you can refer to me as 'she' (mostly, because I'd be correcting everyone all the time if I wasn't ok with 'she'), but I often refer to myself as 'they,' and I ask you to respect that. So if I write, for example, my bio with 'they', it's not a typo, and you don't need to fix it to 'she'.

I'm also autistic with a head injury, which means I process information differently than neurotypicals do. I try to explain some of these things in this document, but in general, please, don't make assumptions through a neurotypical lens about my behaviour or the way I'm thinking.

Lastly, I don't do well with injustice, or any sexist, homophobic, transphobic, ableist, or racist comments or behaviours. I will bring them up if I have spoons.

Working Hours

If I can choose my work hours without limitations when I'm part of a team, I work from about 7:30 to 15:30 Finnish time. Of course, I'm flexible if there are meetings or other things agreed, but these are my ideal working hours. For solo work, I usually start earlier.

I'm definitely a morning person, and I do my best cognitive work in the morning. Writing is one of the things I reserve for mornings, as I'm most productive at that time. I can code all day, but I usually solve the most challenging tasks in the mornings.

Communication Style

Written communication is most natural for me because it gives me time to think and formulate my thoughts. It also gives me time to process what the other person is telling me.

Meetings, where I need to react quickly and give responses, are not my cup of tea most of the time. If I happen to have a lot of energy, I might shine in those meetings, but that's like a maximum of 5 percent of the time. I'm often tired.

I'm Finnish, which brings another layer to communication differences, especially in a multicultural environment. Even our friendly communication is often perceived as too direct compared to, for example, the US communication style. We tend to skip the small talk and fillers more often and go to the topic faster. We are also more reserved, which can often be interpreted as unfriendliness, but I can assure you, it's not that.

Personally, I find small talk challenging, even though I've tried to learn how to do it. I don't always even notice that there is a time for it, and I tend to go straight to the point, especially if the point is something I'm excited about. So if this happens, it's not you, it's me.

And please, give me the honest opinion, situation, or prediction. For example, in a job interview, I appreciate a truthful explanation of the situation at the workplace, rather than some marketing lies. I really want to know what I'm committing to, even if it's something suboptimal. The same goes for anything else - be it a project or other commitment.

The Hard Conversations

When I bring up problems, I want to discuss them so that everyone gets heard, not just bring solutions. That often means that initially, I'm not providing solutions; I'm just describing the problem so that everyone knows what it's about and can start ideating.

I often have solution ideas in my mind, but I don't want them to have the anchor effect. Instead, I want to hear others' ideas as well. In certain kinds of environments, this might look like I'm just bringing up problems, not solutions.

Also, if I feel that the environment is not psychologically safe, for me, asking questions or help publicly is not easy, and it takes time to reach the point where I do it.

One example is asking for help with a coding problem in a public Slack channel. Assume I constantly read messages where others are being borderline rude, and framing it as "we just give direct feedback". In that case, it's not a psychologically safe environment for anyone, but especially for someone who has had to endure more or less belittling for their whole career. So, when I'm writing the question on that channel, I need to mentally prepare for those rude comments and check all the possible scenarios for my problem, instead of, you know, just writing the question. And that takes a lot of spoons to do that.

Meetings

I'm one of those people who don't enjoy meetings if there are too many of them in a day. Whether in-person or remote, I become exhausted after attending too many meetings in a day. I also need some time to transition from one meeting to another, so I can contribute my best in both meetings, especially if they're unrelated.

Meetings need to have an agenda. I need to know what I should be prepared for. If it's an informal coffee meeting, that's enough to know about it, but for meetings where something needs to be decided, I want to know beforehand what we're doing and what the goal of the meeting is.

If I'm in the middle of something, like solving a task or writing a document, asking me to just hop into a call is not a good idea if you want me to give my best in that meeting. So please, allow me at least 15 minutes to transition from my task if possible.

Information

When there is something new to understand, especially if it's a big concept or a whole new codebase, my approach for getting into it might seem chaotic. I'm trying to absorb as much as possible, and then start building the bigger picture, piece by piece.

So, the best way to give me information? Give me a summary, just enough to start working with, and let me ask questions, read the code or other materials, and absorb everything.

When given a lot of information, I often don't have questions right away. My brain needs a moment to build the connections before I can ask anything meaningful. So let me have some time, and then come back with questions.

Remote vs Office

When I come to the office, I can rarely concentrate there. So, office days are for human interaction, conversations, ideation, and other things that are easier in person.

I do my best software development work at home, with my own setup. So, if a deadline is approaching or something else requires my concentration, I would rather skip the office days to get things done.

The Things Often Misunderstood

I gather a lot of information, and I start seeing patterns even before I realise it myself. So, when I bring concerns up, it's not negativity for negativity's sake. It's me seeing risks and trying to address them early on, rather than having these "Oh, things went badly wrong"-meetings after the s*ht hits the fan. Trust me, I've been in many such meetings, after I've warned that the exact thing could happen. But my bringing up the risks is often misunderstood as pure negativity and resistance to change.

When I'm Dealing with Stress

When I'm dealing with stress, I usually withdraw. I avoid coming to the office because I want to avoid any conflicts. I'm also likely to be sleeping poorly, so it takes a lot more from my social battery to meet with people, and this way, I'm trying to preserve my energy.

The Things I Struggle With

If things are too hazy, and I don't even know who to ask for clarifications, I might struggle. And this is not really about the technical details. It's about structure and understanding people and what they expect.

In these cases, I don't expect anyone to solve the issues for me. In the short term, I usually just need a nudge to find the relevant information to solve the problem at hand. If it's a project, then I will need to understand the bigger picture and expectations to thrive. But if the project is a constant mess with constantly changing or not clear expectations, it is super hard for me, and I most likely burn out trying to exceed those unknown expectations.

Feedback

If you want to give me some constructive feedback, please allow me space to react to it. I usually don't do well with it initially, and I need some time to process it. I am taking the relevant parts out of it, I promise, but I need time to get on terms with it. Rejection sensitivity is a real thing, folks.

For positive feedback, it might seem that I don't react to it. I'm learning to say thanks, but other times, I might just smile, and that's it. It doesn't mean I don't appreciate it - it's just that I haven't learned how to react to it.

I appreciate truthful feedback, so if there is nothing to say, then don't say anything. I won't, so if I give some (especially positive) feedback, you know I really mean it.

Wrapping Up

Overall, behind most of these things, there's the need to understand the "why" before I can actually do my best work. Sometimes it's about the technical decisions, but very often, it's about people's motives. If I struggle to understand the why, I often struggle to complete the task at hand, because I don't have all the necessary information.

Links in the Document

Compose UI Tests for Larger Font Sizes: Scrolling and Text Truncation

2025-10-31T05:02:12.332Z

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

Does AI Generate Accessible Android Apps?

2025-11-25T03:19:04.973Z

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.

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.

Why I'm starting a Newsletter About Inclusive Android Apps

2025-12-02T13:53:05.694Z

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.

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.

The Problem of Rows Breaking with Large Text

2025-12-16T03:39:14.982Z

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.

Year in Review - 2025 Edition

2025-12-31T08:05:21.055Z

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.

Be Mine and Add Interaction with Compose and Canvas

Published at February 13th

Read the post Be Mine and Add Interaction with Compose and Canvas

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.

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

Published at March 10th

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

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.

Wear OS Accessibility Considerations

Published at September 6th

Read the post Wear OS Accessibility Considerations

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

Beyond Font Scaling: Large Content Viewer with Compose

2026-01-17T06:00:04.914Z

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.

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

Adding Navigation support to Large Content Viewer with Compose

2026-02-28T06:32:20.708Z

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.

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.

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

About Invisibility, Propaganda, and Assumptions of Incompetence

2026-03-07T14:03:23.161Z

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.

Eevis Blog

Why Playing Team Sports Makes Me a Better Developer

Team Spirit (of the Game)

Perseverance

Willingness to Do Voluntary Work

Getting Away from Work Thoughts

Keeping My Brain Functional

Wrapping Up

Let's Talk About Accessibility

Why is GAAD Important?

But it's Not Only About the Websites

It's About Social Media

It's About the Language

Plain Language

Ableism

So What Can I Do?

Educate Yourself

Check Your Content and Language

Wrapping Up

Don't Develop Just for Yourself - A Developer's Checklist to Accessibility

Keyboard Navigation

Action Item for Keyboard Navigation

Alt-Texts

Action Item for Alt-Texts

Page Language

Action Item for Page Language

Text Resizing

Action Item for Text Resizing

Color Alone

Action Item for Color Alone

Mobile Zooming

Action Item for Mobile Zooming

Captions and Transcripts

Captions

Transcripts

Action Item for Captions and Transcripts

Wrapping Up

Resources

Why I'm Not One of the Guys

The Problem of Man-Default

Guys is Not Gender Neutral

Well, Why Don't I Just Speak Up?

What Can I Use, Then?

Alternatives for Guys

Using They Instead of He (or She for That Matter)

Being Aware of Man-Default

Wrapping Up

The Dark Side of Blogging

Some Background

Writing Quality Content Takes Time

The Pressure

Responses to Controversial Topics

Summing Up The Tips

Making Better Pull Requests

Keep the Pull Request in Scope

Give Context to the Reviewer

Add a Picture of the Changes

Pull Request is a Place for Discussion

Summing Up

Links

Thoughts From Reading Demystifying Disability by Emily Ladau

Person-First Language vs. Identity-First Language

Ableism

Systemic Ableism

People with Disabilities Can Be Ableist Too

Inspiration Porn

Wrapping Up

Links

First Month as an Accessibility Specialist at Oura

I Don't Have to Sell Myself or Accessibility

I'm Expected to Concentrate on Accessibility

I'm not alone

Wrapping Up

Links

Aria-Label is Not Always the Answer

What Is aria-label?

Interactive Elements

Elements with Landmark Role

Elements with ARIA-widget Role

img and iframe

What Is `aria-label`?

`img` and `iframe`

How does `aria-label` work?

`aria-label` and non-supported elements

Options for `aria-label`

What is `outline`?