# Does AI Generate Accessible Android Apps?

DevFeed: [Does AI Generate Accessible Android Apps?](<https://devfeed.tech/articles/does-ai-generate-accessible-android-apps-38514.md>)

Original publisher: [Read original article](<https://eevis.codes/blog/2025-11-25/does-ai-generate-accessible-android-apps/>)

Author: Eevis Panula

Published: 2025-11-25T03:18:59.610000Z

Content type: article

Language: en

Sources: [Eevis Blog](<https://devfeed.tech/sources/eevis-blog.md>)

Topics: [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [Android](<https://devfeed.tech/topics/android.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [ai](<https://devfeed.tech/tags/ai.md>), [ai-tools](<https://devfeed.tech/tags/ai-tools.md>), [android](<https://devfeed.tech/tags/android.md>)

## 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