@eevis.codes
Mobile Accessibility Specialist, Android GDE, Senior Android Developer, Blogger, Speaker from Finland 🇫🇮 They/She Website: https://eevis.codes YouTube: https://www.youtube.com/@eeviscode Inclusive Android Apps-newsletter: https://eevis.codes/newsletter
Following up on my last post about building an item previewer in Jetpack Compose, I’ve published Part 2: Adding navigation support, in which I look into keyboard, screen reader, and voice access navigation considerations for the item previewer.
eevis.codes/blog/2026-02...
#A11y #AndroidDev
Eeva-Jonna @eevis.codes Panula on kaikkien aikojen ensimmäinen Mimmit koodaa -palkinnon voittaja.
Tänä vuonna ympyrä sulkeutuu, kun hän on mukana tuomaristossa valitsemassa tulevaa voittajaa.
Kysyimme Eeviksen kuulumisia, lue lisää ohesta. ☺️
#MimmitKoodaa
I released jetc.dev Newsletter Issue #302! Compose patch release and alpha release! Compose Multiplatform patch release! Bottom sheets! @eevis.codes on colors and accessibility! And... can we work with Glance?!? jetc.dev/issues/302 #JetpackCompose #AndroidDev
Issue #3 of Inclusive Android Apps is live! 🚀
This one covers the problem of color-only indicators: why relying on color alone excludes users, with code examples for fixing the issue with text, icons, and/or patterns.
Read it: buttondown.com/inclusive-an...
#AndroidDev #InclusiveAndroidApps
Issue #3 of Inclusive Android Apps drops Tuesday! 📬
This one's about color-only indicators: why relying on color alone excludes users, and how to fix it with text, icons, and patterns. Code included.
Want to get it to your inbox? Subscribe here: eevis.codes/newsletter
#AndroidDev
OK, I released jetc.dev Newsletter Issue #298! Compose Multiplatform 1.10! 🎉 Compose Hot Reload! @eevis.codes on bottom nav bar accessibility! Responsive tab rows! And... a no-Chromium desktop WebView?!? jetc.dev/issues/298 #JetpackCompose #AndroidDev
ScanAgile 26. The agile accessibility mindset: Progress over perfection. Tue 17th of March, 2026 1:30 PM - Helsinki, Finland. Eeva-Jonna Panula. scan-agile.org
Looking back, I've mostly spoken at events abroad and in Turku, so I'm happy to share that I will be speaking at #ScanAgile26 in Helsinki in March!
This time, my POV on accessibility is not the most technical, but how teams should value progress over perfection when fixing accessibility issues.
Font scaling is important, but what if UI elements can't scale?
I’m borrowing a concept from iOS to build an item previewer in Jetpack Compose. It ensures small icons/labels stay accessible via item previews.
Read more: eevis.codes/blog/2026-01...
#A11y #AndroidDev
Issue #2 of Inclusive Android Apps is live! 🚀
This one tackles how to build gender forms that don't force binary choices. The practical solutions include multiple options, custom fields, and opt-out choices.
Read it: buttondown.com/inclusive-an...
#AndroidDev #InclusiveAndroidApps
Issue #2 of Inclusive Android Apps drops Tuesday 📬
This one's about gender selection in forms, why binary male/female choices exclude users, and how to build forms that actually work for everyone, with practical code examples.
Want it in your inbox? Subscribe: eevis.codes/newsletter/
#AndroidDev
Otherwise, there are two tab stops in the tab order, which can make assistive tech navigation harder, or in some cases, unusable.
#AndroidDev #Android #AndroidAccessibility
Compose-tip: When building reusable components, avoid unintentional nested clickable/selectable/toggleable elements, such as a `Column` with `clickable` that wraps a `Button`.
For gesture navigation, if not testing with it, there might be interactive components that interfere with the gestures - for example, a slider or range slider, or a component with swipe-to-dismiss actions.
#AndroidDev #Android #AndroidAccessibility
Compose (or Android) tip: Test your app with both button and gesture navigation to avoid breaking the user experience.
When not testing with button navigation, it's easy to forget to leave enough padding for the buttons, which, in turn, can make some elements unusable at the bottom of the screen.
First issue of Inclusive Android Apps is live! 🚀
This one's about how Row layouts break when users increase text size - and why FlowRow is a good fix.
Read it: buttondown.com/inclusive-an...
#AndroidDev #AndroidAccessibility #a11y #InclusiveAndroidApps
I also write a bit about why I'm starting the newsletter, and what to expect from it. If you're interested, here's the link:
eevis.codes/blog/2025-12...
#Android #AndroidDev #AndroidAccessibility #a11y #InclusiveAndroidApps
Less than a week until the first issue of the Inclusive Android Apps newsletter!
The response to the newsletter has been amazing, and I am so excited about it. I already have so many different ideas for the upcoming issues, and just can't wait to launch them! Did I already say I'm excited?
Also, remember to pass in the role (Role.Switch, Role.Checkbox, Role.RadioButton). Using the correct modifier and role ensures, that the semantics are communicated correctly to assistive technologies.
#AndroidDev #Android #AndroidAccessibility
Compose tip: When you create either custom toggleable and selectable components (like switches, checkboxes, or radio inputs), or when you associate said native components with their labels and wrap them with, for example, a `Row`, use `toggleable` and `selectable` modifiers instead of `clickable`.
That's an interesting idea. I think that for screen readers on Android, the best one resource would be the official Android documentation - the information is a bit scattered, but overall, I feel like it still contains most of things that need to be taken into account in one resource.
Setting a fixed height, especially for components that wrap text, can cause various problems for users who use larger font sizes, such as cutting off text and preventing the component from expanding naturally.
#AndroidDev #Android #AndroidAccessibility
Android and Compose tip: Don't set a fixed height to components unless it's absolutely necessary. And even then, double-check if it is actually required, and test with large font sizes, such as 200%.
I've been testing different AI tools for generating Android apps and running accessibility tests on them, and now I've finally written my wrap-up of those tests.
In short, from an Android accessibility perspective, I don't believe AI will replace developers anytime soon.
Thanks Mike, I really appreciate it!
First issue drops December 9th, subscribe to get it delivered to your inbox: eevis.codes/newsletter
#Android #AndroidDev #AndroidAccessibility #InclusiveDesign
So I'm launching a newsletter about Inclusive Android Apps in December!
Inclusive Android Apps is a monthly newsletter about making Android apps more inclusive. I cover accessibility, LGBTQ+ inclusive design, internationalization, and other considerations for apps to not accidentally exclude users.
But ripple is not just for focus indication, it's also part of the interaction as whole - for example, as feedback from touch input.
The default ripple is so subtle that it's easy to miss, but it's better than nothing.
#Android #AndroidDev #AndroidAccessibility
Another Android accessibility tip: if you have `indication=null` set to your interactive components, it's likely that you're preventing anyone relying physical keyboard or d-pad for navigation.
This is, of course, if you haven't implemented proper focus indicators, which don't include ripples.
This can be either just annoying, or purely painful if every keystroke hurts. And if you do this for components on list, it would mean the same happening in every list item - which can mean a lot of extra tab stops.
Another Compose tip: If you use `clickable`-modifier, or for example, a Button-component, you don't need to add `focusable`-modifier to that component. If you do, the component gets added twice to tab order, meaning users using assistive technology for navigation would focus twice on that component.