How to Make Your App Accessible (WCAG 2.2)
Make an app accessible by designing and testing it against WCAG 2.2 Level AA, the most widely used target, and the iOS and Android accessibility guidelines. In practice: label every control for screen readers, support system text sizes without breaking layouts, meet contrast ratios (4.5:1 for normal text), make touch targets large enough, never rely on color or gestures alone, and make forms and errors clear. Test with VoiceOver and TalkBack on real devices, not only automated scanners.
- WCAG 2.2 Level AA is the practical target; it applies to native apps through W3C's WCAG2ICT guidance.
- Using native platform controls gets you most screen reader support for free; custom controls need extra work.
- Automated tools catch only part of the problems; manual testing with VoiceOver and TalkBack is essential.
- Accessibility is cheapest when built into design; retrofitting a finished app costs far more.
- Legal requirements vary: US state and local government apps must meet WCAG 2.1 AA under DOJ's Title II rule, with deadlines in 2027 and 2028.
The Steps
- Set WCAG 2.2 AA as the targetWrite WCAG 2.2 Level AA into the requirements and the contract, along with the platform guidelines from Apple and Google, so design, development and testing share one definition of done.
- Design with accessibility built inCheck color contrast, plan for large text sizes, keep touch targets generous, provide visible labels on form fields, and avoid conveying meaning through color alone.
- Prefer native componentsUse the platform's standard buttons, lists, switches and text fields wherever possible. They come with roles, states and keyboard support that custom components must recreate by hand.
- Label everything for screen readersGive every icon button, image and control a meaningful accessible label, hide decorative images, and make sure the reading order matches the visual order of the screen.
- Support dynamic text and orientationLet text scale with the user's system setting up to the largest sizes without truncation or overlap, and support both portrait and landscape unless a task truly requires one.
- Offer alternatives to complex gesturesProvide a single-tap or button alternative for swipes, drags and multi-finger gestures, and do not rely on shaking or tilting the device as the only way to act.
- Make forms and errors clearExplain what each field needs, identify errors in text near the field, preserve what the user typed, and avoid authentication steps that require memorizing or transcribing codes.
- Test with assistive technologyRun automated checks with Accessibility Inspector and Accessibility Scanner, then complete key journeys using VoiceOver, TalkBack, switch control and the largest text size.
- Publish a statement and keep testingDocument your conformance target and a contact for accessibility issues, fix reported problems quickly, and include accessibility checks in every release.
Why WCAG 2.2 Is the Target, Even for Native Apps
The Web Content Accessibility Guidelines are written for web content, but they are the reference point regulators, courts and procurement teams use for apps too. W3C publishes a guidance note, WCAG2ICT, that explains how each success criterion applies to non-web software, including native mobile apps. Apple's and Google's own accessibility guidelines then fill in platform specifics.
WCAG 2.2, published in 2023, added nine success criteria to 2.1. Several matter directly for apps:
- Target Size (Minimum): interactive targets at least 24 by 24 CSS pixels, or with enough spacing. Apple's guidelines recommend at least 44 by 44 points and Android's at least 48 by 48 dp, which comfortably exceed it.
- Dragging Movements: anything done by dragging must also be possible with a simple tap.
- Focus Not Obscured: sticky headers and keyboards must not hide the element that has focus.
- Accessible Authentication (Minimum): login must not depend on a cognitive test such as remembering or transcribing a code, unless an alternative such as paste, password managers or passkeys is supported.
- Redundant Entry and Consistent Help: do not make users retype information they already gave, and keep help in a consistent place.
The Legal Picture in Plain Terms
For US state and local governments, the Department of Justice's ADA Title II rule sets WCAG 2.1 Level AA as the standard for web content and mobile apps, including apps a vendor runs on a government's behalf. An April 2026 interim final rule moved the compliance dates to April 26, 2027 for entities serving 50,000 people or more and April 26, 2028 for smaller ones. If you build apps for public agencies, this is a contract requirement now.
For private businesses, the ADA does not name a technical standard in regulation, but lawsuits over inaccessible websites and apps are common, and WCAG is the benchmark used in them. In the European Union, the European Accessibility Act has applied since June 2025 to many consumer services, including e-commerce and banking apps. Get advice from a qualified attorney on what applies to your business; this page is not legal advice.
The Issues That Block Users Most Often
- Unlabeled icon buttons. A screen reader announces "button" with no name, so a blind user cannot tell the cart from the menu.
- Text that does not scale. Fixed font sizes, or layouts that clip text at large sizes, lock out many users with low vision, including many older customers.
- Low contrast. Light gray text on white fails the 4.5:1 ratio for normal text (3:1 for large text and for key interface graphics).
- Custom controls without roles or states. A custom toggle that does not report "on" or "off" is unusable with a screen reader.
- Gesture-only actions. Swipe-to-delete with no alternative, or carousels that only respond to swipes.
- Timeouts and auto-advancing content. Sessions that expire mid-form, or banners that move before they can be read.
How to Test Properly
Automated scanners such as Xcode's Accessibility Inspector, Android's Accessibility Scanner and web tools are fast and catch missing labels, contrast failures and small targets. They cannot tell whether a label makes sense, whether reading order is logical, or whether a task can actually be completed. For that, test the key journeys by hand:
- Turn on VoiceOver (iOS) or TalkBack (Android) and complete sign-up, the core task and checkout without looking at the screen.
- Set text to the largest accessibility size and check every screen for clipping and overlap.
- Try the app with switch control or a connected keyboard.
- Check with reduced motion and increased contrast settings on.
Where possible, include people with disabilities in usability testing. They find issues no checklist will. The same principles apply to your website, which customers often use alongside the app; see web design for the site side.
Making It Part of the Process
Accessibility costs least when it is a requirement from day one. Add it to your requirements document, include contrast and target-size checks in design review, add accessibility identifiers and labels as part of each feature's definition of done, and run a screen reader pass before each release. Retrofitting a finished app often means redesigning components, which is far more expensive than building them right.
Sources and Further Reading
We link to the primary documentation so you can verify the details yourself.
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C
- What's New in WCAG 2.2, W3C Web Accessibility Initiative
- Guidance on Applying WCAG 2.2 to Non-Web ICT (WCAG2ICT), W3C
- Fact Sheet: Rule on the Accessibility of Web Content and Mobile Apps, U.S. Department of Justice, ADA.gov
- Human Interface Guidelines: Accessibility, Apple Developer
- Test your app's accessibility, Android Developers
Related Questions
Does WCAG apply to native mobile apps?
WCAG itself is written for web content, but W3C's WCAG2ICT guidance explains how its criteria apply to native software, and the DOJ Title II rule explicitly applies WCAG 2.1 AA to government mobile apps. In practice, WCAG 2.2 AA plus Apple's and Google's guidelines is the accepted target for apps.
Is an accessibility overlay or plugin enough?
No. Overlays and widgets cannot fix missing labels, broken reading order or inaccessible custom controls in a native app, and they have drawn criticism from disability advocates on the web too. Accessibility has to be built into the app's code and design, then verified with assistive technology.
Should I target WCAG 2.1 or 2.2?
Target 2.2 Level AA. It includes everything in 2.1 plus nine newer criteria that matter on touch screens, such as target size and dragging alternatives. Meeting 2.2 AA also satisfies requirements written against 2.1 AA, such as the DOJ Title II rule.
How much does accessibility add to the budget?
Built in from the start, it usually adds a modest amount of design and testing effort, often a few percent of the project. Retrofitting an existing app can cost much more, because components may need redesign. An audit of the current app is the best way to size a retrofit.