Guide · 8 min read
App Accessibility Requirements 2026: The WCAG 2.2 Audit Every Indie Dev Needs Before Submitting
The European Accessibility Act became enforceable on June 28, 2025, making WCAG 2.2 Level AA compliance a legal requirement for apps distributed in the EU. Apple and Google have tightened their own accessibility review criteria in parallel. The practical result for indie developers: apps that fail screen reader navigation, color contrast checks, or use undersized touch targets are now on the wrong side of both legal exposure and store enforcement. Here's what to audit and in what order — no $25,000 external audit required.
WCAG 2.2 Level AA: the 6 requirements that apply directly to native mobile apps
WCAG 2.2 Level AA applies to native iOS and Android apps — not just websites — and six criteria are directly enforceable through Apple and Google's own developer guidelines. The relevant requirements are: sufficient touch target size (2.5.8), no color as the only visual differentiator (1.4.1), adequate color contrast (1.4.3 and 1.4.11), all functionality operable without a pointer (2.1.1), a logical focus order for assistive technology (1.3.2 and 2.4.3), and visible focus indicators for keyboard or switch navigation (2.4.7).
The key distinction between Levels A and AA: Level A covers the outright blockers (unlabeled buttons, content completely inaccessible to screen readers), while Level AA adds the quality floor — contrast ratios, focus visibility, sufficient target sizing — that separates tolerable from compliant. Both stores require at minimum that Level A criteria pass for submission. The EAA requires Level AA for apps distributed in Europe, which now effectively sets the bar for any app with meaningful EU user presence.
What's new in WCAG 2.2 versus 2.1: three additions matter most for mobile. First, the minimum touch target size criterion (2.5.8) is new. Second, 'dragging movements' (2.5.7) must have a single-pointer alternative. Third, redundant entry (3.3.7) limits how many times users have to re-enter the same information in a session — directly relevant to onboarding flows that collect user data across multiple screens.
Touch target size: 24×24px is the WCAG floor — 44pt is the practical minimum
WCAG 2.2 criterion 2.5.8 sets the minimum touch target size at 24×24 CSS pixels with adequate spacing between targets — but this is the compliance floor, not the design target. Apple's Human Interface Guidelines recommend 44×44 points, and Google's Material Design recommends 48×48 density-independent pixels. In practice, anything below 44pt on iOS will generate VoiceOver navigation complaints, even if it technically passes WCAG's 24px floor.
The failure pattern is consistent: icon-only toolbar buttons and text links inside dense paragraph content. These are the two places where developers routinely create tap targets under 20px because the visual element is small and expanding it feels like it would change the layout. The fix is almost always a padding expansion applied to the hit area rather than the visual element itself — the button stays the same visual size, but the touchable region is expanded invisibly around it.
Automated tools catch this reliably. Xcode's Accessibility Inspector flags touch targets below the Apple-recommended threshold during Simulator runs. Android Studio's Accessibility Scanner does the same for Android. Run both as part of your standard pre-submission build process — the same discipline that keeps your listing out of common App Store rejection reasons applies here: consistent build-time checks eliminate the surprises that delay launches.
VoiceOver audit: 5 iOS flows that catch most screen reader failures before review
Five VoiceOver navigation flows surface the majority of iOS accessibility failures before any reviewer sees them: the app's primary onboarding sequence, any modal or sheet that appears over existing content, form fields with inline validation, the main navigation structure (tab bar or navigation controller), and error or empty states. Walking these five flows with VoiceOver active — swipe right to advance focus, double-tap to activate — will expose unlabeled buttons, incorrect groupings, and focus traps within 20 minutes of testing.
The most common iOS failure is an unlabeled interactive element: a close button represented only by an X icon, a toggle without a meaningful accessible label, an image that doubles as a button with no accessibilityLabel set. VoiceOver reads these as 'button' or 'image' with no context. Fix: add accessibilityLabel to every interactive element that doesn't already have a human-readable title. Elements whose visible label is descriptive do not need additional labeling — only those where the visual representation is ambiguous.
One less-obvious failure mode: if your app uses animated transitions or motion-based elements, ensure they respect the 'Reduce Motion' accessibility setting. This matters both for users with vestibular disorders and for WCAG 2.3.3 compliance. The same principle applies to animated app icons — apps using motion-forward icon variants should offer a static fallback and honour the system-level Reduce Motion toggle, since animated assets that ignore this setting are flagged by Apple's accessibility reviewers.
TalkBack audit: 4 Android flows Play Store reviewers check
Four TalkBack navigation flows expose the accessibility failures Google's review process catches most consistently: linear navigation through the screen using swipe-right focus traversal, form completion using keyboard and TalkBack together, response to dynamic content changes (notifications, snackbars, bottom sheets that appear without user action), and any custom gesture path that doesn't have a single-pointer alternative.
The most frequent Android failure is incorrect focus order in custom views. When you build a UI component from a base View class rather than using a standard Material component, TalkBack often focuses elements in the order they appear in the XML hierarchy — which frequently does not match the logical reading order. Fix: use importantForAccessibility, accessibilityTraversalAfter, and accessibilityTraversalBefore to explicitly specify traversal order on any screen where the XML hierarchy and logical order diverge.
For Play Store submissions, also check your feature graphic and Play Store listing assets — images submitted without descriptive content descriptions fail Google's own asset review criteria separately from the in-app TalkBack audit. Your store listing assets are reviewed for accessibility compliance as part of the listing submission, not just your binary. Android Studio's Accessibility Scanner can be run directly against any screen during development and generates a report of failures with line-number-level fix guidance.
Color contrast 4.5:1 — the AA ratio most indie apps quietly fail
WCAG 2.2 Level AA requires a minimum contrast ratio of 4.5:1 between text and its background for normal text (under 18pt), and 3:1 for large text (18pt or larger, or 14pt bold). UI components and graphical elements require at least 3:1 against adjacent colors. This is the most frequently violated accessibility criterion in indie app audits, consistently, because most developers do not measure contrast — they eyeball it.
The failure pattern in practice: light gray placeholder text in search fields, white text on light-colored button backgrounds, medium-gray secondary labels in dark mode that look readable on a calibrated design monitor but fail on budget Android hardware with poor screen quality. The fix requires measuring, not guessing. Apple's Accessibility Inspector includes a contrast ratio checker. Online tools like the WebAIM contrast checker work for any hex or RGB value pair. Both stores now run automated contrast checks on binary submissions.
Dark mode doubles the surface area of potential failures: every text/background pair that passes in light mode needs to be separately checked in dark mode. Apps that set custom color values without defining both light and dark mode variants — relying instead on the system inverting their colors — routinely fail dark mode contrast checks even when the light mode version passes. Define explicit semantic colors for every text-background pair and check both modes before submitting.
Apple's Accessibility Nutrition Labels: what to declare and what you must not omit
Apple's Accessibility Nutrition Labels, introduced in iOS 18 and carried forward in iOS 26, let App Store users filter search results by accessibility features — making correct declarations a discoverability lever, not just a compliance checkbox. The declared features appear on your product page and feed Apple's accessibility-aware search filters. Incorrect declarations are an App Store rejection trigger: claiming VoiceOver support when the app has unlabeled buttons, or declaring subtitle support when the feature is absent, constitutes a misleading metadata violation.
The declaration process lives in App Store Connect under App Information → Accessibility. The categories are: VoiceOver, Voice Control, larger text sizes, sufficient contrast, reduced motion support, captioning and audio description, and alternative text for images. Declare every feature your app genuinely supports — and only those. An accurate sparse declaration (four features) is better than an optimistic full declaration that contradicts what a reviewer finds during testing. For a full walkthrough of the App Store Connect submission interface, the App Store Connect guide for first-time submitters covers where every field lives and in what order to fill them.
The discoverability upside is concrete: Apple's 'Made for' and 'Supports' filters in the App Store surface apps based on nutrition label declarations to users who have enabled accessibility features on their device. An app that genuinely supports VoiceOver and declares it accurately gains placement in filtered results that its unlabeled competitors do not appear in. It is one of the few ASO levers that works both for store visibility and user satisfaction simultaneously — analogous to how the App Store privacy nutrition labels affect trust signals on the product page.
Fastest compliance path for apps built before WCAG 2.2
The fastest compliance path for an existing app is to run Xcode's Accessibility Audit tool first — it surfaces Level A failures in minutes with zero manual effort, flagging unlabeled elements, insufficient contrast, and oversized text truncation automatically. Fix every automated finding before moving to manual testing. Automated tools catch approximately 30–40% of real-world failures; the rest require a manual VoiceOver walk.
After the automated pass, run the five VoiceOver flows described above on your highest-traffic screens — the onboarding sequence, the main feature screen, the settings flow, any paywall or purchase flow, and error states. Track each finding in a spreadsheet with three columns: screen, finding type, and fix status. Prioritize in this order: (1) focus traps and navigation dead-ends that prevent VoiceOver users from exiting a screen, (2) unlabeled interactive elements, (3) contrast failures, (4) touch target sizes. This ordering matches both store review priorities and user impact severity.
For a full listing refresh alongside the accessibility update — which is a natural moment since you're already touching submission assets — check that your App Store screenshot sizes are current for the 6.9-inch display class and your app icon dimensions include explicit dark and tinted variants for iOS 26. Accessibility compliance and a listing refresh submitted together create one review cycle rather than two, saving a week of turnaround time.
Compliance is a one-time sprint, not an ongoing overhead
The upfront investment in an accessibility audit — typically 10–20 hours for a mid-size app using the systematic approach above — produces a listing that performs in filtered App Store searches, reduces legal exposure in the EU and US, and reaches the roughly 15% of mobile users who rely on some form of assistive technology. That is not a charitable use case; it is a meaningful audience segment most apps are currently turning away.
Once the initial issues are resolved, maintaining compliance costs almost nothing: add accessibility labels to new interactive elements as you build them, run the Xcode Accessibility Audit in your pre-submission checklist, and recheck contrast ratios when you update your color scheme. Build it into the process once and it stops being a project.
Design accessible screenshots in the editor →
Frequently asked questions
is wcag 2.2 compliance required for app store submission?
Apple does not publish a specific list of WCAG 2.2 criteria as binary pass/fail submission requirements, but their Human Interface Guidelines align closely with WCAG 2.2 Level AA, and apps are rejected for accessibility violations including unlabeled UI elements, insufficient contrast, and inaccessible navigation. The European Accessibility Act (live June 28, 2025) makes WCAG 2.2 AA a legal requirement for apps in EU markets. The practical answer for any app with EU users: compliance is required.
what is the minimum touch target size for app store and play store?
WCAG 2.2 sets the minimum at 24×24 CSS pixels. Apple's Human Interface Guidelines recommend 44×44 points. Google's Material Design recommends 48×48 density-independent pixels. In practice, targeting Apple's 44pt recommendation on iOS and Google's 48dp on Android will pass both WCAG and store review criteria — the WCAG floor of 24px is too small for comfortable real-world use and will fail manual review on screens with dense layouts.
how do i test my app with voiceover on ios?
Enable VoiceOver in Settings → Accessibility → VoiceOver, or triple-click the side button if you have the Accessibility Shortcut configured. With VoiceOver on: single-tap to select and hear an element, swipe right to advance to the next element, swipe left to go back, double-tap to activate. Walk your five most-used flows — onboarding, core feature, navigation, settings, and error states — and note any element that announces as 'button' or 'image' without a descriptive label. Those are your first fixes.
what color contrast ratio do i need for app store approval?
WCAG 2.2 Level AA requires 4.5:1 contrast ratio for normal text (under 18pt regular or 14pt bold) and 3:1 for large text. UI component graphics and icons need at least 3:1 against adjacent colors. Check every text/background pair in both light and dark mode — they are evaluated separately. Use Xcode's Accessibility Inspector or any WCAG contrast checker tool with your exact hex values; eyeballing contrast fails consistently.
do accessibility nutrition labels in the app store affect search ranking?
Accessibility Nutrition Labels affect discoverability through Apple's filtered search results — users who enable accessibility filters on their devices see only apps that declare the matching features. This is not traditional keyword ranking but it is a meaningful visibility filter that most apps opt out of by default by not declaring anything. Correct declarations increase placement in filtered results; incorrect declarations are a rejection trigger.