vanished
A control present at the default text size is gone at the largest one. The user cannot reach it.
Does your app survive the largest font size?
Android and iOS both let people scale text to twice its default size. Real users turn it on. Almost nobody tests it, because the only way to see the damage has been to enable it by hand and scroll through every screen. We built the check that does it from two captures, and ran it on four open-source apps.
All four passed the large-font check.
That is the honest headline, and it is worth publishing precisely because it is not the dramatic one. These are well-maintained projects, and a check that screamed at all of them would be telling you about itself rather than about the apps.
| App | Large-font (1.0 → 2.0) | Single screen | Notes |
|---|---|---|---|
Wikipedia org.wikipedia | clean | clean | Body copy grew from 252px to 480px tall and the layout absorbed it. |
NewPipe org.schabi.newpipe | clean | clean | Its dialog restacks the action buttons vertically rather than letting them overflow. |
Tusky com.keylesspalace.tusky | clean | 2 serious | A tappable text link measures 27.4dp tall against a 48dp minimum. |
AntennaPod de.danoeh.antennapod | clean | 1 serious, 1 unverified | The one serious finding is a framework default, not app code — see below. |
Pixel 7 emulator · 1080×2400 · density 2.625 · API 36 · font_scale 1.0 vs 2.0 · captured 1 September 2026
Three things that belong next to those numbers
- One screen per app. We audited whatever each app opens to on first launch, not its full flows. A real audit drives the app through its screens; this is a sample, and a small one.
- One of the findings is a framework default, not app code. A 40×48dp More optionsbutton appears identically in Tusky and AntennaPod because it is the standard Material toolbar overflow control. Neither project wrote it. Tusky's 27.4dp text link is app-authored and is a genuine finding.
- The tool was wrong before it was right. Its first run on NewPipe reported three dialog buttons as unreachable. They were not — the dialog restacks them vertically and Android reassigns every sibling index, which our matching mistook for disappearance. We found it by checking the claim against the raw capture before publishing it. The fix, and five other bugs that only real captures exposed, are written up in the repository.
Capture the same screen twice. Report what got worse.
Elements are matched across the two captures by identity, not by position — an element that moved is still the same element, and movement is the measurement. Only regressions are reported: a defect present in both captures is a normal layout bug, not a large-font one.
pushed-offscreen
A control that fitted the display no longer does, reported with both positions.
new-overlap
Larger text makes two tap targets collide, so z-order decides which one receives the tap.
shrunk
A text box gets smaller while its text gets bigger. The content needs more room and is being given less — this is where truncation comes from.
capture and compare
# two captures, five seconds apart adb shell settings put system font_scale 1.0 adb shell uiautomator dump /sdcard/base.xml adb shell settings put system font_scale 2.0 adb shell uiautomator dump /sdcard/large.xml $ lv-ux compare base.xml large.xml --density 2.625 # iOS is the same idea xcrun simctl ui booted content_size accessibility-extra-extra-extra-large
Every existing tool looks at one capture.
Accessibility Scanner and the Accessibility Test Framework are good, and they already check contrast and tap-target size. But they examine a screen as it is, once. A layout that breaks only at 200% text is not a property of any single capture — it is a difference between two, which is why a single-capture tool structurally cannot see it.
On iOS the gap is wider still. Dynamic Type at accessibility sizes breaks layouts constantly, and there is no equivalent of Accessibility Scanner to lean on at all.
We'll run this on your app, free.
Send an APK or a TestFlight build and the screens you care about. You get the findings and the raw captures back, whatever they say — including “nothing found”, which is what happened to all four apps above on the large-font check. No SDK, no source code, nothing installed in your app.
Findings above are reproducible from the capture parameters given and describe one screen of each app on the date shown. They are not a general assessment of these projects, all of which are actively maintained and passed the check this page is about. The audit is geometry-only: it reads the accessibility hierarchy, not pixels, so it cannot judge contrast or confirm visual clipping.