# Eevis Blog Posts about accessibility, being a (woman) developer and life in general. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Autofilling in the Blanks DevFeed: [Autofilling in the Blanks]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2026-05-29T09:05:36.887000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Compose](), [Android](), [Accessibility](), [Usability](), [Forms](), [API]() Tags: [accessibility](), [android](), [api](), [compose](), [deprecated](), [forms](), [usability]() ### AI overview This tutorial explains how autofill can improve accessibility and usability in Android forms. It describes autofill services and settings, then shows how Jetpack Compose uses the semantics-based autofill API after the previous Autofill API was deprecated with Compose 1.8.0. ### Source excerpt If you have forms in your app that collect user information, autofill is one of the easiest accessibility wins you can add. Autofill is both an accessibility and a usability feature. And you can support it with just a few lines of code. What is Autofill? So, what is autofill, anyway? It's a technique that uses previously saved data to fill in text fields without having to type the full text. Typically, the data types are related to the user's name, address, email, or password, to mention a couple of examples. There are different autofill services for Android; some provide more data than others. Most of them are various password managers, but Google's service, for instance, also provides account-related data. You can find the autofill settings in your phone's settings. On Pixel, the setting group is called "Passwords, passkeys and accounts". You'll need to set a service as the preferred one to make autofill work properly. Autofill is also an accessibility feature. Let's look into that next. Autofill is an Accessibility Feature Supporting autofill for form fields helps people of all kinds. For example, if typing is difficult for you for any reason, like limited mobility, trembling hands, or fingers freezing outside, being able to use autofill services makes your life so much easier. Autofill also helps with avoiding spelling mistakes - when the data is already available and can be just filled out, you don't need to stress about making mistakes when writing your address, for example. And autofill makes it faster if you're in a hurry and need to buy a ticket somewhere. So, autofill has many great use cases. But how do you support it? Let's look at the details. Autofill and Compose Compose used to have an Autofill API for requesting autofill, but it was deprecated with Compose 1.8.0. Autofill is now requested with the new semantics-based autofill API. Supported Types As mentioned before, autofill supports different kinds of data. I'll list some of the types: Address-rela ## More Accessible Focus Indicators with Compose DevFeed: [More Accessible Focus Indicators with Compose]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2026-04-30T07:11:56.799000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Jetpack Compose](), [Accessibility](), [Android](), [Web Content Accessibility Guidelines](), [keyboard]() Tags: [accessibility](), [accessible](), [android](), [compose](), [focus](), [jetpack-compose](), [keyboard](), [web-content-accessibility-guidelines]() ### AI overview A tutorial on creating more visible keyboard focus indicators in Jetpack Compose. It explains relevant WCAG Focus Appearance requirements, notes that Android's default ripple may be insufficiently visible, and introduces the Indication API for drawing custom indicators such as an underline on focused interactive components. ### Source excerpt Last summer, I wrote a blog post about focus management with Compose. Ever since, I've had drafts of this post, but I didn't get to finalize it until now. The blog post is available in: It's All About (Accessibility) Focus And Compose. So, in this blog post, we're talking about focus indicators and how to make them more accessible with Compose. But let's first talk about focus indicators in general. Focus Indicators Focus indicators are, as the name suggests, indicators that show where keyboard focus currently is in the UI. They need to be visible so that keyboard and keyboard-emulating device users can navigate around the app effortlessly. An important thing to note is that the focus indicator I'm talking about here is not for the screen reader (e.g., TalkBack) focus. That is handled on the system level. Web Content Accessibility Guidelines (the standard behind accessibility legislation and used with apps as well, despite the name) has some requirements for accessible focus indicators. Per SC 2.4.13 Focus Appearance, the focus indicator needs to be either User agent's (Android system) default styles At least 2 pixels thick and has a contrast ratio of at least 3:1 between the same pixels of focused and unfocused states. Android's default focus indicator is the ripple, which isn't very visible. Technically, it would pass, but if you want to make the application accessible, you'll need to improve the visibility of the focus indicator. Let's next discuss one way to build more visible (and thus, more accessible) focus indicators with Compose. Building More Accessible Focus Indicators with Compose There are several ways of creating the focus indicators. You can, for example, add a border based on the focused state, as Appt.org suggests in their code snippets: Accessibility focus indicator in Jetpack Compose, but if you want anything more complex, you'll want to turn to Indication API. Indication API with a DrawModifierNode can be used to draw complex focus indicators. In ## Adding Navigation support to Large Content Viewer with Compose DevFeed: [Adding Navigation support to Large Content Viewer with Compose]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2026-02-28T04:26:46.364000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Jetpack Compose](), [navigation](), [Compose](), [keyboard](), [screen](), [Code]() Tags: [code](), [compose](), [keyboard](), [navigation](), [screen](), [test]() ### AI overview This tutorial explains how to add keyboard and assistive-technology navigation to a large content viewer built with Jetpack Compose. It presents an approach using focus handling to show item previews, covers keyboard and screen reader navigation, and discusses voice access support. The author notes that the example is a demo and should be tested with users of assistive technologies before production release. ### Source excerpt In my previous blog post, Beyond Font Scaling: Large Content Viewer with Compose, I explained how to build a large content viewer from iOS using Jetpack Compose. The implementation did not include support for keyboard or other assistive tech navigation, so this blog post tackles those topics. A disclaimer: The way I'm presenting the support for assistive tech navigation in this blog post is one approach, and my goal is to provide examples and context, but as always, this is a demo project. In your production app, things might get a bit more complicated, and you might need to handle more variables. So always remember to test the solution, ideally with your users who use assistive technologies. And I hope it goes without saying: Before releasing to production. In this blog post, I'm presenting code for keyboard and screen reader navigation, then sharing some considerations for voice access support. The code relies heavily on the code presented in the previous blog post, so if you have questions about it, please check that post. A link for the full code is also provided at the end of the blog post. Keyboard Navigation Support The pointer input implementation presented in the previous blog post relies on long-press, but keyboard navigation doesn't support that kind of interaction, so we need another tactic to display the item preview. With a keyboard, focusing on an item is a natural choice, so we're going to use that. The idea is that when a user who navigates with a keyboard or a keyboard-emulating device focuses on a bottom bar item for the same duration as a long press, we will show the item preview. We can do this with the following code: NavigationBarItem( modifier = Modifier .onFocusChanged { if (it.isFocused) { scope.launch { delay( viewConfiguration.longPressTimeoutMillis ) previewedItem = item } } else { previewedItem = null } }, ... } We use the onFocusChanged-modifier. Its state indicates whether the current element is focused via it.isFocused. If it is, we ## Beyond Font Scaling: Large Content Viewer with Compose DevFeed: [Beyond Font Scaling: Large Content Viewer with Compose]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2026-02-28T04:24:34.139000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Compose](), [Accessibility](), [iOS](), [Mobile](), [Web Content Accessibility Guidelines]() Tags: [accessibility](), [accessibility-guidelines](), [bottom-navigation](), [compose](), [ios](), [mobile](), [wcag](), [web-content-accessibility-guidelines]() ### AI overview This tutorial explains how to build a Large Content Viewer-like item previewer with Compose for bottom navigation items whose text cannot be adequately enlarged through font scaling. It describes the iOS accessibility pattern and discusses WCAG text-resizing considerations and the limitation that the proposed interaction relies on long press. ### Source excerpt 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 ## Year in Review - 2025 Edition DevFeed: [Year in Review - 2025 Edition]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-12-31T08:08:24.569000Z Content type: opinion Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Mobile](), [Android](), [coding]() Tags: [2025](), [accessibility](), [android](), [coding](), [mobile](), [review](), [year-in-review]() ### AI overview A personal review of 2025 covering a transition to independent mobile app accessibility work, the launch of the Inclusive Android Apps newsletter, development of a Wear OS stitch-counting app, and participation in talks, roundtables, and accessibility judging. ### Source excerpt 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: Year in Review - 2021 Edition Year in Review - 2022 Edition Year in Review - 2023 Edition Year in Review - 2024 Edition 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. Spe ## The Problem of Rows Breaking with Large Text DevFeed: [The Problem of Rows Breaking with Large Text]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-12-16T03:39:05.686000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Android](), [Compose](), [User interface design]() Tags: [accessibility](), [android](), [code](), [compose](), [developers](), [devices](), [layout]() ### AI overview This tutorial explains why Android Compose Row layouts can overflow or cut off buttons when users increase text size. It recommends replacing Row with FlowRow, avoiding fixed heights, and testing with large text and small screens. ### Source excerpt 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.spaced ## Why I'm starting a Newsletter About Inclusive Android Apps DevFeed: [Why I'm starting a Newsletter About Inclusive Android Apps]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-12-02T13:52:53.691000Z Content type: opinion Language: en Sources: [Eevis Blog]() Topics: [Android](), [Accessibility](), [User interface design]() Tags: [accessibility](), [accessible](), [android](), [design](), [developers]() ### AI overview The author introduces Inclusive Android Apps, a monthly newsletter about making Android apps more inclusive. It will cover accessibility, LGBTQ+ inclusion, cultural and language differences, privacy and safety for marginalized users, and one inclusion problem each month, including its impact on users and the reasons developers may create it. ### Source excerpt 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 b ## Does AI Generate Accessible Android Apps? DevFeed: [Does AI Generate Accessible Android Apps?]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-11-25T03:18:59.610000Z Content type: article Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Artificial Intelligence](), [Android]() Tags: [accessibility](), [ai](), [ai-tools](), [android]() ### AI overview This article summarizes tests of Android apps generated with Gemini, Junie, Cursor, and Claude. It reports that every tested tool added redundant content descriptions, while all except Claude failed to add scrollability that became important at larger font sizes. ### Source excerpt 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 rep ## Compose UI Tests for Larger Font Sizes: Scrolling and Text Truncation DevFeed: [Compose UI Tests for Larger Font Sizes: Scrolling and Text Truncation]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-10-31T05:06:57.487000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Compose](), [Accessibility](), [Testing](), [Android](), [ui]() Tags: [accessibility](), [android](), [compose](), [tests](), [ui]() ### AI overview A tutorial on writing Android Compose UI tests for accessibility issues caused by larger font sizes. It demonstrates testing whether content scrolls when needed and whether truncated text can be expanded, using a 200% font scale in the test setup. ### Source excerpt 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 ## Wear OS Accessibility Considerations DevFeed: [Wear OS Accessibility Considerations]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-09-06T07:38:33.218000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Android](), [Compose](), [screen](), [Font]() Tags: [accessibility](), [accessible](), [android](), [compose](), [screen]() ### AI overview A discussion of accessibility considerations for Wear OS apps, focusing on how the small form factor differs from phones and tablets. It explains why TalkBack remains a major focus and highlights built-in components, content descriptions, and list behavior. ### Source excerpt Lately, I've been learning about Wear OS development. As I'm also an accessibility specialist, I've naturally also been looking into the accessibility aspects of Wear OS. The small form factor impacts many things typically associated with accessibility. Not everything can work, or is working, the same as with, for example, phones and tablets. It's been fascinating to dive into the topic and learn more about it. In this blog post, I'll give pointers on Wear OS accessibility and share some of the learnings I've had. For transparency, I must note that my perspective is very Pixel-y, as I have a Pixel Watch 3. Let's dive in! Screen Reader Seems to Be on the Main Stage Most of the available documentation about Wear OS accessibility focuses on making apps accessible for screen reader users. The Accessibility on Wear OS-page first mentions font size and rotary input (which we'll discuss later in this blog post), and then proceeds to optimizing apps for TalkBack (the built-in screen reader), which takes up most of the page. And I'm not surprised - that's the case with most of the accessibility documentation for any platform. And don't get me wrong, screen reader accessibility is important, but there's often this misconception that that's all accessibility is. However, it's not just screen readers - there are many other sides to it. In Wear OS's case, however, I think that it might even be warranted to keep the screen reader accessibility on the main stage of the accessibility documentation. The reason for that is that many other things work out of the box. I mean, of course, there are ways to make them not work, but unless you're misusing components, most of the things work. The "Optimize your app for Talkback" section in the forementioned documentation comes down to basics: Use built-in components, as they already have the semantics, accessibility actions, focus handling, etc. included. Add content descriptions to tiles and complications. Tip! If you're wondering what to w ## Does Claude Generate Accessible Apps? DevFeed: [Does Claude Generate Accessible Apps?]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-08-22T10:08:28.310000Z Content type: article Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Claude](), [Testing](), [Android](), [Jetpack Compose](), [Android Studio]() Tags: [accessibility](), [android](), [blog-post](), [claude](), [jetpack-compose](), [testing]() ### AI overview This article documents a test of Claude's ability to generate accessible Android user interfaces. The author generated an Android app with Claude, moved the code into an Android Studio project using Jetpack Compose, and tested it with accessibility tools, settings, and assistive technologies. The supplied excerpt describes the test setup and prompt but does not include the final accessibility findings. ### Source excerpt 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 siz ## 10 Tips to Make Your Blog Posts More Accessible DevFeed: [10 Tips to Make Your Blog Posts More Accessible]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-07-18T11:44:00.644000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [alt text](), [Code](), [HTML](), [Markdown]() Tags: [accessibility](), [accessible](), [alt-text](), [blog-post](), [code](), [tips](), [writing]() ### AI overview This article shares accessibility tips for blog authors, emphasizing that technical content should support developers with disabilities. It recommends presenting code as text in code blocks instead of images and providing text alternatives for graphics. ### Source excerpt Sometimes I encounter this weird idea that developers don't need accessibility at all. Some people seem to believe that our development tools and resources don't need to be accessible, because accessibility is just something to do with the end users of our services. If you're one of those people, you know, disabled software developers exist. You're reading text from one right now, and I know many developers with disabilities. Yes, even blind developers. I've been writing a blog since 2019, and as an accessibility specialist, I've tried to make my blog posts as accessible as possible. In this blog post, I decided to share some of the things I've learned over the years. So, without further ado, let's get started. Share Code as Text, not as Images If you're writing a technical blog post and sharing some code, always write it as text, never share it as an image. Why? There are multiple reasons. First of all, it's super annoying to copy the code from a blog post if it's an image. The reader would need to type it out, instead of just copying and pasting. At least for me, when I'm sharing code in a blog post, it's meant to be used, and the fastest way is to use copy and paste. Images of code are also an accessibility problem. With an image, there is no way to make the text bigger, change colors for better contrast, or modify the text row length. All of these are things people might need to make the web content more accessible for them. And then there's the text alternative part - if you're sharing an image of text, you should always include the text as text alternative (alt text) for the image. However, even if you include code, the way screen readers interact with alt texts makes it more challenging to use. E.g., navigating within the code is harder because screen readers read the text from the beginning, and it's not really possible to jump from one row to another. So, always put code into a code block as text. Most blogging platforms allow this, and if you have your own ## Understanding Accessibility Focus and Keyboard Focus in Android Compose DevFeed: [Understanding Accessibility Focus and Keyboard Focus in Android Compose]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2026-04-30T03:53:43.294000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Compose](), [Android](), [User interface design]() Tags: [accessibility](), [android](), [compose](), [interaction](), [keyboard](), [screen]() ### AI overview This tutorial explains the difference between accessibility focus used by screen readers such as TalkBack and keyboard focus used with keyboards, D-pads, and similar devices in Android Compose. It describes which elements can receive each type of focus and gives guidance on making touch-interactive components focusable. ### Source excerpt 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 in ## Does Cursor Generate Accessible Android Apps? DevFeed: [Does Cursor Generate Accessible Android Apps?]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-06-16T03:56:47.185000Z Content type: article Language: en Sources: [Eevis Blog]() Topics: [cursor](), [Accessibility](), [android-development](), [Testing](), [Android Studio](), [Artificial Intelligence]() Tags: [accessibility](), [ai](), [android](), [android-development](), [android-studio](), [cursor](), [testing]() ### AI overview The article evaluates Cursor for generating an Android app and testing its accessibility. In one test, the author used Android Studio and Cursor to build a yarn and knitting-needle tracking app, encountering missing dependencies, improper navigation, and non-existent parameters in Composable functions. The author preferred Gemini and Junie for Android development based on this experience. ### Source excerpt 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 indivi ## Does Junie Create Accessible Android Apps? DevFeed: [Does Junie Create Accessible Android Apps?]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-06-10T04:54:16.242000Z Content type: opinion Language: en Sources: [Eevis Blog]() Topics: [junie](), [Accessibility](), [Artificial Intelligence](), [Android](), [Testing](), [IntelliJ IDEA]() Tags: [accessibility-testing](), [ai](), [android](), [android-studio](), [junie]() ### AI overview The article reports on two rounds of testing Junie, JetBrains' coding agent, by generating Android apps and evaluating their accessibility. It also discusses Junie's structured workflow, unnecessary library additions, a KSP version issue, and differences between its Early Access and generally available versions. ### Source excerpt 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 b ## The Accessibility Problems Caused by Incorrect Text Truncation in Android Apps DevFeed: [The Accessibility Problems Caused by Incorrect Text Truncation in Android Apps]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-04-26T07:31:38.151000Z Content type: article Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Android](), [User interface design](), [Font](), [Large Screen]() Tags: [accessibility](), [android](), [cognitive-load](), [text](), [users]() ### AI overview The article examines how Android apps truncate text with ellipses when it does not fit, often without a way to expand the hidden text. It argues that this can prevent users, especially those using larger font sizes or smaller displays, from accessing important labels and context. ### Source excerpt 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 " ## Does Gemini Generate Accessible Android Apps? DevFeed: [Does Gemini Generate Accessible Android Apps?]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-06-16T03:47:24.416000Z Content type: opinion Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Artificial Intelligence](), [Testing](), [Android](), [Android Studio](), [ui](), [screen](), [prompt]() Tags: [accessibility](), [ai](), [ai-assistants](), [android-studio](), [code](), [prompt](), [screen](), [test](), [testing](), [ui]() ### AI overview This article begins a series testing whether AI assistants can generate accessible Android application code. It examines Gemini through Android Studio by generating UI screens for an app that tracks yarn and knitting needles, with accessibility as the central evaluation concern. ### Source excerpt 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 detail ## Echoes of the Past - Tech is Still Not Equal for All DevFeed: [Echoes of the Past - Tech is Still Not Equal for All]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-06-11T04:16:25.278000Z Content type: opinion Language: en Sources: [Eevis Blog]() Topics: [Development]() Tags: [blog-post](), [dev](), [tech](), [video]() ### AI overview The author continues a personal account of being a member of a gender minority in tech, discussing changing social conditions, the importance of the We Coded campaign, and hostile or sexualized comments received on related blog posts. ### Source excerpt 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 ## Making basicMarquee-Modifier More Accessible DevFeed: [Making basicMarquee-Modifier More Accessible]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-02-20T10:38:55.771000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Android](), [marquee](), [Code]() Tags: [accessibility](), [accessible](), [android](), [animations](), [code](), [how-to](), [marquee](), [technical]() ### AI overview This tutorial explains how to make Android's basicMarquee modifier respect the system "Remove animations" accessibility setting. It proposes reading the setting and exposing its value through composition locals to conditionally enable the marquee animation. ### Source excerpt 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: Android, Animations and Reduced Motion You Make My Head Spin - Reducing the Motion on Web 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 Animat ## Be Mine and Add Interaction with Compose and Canvas DevFeed: [Be Mine and Add Interaction with Compose and Canvas]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-06-11T04:08:03.778000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Canvas](), [Compose](), [compose-multiplatform](), [SVG](), [Figma]() Tags: [canvas](), [compose](), [creative-coding](), [figma](), [interaction](), [svg]() ### AI overview This tutorial shows how to use Compose and Canvas to draw interactive heart-shaped candies. It explains detecting pointer input gestures so the candies scale larger when touched, and builds on earlier work using SVG path strings with Compose Multiplatform. ### Source excerpt 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, which returns the two path strings with the color with different opacity ## January 2025: A Monthly Reflection on Personal Challenges and Positive Moments DevFeed: [January 2025: A Monthly Reflection on Personal Challenges and Positive Moments]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-06-11T04:18:31.535000Z Content type: opinion Language: en Sources: [Eevis Blog]() Topics: [Development](), [compose-multiplatform]() Tags: [article](), [blog-post](), [content](), [gender]() ### AI overview A personal reflection on January 2025, reviewing hopes and fears recorded in two bingo cards. The author describes a positive milestone involving a Compose Multiplatform blog post, alongside experiences of gender stereotypes, biased AI-generated content, and unequal treatment in developer discussions. ### Source excerpt 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 reali ## Using SVGs on Canvas with Compose Multiplatform DevFeed: [Using SVGs on Canvas with Compose Multiplatform]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-06-11T04:09:33.844000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [compose-multiplatform](), [Canvas](), [SVG](), [Compose](), [creative technology](), [Figma]() Tags: [canvas](), [compose](), [compose-multiplatform](), [creative-coding](), [developer-tools](), [figma](), [svg]() ### AI overview This tutorial explains how to use SVG path data to draw SVG components on Canvas in a Compose Multiplatform application. It covers extracting path data from SVG source, storing paths with color information, and preparing them for rendering on Android and iOS. ### Source excerpt 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. I ## 2025, Please, Be Gentle DevFeed: [2025, Please, Be Gentle]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2025-06-11T04:18:26.653000Z Content type: opinion Language: en Sources: [Eevis Blog]() Topics: [Development](), [Kotlin]() Tags: [2025](), [article](), [kotlin]() ### AI overview A personal reflection on hopes and predictions for 2025, presented as two bingo cards. The author describes positive goals involving work, technology, learning, representation, and personal life, alongside anticipated negative experiences related to being a minority in tech. ### Source excerpt 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+ positi ## Year in Review - 2024 Edition DevFeed: [Year in Review - 2024 Edition]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2024-12-31T09:23:43.816000Z Content type: article Language: en Sources: [Eevis Blog]() Topics: [compose-multiplatform](), [Google](), [Android](), [Accessibility](), [Mobile](), [iOS]() Tags: [accessibility](), [android](), [compose](), [compose-multiplatform](), [google](), [ios](), [review](), [year-in-review]() ### AI overview A personal review of 2024 covering the author's Google Developer Expert recognition, master's thesis and graduation, release of the Neule.art Android app using Compose Multiplatform, and public speaking activities. ### Source excerpt 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: Year in Review - 2021 Edition Year in Review - 2022 Edition Year in Review - 2023 Edition 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 [Next page]()