Contrast Checker: Meet WCAG in Mobile Apps

Use a contrast checker to list every foreground–background pair on one mobile screen, then test each pair against WCAG 2.2: normal text needs 4.5:1, large text needs 3:1, and controls and meaningful icons need 3:1. Treat text as large only at 18 pt regular or 14 pt bold and above. Start with placeholder and disabled states, which commonly fail, then preserve the brand by changing the text, icon, container, or scrim colour nearest to the existing token rather than replacing the palette.

Key takeaways

•WCAG 2.2 AA requires 4.5:1 contrast for normal-sized text.
•Large text may use 3:1 at 18 pt regular or 14 pt bold.
•WCAG 2.2 SC 1.4.11 requires 3:1 for active UI components and meaningful graphics.
•WCAG AAA raises the normal-text target from 4.5:1 to 7:1.
•Placeholder text and disabled states are frequent contrast audit failures.

This guide is for mobile UI/UX designers, founders, and engineers who already work with iOS and Android screen designs and design tokens.

Time: 25 minutes per screen · You'll need: A screen export or inspectable iOS and Android design file, Design-token values for text, icon, surface, and state colours, A calculator or a WCAG contrast checker, WCAG 2.2 Understanding documents for SC 1.4.3 and SC 1.4.11

What's on this page

•Inventory each visible foreground and surface pair
•Calculate WCAG contrast mobile ratios manually
•Apply accessible color contrast thresholds
•Fix placeholder and disabled-state failures
•Recheck both platforms and document the decision
•Reference table

•Common mistakes
•FAQs

Auditing mobile contrast checker results step by step

1. Inventory each visible foreground and surface pair

Export the screen at its intended device scale, then make a row for every visible pair: body text on a surface, label text on a filled button, icon on a navigation bar, input text on a field, placeholder on a field, error text on its container, and disabled controls. Record the foreground token, background token, font size, font weight, and state.

Do not assess a text token in isolation. onSurface can pass on a plain surface and fail when the same label sits over a tinted card, an image scrim, or a disabled container. Include selected, pressed, error, and disabled variants where the app exposes them. On iOS, inspect screens with larger Dynamic Type sizes; on Android, inspect with increased font size, because wrapping can place text over a different surface or expose clipped labels.

Keep decorative graphics out of this list. Include icons, chart marks, status indicators, and focus or selection boundaries only when users need them to understand or operate the screen.

Tip: Capture the actual composited colour for translucent layers; testing the token before opacity is applied gives the wrong ratio.

2. Calculate WCAG contrast mobile ratios manually

For a manual WCAG 2.2 check, start with two opaque sRGB colours. Convert each 8-bit RGB channel to a value from 0 to 1. For each channel c, use c/12.92 when c ≤ 0.04045; otherwise use ((c + 0.055)/1.055)^2.4. Calculate relative luminance as 0.2126R + 0.7152G + 0.0722B using those linear values.

Put the lighter luminance first, then calculate (L1 + 0.05) / (L2 + 0.05). A black-on-white pair returns 21:1. For a semi-transparent foreground, first composite it over its actual background, then run the calculation on the resulting colour. For text on photography or gradients, test the lowest-contrast area where text can appear, not the average image colour.

Use this ratio for WCAG 2.2 conformance. You can also test the pair with APCA, but APCA does not replace the WCAG 2.2 AA ratio requirements used in this audit.

Tip: A 50% black label is not automatically 50% as bright as black because sRGB values are gamma-encoded.

3. Apply accessible color contrast thresholds

Classify each row before marking it pass or fail. WCAG 2.2 AA Success Criterion 1.4.3 requires 4.5:1 for normal text. It permits 3:1 only for large-scale text: 18 pt regular or 14 pt bold and above. Do not call a 16 pt semibold mobile label “large” unless its actual rendered size and weight meet that definition.

Apply WCAG 2.2 SC 1.4.11 separately. Interactive component boundaries, selected indicators, and graphical objects required to understand the interface need at least 3:1 against adjacent colours. A meaningful outlined text field can therefore fail even when its label passes. Pure decoration has no SC 1.4.11 requirement.

Mark normal text at 7:1 or higher as AAA under SC 1.4.6. Target 7:1 for small, persistent text that users must read quickly, such as medication instructions, financial amounts, transit disruption details, and dense settings descriptions. Do not force 7:1 on every brand accent; it can unnecessarily flatten hierarchy when AA already meets the product’s access needs.

Tip: A 3:1 icon may meet SC 1.4.11 but its adjacent text still needs its own 4.5:1 check.

4. Fix placeholder and disabled-state failures

Audit placeholder text first. A placeholder is still text, so it normally needs 4.5:1 against the input surface when it conveys information a user needs. Prefer a persistent visible field label and make the placeholder an optional format example, such as MM / YY; this reduces the amount of low-emphasis text that must carry meaning.

Audit disabled states next. WCAG contrast criteria exempt inactive user-interface components, but a washed-out disabled control often becomes a practical failure when users cannot tell what is unavailable, why it is unavailable, or how to enable it. Keep the disabled appearance distinct, add an explanatory message when the action is blocked, and never use colour alone to communicate an error or unavailable state.

Fix a failed pair by changing the smallest relevant token. Darken onSurfaceVariant, lighten the filled-button container, add an opaque surface behind text on imagery, or use a stronger icon token. Recalculate every screen that shares that token before publishing the change.

Tip: Do not solve a low-contrast placeholder by removing the label; a placeholder disappears as soon as the user enters text.

5. Recheck both platforms and document the decision

Run the final pair list through the manual formula or a contrast checker. For each result, save the foreground hex value, background hex value, ratio, text classification, criterion, state, and chosen fix. This creates an auditable handoff for iOS and Android rather than a screenshot-only approval.

Test the same semantic tokens in both platform implementations. iOS and Android can apply different elevation, opacity, disabled alpha, image treatment, and system appearance behaviour, so identical token names do not guarantee identical composited colours. Inspect light and dark appearances where the app supports them, and test text over every allowed image or gradient treatment.

For a second reading model, test pairs with the newer APCA method and review a colour-blind simulation. Use the WCAG 2.2 ratio as the pass/fail record for this guide. Use APCA and colour-blind results to find pairs that technically pass but remain weak in context.

Tip: Add contrast requirements to token acceptance criteria so a future theme change cannot silently reintroduce the same failure.

Reference table

WCAG 2.2 contrast thresholds for mobile screens

Content type	Minimum ratio	WCAG 2.2 rule
Normal text	4.5:1	AA, SC 1.4.3
Large text	3:1	18 pt regular or 14 pt bold
UI components and graphics	3:1	SC 1.4.11
Normal text at AAA	7:1	AAA, SC 1.4.6
Maximum possible ratio	21:1	Black on white

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

Testing only body text on the main app background.

Test every composited foreground–background pair, including button labels, field outlines, icons, overlays, and state containers. A shared text token can produce different ratios on different surfaces.

Applying the 3:1 large-text exception to any bold mobile label.

Use 3:1 only when the actual text is at least 18 pt regular or 14 pt bold. Smaller labels require 4.5:1 even when they look visually prominent.

Treating disabled components as automatically acceptable.

Inactive controls are exempt from the contrast criteria, but users still need to understand the unavailable state. Provide a clear reason or enabling condition when the action matters.

Using an average image colour behind text.

Test the lowest-contrast location permitted by the image treatment. Add an opaque or sufficiently dark scrim when imagery can vary.

Frequently asked questions

What contrast ratio does WCAG require for mobile app text?

WCAG 2.2 AA requires 4.5:1 for normal text and 3:1 for large text that is at least 18 pt regular or 14 pt bold. These thresholds apply to rendered foreground and background colours, including the final result of opacity, gradients, and image overlays.

Does WCAG contrast mobile guidance require 3:1 for buttons and icons?

WCAG 2.2 SC 1.4.11 requires 3:1 for visual information needed to identify user-interface components and meaningful graphical objects. Check component boundaries, selected states, icons, and chart marks when users need them to operate or understand the app; decorative graphics are excluded.

Should I target AAA 7:1 for every accessible color contrast pair?

No, WCAG AAA requires 7:1 for normal text, but AA at 4.5:1 is the usual baseline for mobile product work. Reserve 7:1 for small, critical, persistent content such as health instructions, financial figures, or safety information where rapid reading matters.

Do placeholder and disabled text need to meet app accessibility contrast rules?

Placeholder text normally needs the same 4.5:1 text contrast as other meaningful text, while inactive disabled controls are exempt from WCAG contrast requirements. Persistent labels prevent placeholder-only instructions from disappearing, and disabled actions should explain how users can make them available when that information is necessary.

Where this leaves you

A WCAG contrast audit is a screen-level exercise, not a one-time palette review. The 4.5:1, 3:1, and 7:1 thresholds apply to the colours users actually see after surfaces, opacity, imagery, and state styling combine. Preserve brand recognition by changing the narrowest token that fixes the pair: an on-colour, a container shade, an icon token, or an image scrim. That approach avoids repainting an entire mobile theme for one weak label. Start with one production screen, document every foreground–background pair, and resolve the placeholder and disabled-state rows before expanding the audit.

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 →

•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.
•Color Blindness Simulator: Test App Colors — Use a color blindness simulator to test iOS and Android screens, fix red-green status fail
•Color Picker From Image: Build an App Palette — Use a color picker from image workflow to turn a reference screenshot into accessible app
•Gemini 3.1 for Mobile App UI Design: 4 Real Prompts Tested Hands-On (2026) — I tested Gemini 3.1 Pro with 4 real mobile app UI prompts — fitness tracker, food delivery