Mobile App Accessibility to WCAG 2.1 AA

What WCAG 2.1 AA means inside an iOS or Android app

WCAG was written for the web, but the W3C publishes guidance on applying it to native software, and it is the standard most US contracts and the European Accessibility Act point to for apps. On a phone, the same principles land on different platform features. A text alternative becomes an accessibility label on iOS or a content description on Android. Name, role and value means every custom control announces what it is and whether it is selected. Tepia maps each success criterion to the iOS, Android, React Native or Flutter feature that satisfies it before design starts.

Some criteria matter more on a phone than on a desktop. Content has to work in portrait and landscape unless one orientation is essential. Gestures such as swipe to delete or pinch to zoom need a simple tap alternative. Text must stay readable when someone sets their phone to its largest font size, and confirmations such as a saved form must be announced without stealing focus. Teams that only test with a mouse in a desktop browser miss every one of these.

The criteria that trip up most apps, and how Tepia handles them

Tepia reviews new designs and inherited code against the same short list first, because these failures show up in nearly every app we audit:

Target size is Level AAA in WCAG 2.1, yet Tepia still follows the Apple guideline of 44 by 44 points and the Android guideline of 48 by 48 density independent pixels. Small tap targets are among the most frequent complaints from people with tremor or limited dexterity, and fixing them later means reworking layouts.

Who needs an accessible app, and when

Several rules now name WCAG 2.1 AA directly, and Tepia sees them drive real deadlines for clients:

• State and local government. A 2024 Department of Justice rule under ADA Title II requires public entities to make web content and mobile apps conform to WCAG 2.1 AA, with the first compliance dates in 2026. Transit agencies, utilities and parks departments, plus the vendors who build for them, are in scope.
• Health care. HHS adopted a similar WCAG 2.1 AA requirement in 2024 for providers that receive federal financial assistance, which reaches patient apps and portals.
• Federal work. Section 508 incorporates WCAG 2.0 AA, and agencies expect an Accessibility Conformance Report from vendors.
• Selling into the EU. The European Accessibility Act has applied since June 2025 to consumer services such as ecommerce, banking and passenger transport apps.
• Private US businesses. ADA claims over inaccessible websites and apps are common, and settlements usually name WCAG 2.1 AA as the fix.

Tepia is not a law firm, so we work alongside your counsel on which rules apply to you. Our job is to build an app that meets the technical standard and to show, screen by screen, how it does.

Testing with assistive technology, not just scanners

Automated tools find missing labels and low contrast quickly, so Tepia runs them on every build: the Xcode Accessibility Inspector and XCTest accessibility audits on iOS, Accessibility Scanner and Espresso accessibility checks on Android, and lint rules for React Native accessibility props and Flutter semantics. They cannot tell you whether a checkout makes sense when heard aloud, or whether focus lands somewhere useful after a modal closes.

That part is manual. QA engineers complete each core user flow with VoiceOver and TalkBack, then repeat key flows with Switch Control, Voice Control, Full Keyboard Access, Bold Text, Reduce Motion and the largest text size. Where the audience calls for it, we include people who use assistive technology every day in usability sessions, as described in our UX research and usability testing work. Accessibility checks then join the definition of done in our QA and automated testing pipeline so later releases do not quietly regress.

How Tepia approaches mobile app accessibility

Accessibility runs through all six phases of the Tepia process rather than sitting at the end as an audit.

1. Discovery: we confirm which rules and contracts apply, interview users who rely on assistive technology where possible, and write accessibility acceptance criteria into the User Stories. The Investigation Summary lists third party SDKs, such as chat widgets or map views, that may not be accessible.
2. Design: the style guide sets contrast safe color tokens, type scales that grow with system settings, focus states and target sizes. Detailed wireframes annotate reading order and labels for every custom control.
3. Development and Testing: engineers build with native accessibility APIs, and Alpha and Beta test plans include screen reader passes for each user story, plus non functional testing at large text sizes and in both orientations.
4. Training: your team learns how to write alt text in the admin portal and how to check new content with VoiceOver before publishing.
5. Launch: we deliver a conformance summary by screen and confirm store listing text and screenshots describe accessibility features accurately.
6. Support: accessibility issues are tracked as bugs with severity, and new features go through the same checks.

See how this fits the wider Tepia process.

Fixing an existing app versus building access in

If your app is already live, Tepia starts with an audit of the flows that matter most, such as sign up, login, search, checkout and booking, and turns findings into a backlog ranked by severity and by how many users each issue blocks. Fixes in shared components carry the furthest: correcting one button, text field or tab bar component often clears dozens of findings at once.

Sometimes the audit shows a deeper problem, such as a custom drawn interface that exposes nothing to the accessibility tree or a layout system that cannot handle large text. In that case a targeted app redesign is usually faster than patching screen by screen. For new products, building access in from the first sprint is simply less work, and it is part of how Tepia approaches mobile app UI and UX design on every project. Talk to Tepia about an audit or a new build.

Frequently asked questions