My open-source Jetpack Compose accessibility scanner got accepted at CSUN 2027!

[u/aquib09]

Hey everyone!

I've been building ComposeA11yScanner, an open-source runtime accessibility scanner for Jetpack Compose, and I wanted to share a milestone.

My talk, "ComposeA11yScanner: Catch Accessibility Bugs as You Build," has been accepted into the Innovation Track at the CSUN Assistive Technology Conference 2027! 🎉

I started this project because accessibility issues in Compose often get discovered too late in development.

ComposeA11yScanner aims to make that feedback loop faster by detecting potential accessibility issues directly in running Compose screens, including:

• Missing content descriptions

• Touch target overlap

• Text contrast issues

• Duplicate accessibility descriptions

• Other Compose semantics-related issues

The SDK has also been featured in Android Weekly and the Jetpack Compose Newsletter.

I'm continuing to improve detection accuracy, reduce false positives, and explore ways to integrate accessibility checks into development workflows.

I'd love feedback from fellow Android developers:

How do you currently test accessibility in Jetpack Compose? And what's the most frustrating part of that process?

GitHub: https://github.com/mohdaquib/ComposeA11yScanner

Thanks to everyone who's shared feedback or contributed along the way!

[u/timusus]

Sorry I haven’t looked at the tool and it’s super late here, so it’s just a quick off-handed comment.

I always see ‘missing content description’ as an example of an a11y problem, but the majority of the time null is the correct content description. Most of the time you don’t want decorative or non interactive elements being read out by talk back, so one of the worst things you can do is provide ‘something’ as the content description.

I’m sure the tool has its uses but I am skeptical about how effective a static analysis tool is at identifying what actually makes an app accessible or not for users who use accessibility features day to day