WCAG for Mobile Apps
WCAG for mobile apps means applying the Web Content Accessibility Guidelines to native, hybrid, and mobile web applications. WCAG 2.2 is the current version, and its success criteria cover touch gestures, target size, orientation, focus, screen readers, and accessible authentication. W3C’s draft WCAG2Mobile note explains how to interpret these criteria in mobile contexts. For an overview of all mobile standards, including Apple and Android guidance, see our mobile accessibility guidelines.
What Is WCAG for Mobile Apps?
WCAG for mobile apps refers to applying WCAG 2.2 principles and success criteria to apps on phones and tablets. W3C has not created a separate accessibility standard for mobile. Instead, it explains how existing WCAG criteria apply to touch interaction, small screens, different input methods, orientation, and platform accessibility services. The result is one shared benchmark for websites and apps.
Does WCAG Apply to Mobile Apps?
Yes. WCAG was written for web content, but its success criteria are widely applied to native, hybrid, and mobile web apps. W3C’s draft WCAG2Mobile note explains how to interpret WCAG 2.2 for apps, and WCAG2ICT covers non-web software more broadly. Laws also apply WCAG to apps directly: the ADA Title II rule covers state and local government mobile apps, and EN 301 549 covers apps in the EU.
What Are the WCAG 2.2 Requirements for Mobile Apps?
WCAG 2.2 is organized around testable success criteria under four principles: perceivable, operable, understandable, and robust. Most organizations target Level AA, which includes all Level A and Level AA criteria. On mobile, teams also need to consider touch interaction, screen orientation, focus, input methods, and assistive technology support. For more on conformance levels, see our WCAG compliance guide.
How Does Perceivable Accessibility Apply to Mobile Apps?
Perceivable accessibility ensures that information and interface elements in mobile apps can be presented in ways users can perceive, even when they rely on different visual or assistive technologies. In practice, mobile accessibility requires attention to contrast, text scaling, orientation, and how content adapts to different screen sizes and display settings.
for example: A mobile banking app should remain readable when a user increases text size, switch appropriately between portrait and landscape where permitted, and maintain sufficient contrast between text, icons, and backgrounds. These practices help users with low vision access essential tasks without depending on default display settings.
How Does Color Contrast Affect Mobile Accessibility?
Color contrast mobile interfaces should provide sufficient distinction between foreground content and its background so that text and important visual information remain readable. Under WCAG 2.2, 1.4.3 Contrast (Minimum) requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, subject to the applicable exceptions.
for example: If a shopping app uses light-gray text on a white background for product prices or checkout instructions, users with low vision may struggle to read essential information. Increasing the contrast ratio can make these elements significantly easier to identify.
How Does Text Scaling Improve Mobile Accessibility?
Text scaling allows users to enlarge content without losing information or functionality. Applying 1.4.4 Resize Text helps support mobile readability, particularly for people with low vision who depend on larger text or device-level display settings.
for example: When a user increases text size on a healthcare app, appointment details, labels, and instructions should remain visible and usable rather than becoming clipped or overlapping other controls. A responsive layout helps resize text without creating new navigation barriers.
How Does Screen Orientation Impact Mobile Accessibility?
Screen orientation accessibility means content should remain usable when users change between portrait and landscape views, unless a specific orientation is essential. WCAG 2.2 Success Criterion 1.3.4 Orientation addresses situations where restricting device orientation could prevent users from accessing content or completing tasks.
for example: A travel app should not unnecessarily lock users into portrait mode if landscape viewing would better support someone using a mounted device or an accessibility setup. Maintaining functionality across mobile orientation accessibility scenarios creates a more flexible experience
How Does Operable Accessibility Apply to Mobile Apps?
Operable accessibility ensures that users can navigate and interact with mobile apps through different input methods, including touch, keyboards, switches, and assistive technologies. Effective mobile accessibility requires predictable navigation, logical focus behavior, sufficiently large controls, and alternatives to complex gestures or device movements.
for example: In a banking app, a customer should be able to reach account controls in a logical sequence, activate buttons without precise tapping, and complete transactions without relying exclusively on swiping or shaking the device. This creates a more flexible experience for users with motor or mobility disabilities.
How Does Mobile Keyboard Navigation Support Accessibility?
Mobile keyboard navigation is important for users who connect physical keyboards, switch devices, or other alternative input technologies to their mobile devices. WCAG 2.1.1 Keyboard requires functionality to remain operable through a keyboard interface where applicable, ensuring that interaction is not dependent solely on touch.
for example: A productivity app should allow a user with a Bluetooth keyboard or assistive switch system to move through interactive controls and activate functions without requiring touch gestures.
Why Is Focus Order Important in Mobile Apps?
A logical focus order mobile experience helps users understand where they are and what they can interact with next. WCAG 2.4.3 Focus Order requires sequential navigation to preserve meaning and operability, which is particularly relevant when users navigate an app with screen readers, keyboards, or alternative input devices.
for example: In a checkout app, focus should move from product information to delivery details, payment fields, and the final purchase action rather than jumping unpredictably between unrelated controls.
How Does Touch Target Size Affect Mobile Accessibility?
Adequate touch target size reduces accidental activation and makes interactive controls easier to operate. WCAG 2.5.8 Target Size (Minimum) requires targets to meet a minimum size or have an allowed exception, helping users with limited dexterity interact more reliably with mobile interfaces.
for example: Small icons placed closely together in a mobile banking interface can be difficult to activate accurately. Providing appropriately sized and spaced controls makes actions such as opening menus or confirming payments easier to perform.
How Do Gesture Requirements Affect Mobile Accessibility?
Gesture accessibility requires mobile interactions to remain usable for people who cannot perform complex gestures or device movements. WCAG 2.5.1 Pointer Gestures addresses multipoint or path-based gestures, while 2.5.4 Motion Actuation addresses functionality triggered by device movement; where applicable, users should have simpler alternatives.
for example: A fitness app that requires users to shake a phone to dismiss an alert should provide an on-screen control as an alternative. Likewise, a map app should offer a simple button-based option when a feature would otherwise require a complex pointer gesture.
How Does Understandable Accessibility Apply to Mobile Apps?
Understandable accessibility helps users interpret content, navigate interfaces, and complete tasks without unnecessary confusion. In mobile apps, this means providing clear instructions, consistent navigation, meaningful form feedback, and predictable interactions that support users with cognitive, visual, and motor disabilities.
for example: A mobile healthcare app can improve usability by keeping navigation controls consistent across screens, clearly labeling appointment fields, and explaining exactly what went wrong when information is entered incorrectly. This reduces cognitive load and helps users complete important tasks independently.
How Can Mobile Form Accessibility Be Improved?
Effective mobile form accessibility starts with clear labels, useful instructions, and specific error messages. WCAG 3.3.1 Error Identification requires input errors to be identified and described, while 3.3.2 Labels or Instructions helps users understand what information is expected, making accessible forms easier to complete with screen readers and alternative input methods.
for example: If a user enters an invalid phone number in a banking app, the interface should identify the affected field and explain the required format instead of displaying only a generic error message.
How Do Consistent Navigation and User Interfaces Improve Mobile Accessibility?
Consistent navigation makes mobile interfaces easier to understand by keeping recurring controls and navigation mechanisms in predictable locations. WCAG 3.2.3 Consistent Navigation supports predictable mobile interfaces, reducing the effort users need to learn or relearn how an app works.
for example: An e-commerce app that keeps its search, cart, account, and primary navigation controls consistent across screens allows users to find essential functions without adapting to a different layout on every page.
How Does Error Prevention Improve Mobile App Accessibility?
Error prevention helps users avoid or correct mistakes before they cause significant consequences. WCAG 3.3.4 Error Prevention is particularly relevant to actions involving legal commitments, financial transactions, or important data, while clear confirmation and review mechanisms make accessible user input safer.
for example: Before confirming a mobile banking transfer, the app can display the recipient, amount, and account details for review and provide an accessible way to correct mistakes. This gives users an opportunity to identify errors before the transaction is submitted.
How Does Robust Accessibility Apply to Mobile Apps?
Robust accessibility ensures that mobile apps work reliably with different assistive technology and platform accessibility services. This includes exposing meaningful names, roles, states, and values to accessibility APIs so that users can interact with app controls through screen readers, switch access, voice input, and other supported technologies.
for example: A public-service app can expose each button, form field, and status message correctly to the device accessibility framework. A user who relies on a screen reader or alternative input method can then complete essential services without needing to interpret the visual interface independently.
How Does Mobile Screen Reader Accessibility Support WCAG Compliance?
Mobile screen reader accessibility depends on controls exposing their correct accessible name, role, state, and value. WCAG 4.1.2 Name, Role, Value supports this requirement, while platform technologies such as TalkBack on Android and VoiceOver on iOS allow users to navigate and interact with app content through spoken feedback and other accessible controls.
for example: In a mobile banking app, a visually presented "Transfer Money" icon should have a meaningful accessible name and expose its current state correctly. TalkBack or VoiceOver can then communicate the control to the user instead of announcing only an unlabeled button.
How Do Assistive Technologies Like Switch Control and Voice Control Support Mobile Accessibility?
Mobile accessibility should support multiple interaction methods rather than assuming every user can operate a touchscreen directly. Switch Control, Voice Control, screen readers, and other assistive technology can provide alternative ways to navigate, select, and activate mobile controls when interfaces expose appropriate accessibility semantics.
for example: A user with limited motor control may navigate a mobile app using Switch Control, while another user may rely on Voice Control to activate buttons. Controls with clear names and predictable interaction behavior allow both users to complete tasks without precise touch input.
How Does Alternative Text Support Mobile Accessibility?
Alternative text provides a meaningful textual equivalent for relevant non-text content and supports accessible images for users who cannot perceive visual information. Under WCAG 1.1.1 Non-text Content, informative images should have an appropriate text alternative, while purely decorative images can be implemented so they do not create unnecessary noise for assistive technologies.
for example: A travel app showing a hotel image should provide useful alt text when the image conveys information, while a decorative background image should not be unnecessarily announced by a screen reader. This helps users receive the information that actually matters.
How Can Native and Hybrid Mobile Apps Meet WCAG Requirements?
Native mobile apps and hybrid apps can support WCAG requirements by implementing accessibility at both the interface and platform level. Native iOS and Android apps should expose controls through their respective accessibility APIs, while web components inside native mobile apps need accessible HTML, semantics, focus behavior, and input handling. The implementation approach differs by architecture, but the goal remains the same: ensure content and functionality can be perceived, operated, understood, and interpreted by assistive technologies.
for example: A retail app built natively for iOS and Android may need separate accessibility implementations for VoiceOver and TalkBack, while a hybrid app may require accessibility testing across both its web-based components and native controls. Testing each platform independently helps identify architecture-specific barriers before release.
How Can Teams Apply WCAG During Mobile App Design and Development?
Teams can start implementing WCAG 2 in mobile from the earliest stages of mobile app design, rather than treating accessibility as a final testing task. App designers and developers can incorporate accessible interaction patterns, semantic controls, sufficient contrast, scalable text, keyboard and assistive-technology support, and appropriate accessibility features into requirements, design systems, development, testing, and release processes.
for example: A product team developing a mobile banking app can define WCAG requirements during planning, include accessible components in its design system, validate screen-reader behavior during development, and test critical user journeys before release. This approach allows accessibility barriers to be identified while they are still inexpensive to fix.
How Can Organizations Maintain Continuous WCAG Compliance for Mobile Apps?
Organizations can maintain WCAG compliance by treating accessibility as an ongoing accessibility journey rather than a one-time audit. Regular accessibility testing, accessibility monitoring, regression testing, and manual checks with assistive technologies help teams identify new barriers as mobile interfaces, operating systems, and features evolve. A structured process also helps organizations ensure accessibility remains part of product releases and ongoing maintenance.
for example: A financial institution can test critical journeys such as login, account access, and payments after each major app release. Combining automated checks with manual testing using VoiceOver and TalkBack helps detect accessibility regressions before they affect customers.
