The thing most developers only notice at rejection
You've spent four months on this app. The code is clean, the onboarding is smooth, the icon is perfect. You hit submit, settle in for the usual two-day wait, and then the rejection email lands. Not about your code. Not about your permissions. About a screenshot.
Specifically: a screenshot that fails accessibility requirements.
This trips people up more than it should, because screenshots feel like marketing collateral, not engineering deliverables. They're not. To the review systems, they're part of the product, and they get checked like one.
What reviewers are actually checking
Both Apple and Google layer their screenshot review: automated checks run first, every single time, and human review follows.
For the App Store, the automated system is hunting for a few concrete things. Text contrast ratios are the big one. The WCAG standard Apple references requires a minimum 4.5:1 contrast ratio for normal-sized text against its background. Put white text on a pale yellow card and you'll probably fail. Put dark grey text on a near-black background and you might fail going the other direction. The system measures actual pixel values, not your intentions.
Google Play's pre-launch report, generated through Firebase Test Lab, runs a similar automated pass on your screenshots and app previews. It flags low-contrast text, checks that text isn't obscured by device-frame overlays, and notes whether on-screen UI elements clear the 3:1 ratio required for non-text elements: icons, dividers, interactive controls shown in context.
Beyond contrast, both platforms check text size legibility. Apple pushes hard on Dynamic Type support in the live app, and that philosophy bleeds into screenshot expectations. If your screenshot shows text that would be unreadable at 12pt or smaller without zooming, it can trigger a reviewer flag.
Neither store publicly documents every automated check. But the pattern from developer forums and rejection notices is consistent: contrast, text size, and overlay legibility are the three pillars.
A worked scenario that illustrates the gap
Take two developers, Maya and Tariq, submitting fitness-tracking apps in the same week.
Maya uses a screenshot template she bought from a design marketplace. It looks gorgeous: soft gradient backgrounds, thin white typography at roughly 11pt equivalent, a translucent device frame layered on top. Her contrast ratio for the headline text clocks in around 2.8:1. The automated check fails it. Her submission is held.
Tariq, working with a smaller budget, built his screenshots in Figma from scratch. Solid dark navy backgrounds. White text at 16pt equivalent, giving him a contrast ratio just above 5:1. Opaque device frames, not translucent. He passes the automated check and moves to human review without a hitch.
Maya's screenshots look more polished to a sighted designer. The accessibility check doesn't care about polish. A 2.8:1 ratio means a lot of people with low vision simply cannot read her text, and the system is built to catch exactly that. Polished and unreadable is still unreadable.
What people often misread about this process
The common assumption is that screenshot accessibility review is a soft pass, a checkbox Apple and Google tick to satisfy regulators without actually enforcing anything.
That's wrong.
Apple tightened enforcement around the same time it introduced accessibility metadata fields prompting developers to describe their app's accessibility features. The two moves came from the same internal push. Human reviewers now have explicit guidance to flag screenshots where text contrast fails WCAG AA, and the rejection reasons appear in the developer console with enough specificity to act on. This isn't a bureaucratic formality you can charm your way past.
Google's approach uses a different lever. The pre-launch report gives you a detailed breakdown before you formally submit, so it isn't a blunt rejection gate in the same way. But a poor accessibility score in that report directly affects your app's ranking signals in Play's quality tier system. You can technically ship with a failing screenshot, but your visibility takes a measurable hit. Same outcome, quieter mechanism.
Here's the part that almost nobody gets right: alt text for screenshots. Both platforms let developers submit alt text descriptions for their store screenshots. Most don't bother. For sighted users browsing the store, it's invisible. For a blind user relying on a screen reader to understand what an app does before downloading it, that alt text is the entire pitch. It isn't a hard rejection gate yet, but it's part of the accessibility rubric that human reviewers score, and Apple has begun requesting it during review for apps that declare accessibility support in their metadata. Leaving it blank is leaving points on the table, and it signals to reviewers that accessibility was an afterthought rather than a design consideration.
Getting your screenshots to pass cleanly
The practical fix is less complicated than developers fear once you know what the system is measuring.
Run your screenshots through a contrast checker before submission. WebAIM's contrast checker is free and takes thirty seconds per image. Aim for 4.5:1 on all text. Don't assume your design tool's colour picker is accurate enough, because it isn't: measure the actual rendered output, not the hex values in your layers panel.
Keep text at a minimum 16pt equivalent in your screenshot canvas. Below that, even passing contrast ratios struggle under real viewing conditions on a phone screen.
Avoid translucent overlays on text. A frosted-glass card looks beautiful in Figma and behaves like a contrast ratio wrecking ball when the gradient behind it shifts across the image.
Write the alt text. Ten minutes per screenshot, and it's the most underused signal in the entire submission process. Describe what the screenshot shows functionally, not aesthetically. Not "beautiful dashboard view" but "dashboard showing weekly step count at 8,432, goal progress bar at 64%, and three recent activity cards." That's the difference between useful and decorative.
If your headline text is sitting above 4.5:1 and your UI elements clear 3:1, you're in solid shape. The automated check passes you through, and the human reviewer has nothing obvious to catch.
The enforcement is uneven, the documentation is thinner than it should be, and the whole system is more patchwork than either platform would admit. But the underlying ask is reasonable. If someone can't read your screenshot, they can't know whether your app is worth their time. That's not a technicality. That's communication failing before it even starts.