Accessible Color Generator: Mobile App Design Guide

Use an accessible color generator workflow to audit one mobile screen: set body text to at least 4.5:1 contrast and UI components to 3:1, make every iOS target at least 44 × 44 pt and Android target at least 48 × 48 dp, add VoiceOver and TalkBack labels to icon-only controls, test the layout at 200% text size, and remove nonessential parallax when reduced motion is enabled. Check the screen on a device with a screen reader, not only in a design canvas.

Key takeaways

• •WCAG 2.2 AA requires 4.5:1 contrast for normal text and 3:1 for large text.
• •WCAG 2.2 AA requires 3:1 contrast for active UI components and meaningful graphical objects.
• •Apple recommends a minimum 44 × 44 pt hit target for interactive controls.
• •Material Design uses a 48 × 48 dp minimum touch target.
• •Icon-only controls need a programmatic label for VoiceOver and TalkBack users to identify them.

This guide is for mobile UI/UX designers, founders, and engineers who can already create iOS and Android screen layouts.

Time: 30 minutes · You'll need: A representative iOS or Android screen in your design file, An iPhone with VoiceOver or Android device with TalkBack, A contrast-ratio calculator or floow.design Contrast Checker, iOS Accessibility settings or Android Accessibility settings, A build or prototype with tappable controls

What's on this page

1. •Choose one task-critical mobile screen
2. •Check contrast with an accessible color generator
3. •Size targets for mobile accessibility design
4. •Add labels for VoiceOver and TalkBack
5. •Test 200% text and reduced motion
6. •Reference table

• •Common mistakes
• •FAQs

Run an accessible color generator screen audit

1. Choose one task-critical mobile screen

Pick a screen with a complete user task, such as a checkout confirmation, medication reminder, or bank-transfer review. Include a primary action, a secondary action, at least one icon-only control, body copy, a form field or selection control, and an error or status state. A sparse marketing-style welcome screen will not expose the failures users meet in the product.

Duplicate the screen into an audit frame. Mark each interactive element with its platform target size: 44 × 44 pt for iOS and 48 × 48 dp for Android. Apple’s Human Interface Guidelines treats 44 × 44 pt as the minimum tappable area; Material Design specifies a 48 × 48 dp touch target. The visible glyph can be smaller. Expand the invisible hit area around a 20 pt close icon or 24 dp overflow icon rather than enlarging the icon until it dominates the layout.

The result is one annotated screen where every control has a measurable touch area and a defined task role.

Tip: Keep adjacent touch targets separate even when their hit areas meet; overlapping targets create unpredictable tap results.

2. Check contrast with an accessible color generator

List every foreground/background pair that carries meaning: body text, button labels, input borders, selected states, error text, icons, and charts. For WCAG 2.2 AA, normal body text needs 4.5:1 contrast; large text needs 3:1. WCAG defines large text as at least 24 CSS px normal weight or 18.66 CSS px bold. Interactive UI components and meaningful graphical objects also need 3:1 against adjacent colours.

Run each pair through an accessible color generator or contrast checker. The manual method is to convert each sRGB colour to relative luminance, identify the lighter value as L1 and darker value as L2, then calculate (L1 + 0.05) / (L2 + 0.05). Record the ratio beside the component. Do not accept a passing button label while its outlined border, error icon, or disabled-versus-enabled state remains indistinguishable.

Then preview the screen with a colour-blind simulation. Do not use red alone for an error state; pair it with an error icon, text such as “Card declined,” or both.

Tip: Check text over image scrims at the lightest and busiest part of the image, not only over the art-directed focal point.

3. Size targets for mobile accessibility design

Measure the tappable bounds, not the visible artwork. On iOS, give every compact action a 44 × 44 pt activation area. On Android, give every action a 48 × 48 dp touch target. Apply this to back buttons, close controls, overflow menus, inline remove buttons, password-visibility icons, and trailing icons inside text fields.

A common failure is a 16 pt or 24 dp glyph placed in a layout cell that is only as large as the glyph. Keep the glyph visually aligned, then add transparent padding within the component bounds. For two controls in a trailing row, such as share and more, use two distinct target frames rather than one wide target with two icons. The user must be able to predict which action receives the tap.

Test the built screen with one hand. If a control near the bottom edge competes with the system gesture area or requires repeated precision taps, move it, enlarge its target, or put the action in a bottom sheet.

Tip: Do not make destructive and non-destructive icons adjacent with identical visual weight; target size fixes accuracy, not accidental intent.

4. Add labels for VoiceOver and TalkBack

Give every icon-only control a concise programmatic name that states its action. “Close,” “Search,” “Show password,” “Delete photo,” and “More options” work; “X,” “magnifying glass,” and “icon button” do not. VoiceOver reads the iOS accessibility label, and TalkBack reads the Android content description or equivalent semantics. The visible icon is not a reliable substitute for either label.

Run VoiceOver on iOS or TalkBack on Android through the screen in swipe order. Each swipe should announce the control’s name, role, and relevant value or state. A toggle should expose whether it is on or off. A selected tab should expose its selected state. A text field should announce its label, current value if present, and error message when invalid.

Hide decorative artwork from the accessibility tree. If a decorative chevron sits beside a labelled row, the row should announce one actionable item, not “Profile, button, chevron.” Check that the screen-reader focus order follows the visual reading and task order.

Tip: Put the outcome in the label for ambiguous actions: use “Remove saved address” instead of “Remove” when several removable items appear on screen.

5. Test 200% text and reduced motion

Increase text to 200% and inspect every state, including translated strings and error messages. On Android, test with a font scale of 2.0. On iOS, test Dynamic Type with an Accessibility text size at or beyond the equivalent layout stress point; iOS text can grow beyond 200%, so do not impose a fixed-height cap. Let text wrap, allow cards and buttons to grow vertically, and preserve labels rather than truncating a primary action.

Then enable iOS Reduce Motion and the Android system animation-reduction setting available on the test device. Remove nonessential parallax, large zoom transitions, auto-advancing carousels, and motion that shifts the whole screen. Parallax creates a vestibular cost because the visual field appears to move independently of the user’s physical movement. Keep functional feedback, such as a selected-state change, but express it with a colour, label, opacity, or short non-spatial transition.

For web content embedded in an app, respect the CSS prefers-reduced-motion media feature. The reduced-motion version must be designed, not treated as a broken animation.

Tip: A 200% text test often reveals that a fixed-height primary button should become a minimum-height button with vertical padding.

Reference table

Mobile accessibility audit thresholds

Do it with the free Contrast Checker

Test any pair against WCAG 2 and the newer APCA method, with a colour-blind check and the nearest passing colours.

Open the Contrast Checker → — free, no sign-up.

Common mistakes

Passing a button label while its outline or selected state has insufficient contrast.

Check every meaningful visual boundary separately. WCAG 2.2 AA requires 3:1 for the component boundary or state indicator when it is needed to identify the control.

Treating a visible tooltip as the label for an icon-only button.

Add an accessibility label in the native component semantics. Tooltips are not consistently available to VoiceOver or TalkBack users.

Using fixed-height cards and buttons at large text sizes.

Use minimum heights and vertical padding. Allow labels, errors, and multi-line button text to increase component height at 200% text.

Replacing every animation with no feedback at all.

Keep essential state feedback, but use non-spatial changes such as colour, opacity, text, or an immediate state update when reduced motion is enabled.

Frequently asked questions

What contrast ratio should a mobile app use for WCAG AA?

A WCAG 2.2 AA mobile app needs 4.5:1 contrast for normal text and 3:1 for large text, UI components, and meaningful graphical objects. Large text is at least 24 CSS px at normal weight or 18.66 CSS px when bold. Check labels, borders, icons, errors, and selected states rather than body text alone.

What is the minimum touch target size on iPhone and Android?

Use at least 44 × 44 pt for iOS controls and 48 × 48 dp for Android touch targets. These dimensions describe the interactive hit area, not the visible icon size. A 20 pt iOS icon or 24 dp Android icon can remain visually compact inside a larger transparent component frame.

Do icon-only buttons need accessibility labels in an accessible app design?

Yes, every icon-only control needs a programmatic action label for VoiceOver and TalkBack. Name the action rather than the glyph, such as “Search,” “Close,” or “Delete photo.” Also expose relevant state, including whether a switch is on or off or a tab is selected.

How do I test Dynamic Type and Android font scaling?

Test the screen at 200% text size, using Android font scale 2.0 and an iOS Dynamic Type accessibility size that stresses the same layout. Text must be able to wrap and controls must grow vertically without clipped labels, hidden errors, or unreachable actions. iOS can exceed 200%, so fixed-height components remain risky.

Should mobile apps support prefers-reduced-motion?

Mobile apps should provide a reduced-motion experience by honoring iOS Reduce Motion, Android animation-reduction settings, and prefers-reduced-motion in embedded web content. Remove nonessential parallax and large spatial transitions because they can cause vestibular discomfort. Preserve essential feedback through state, colour, labels, or non-spatial changes.

Where this leaves you

A credible accessibility pass is not a palette review. It checks whether users can read the screen at WCAG 2.2 AA contrast, tap each action within its platform target, understand controls through VoiceOver or TalkBack, complete the task with enlarged text, and avoid unnecessary spatial motion. One passing screen also gives the product team reusable component rules: target frames, semantic labels, flexible heights, and reduced-motion variants. Run the selected task screen through the contrast calculations first, then document every failing pair and component as an implementation ticket.

---

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

---

Related

• •Color Picker from Image — Pull a palette out of any image, assign it to screen roles, and export it as tokens or native code.
• •Colour Blindness Simulator — See your screens through every type of colour vision deficiency at once, and download the whole comparison.
• •Text to UI: Design App Screens From Prompts — Use text to UI prompts that produce usable iOS and Android first screens, with real copy,
• •Figma to Code: Export AI Mobile Designs — Figma to code starts with editable Figma layers. Export AI-generated mobile screens with A
• •How AI Is Making Mobile App Design Accessible to Everyone in 2026 — AI design tools have removed the barrier between having a mobile app idea and making it vi

Sources

• •W3C Web Content Accessibility Guidelines (WCAG) 2.2
• •Apple Human Interface Guidelines: Accessibility
• •Apple Human Interface Guidelines: Layout
• •Material Design 3: Accessibility
• •Android Developers: Accessibility