Testing mobile apps – what differs from web testing? (part 1)

The Web Content Accessibility Guidelines as the basis

The foundation for most accessibility testing of web sites and applications are the Web Content Accessibility Guidelines (WCAG), currently in version 2.2. These Guidelines are developed by W3C’s Accessibility Guidelines Working Group (AGWG). They also form the basis of the web-related part of the European accessibility standard EN 301 549 and indirectly also of BITV 2.0 since this German regulation for the public sector refers to current European standards. The WCAG Understanding documents and Techniques help developers, designers and testers understand what the individual accessibility requirements mean, how they can be successfully integrated in web development, and how they can be evaluated.

However, the WCAG supporting documents are geared towards web testing, not mobile testing. While the basic requirements are largely the same, the testing of native mobile apps requires a different approach. The use of the built-in screen readers, Talkback (Android) and VoiceOver (iOS), gains a far greater importance. 

What standards apply to native mobile apps?

In terms of the European accessibility standard, EN 301 549, mobile apps fall under clause 11 Software, and anyone looking at that clause will immediately recognize that it largely replicates the WCAG success criteria reproduced in clause 9, Web. Exempted are six success criteria which are not always appropriate for software. The AGWG has been working on a document called Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT) (last updated in December 2025 to include additions in WCAG version 2.2) to help people apply requirements – in WCAG parlance, Success Criteria – to mobile applications, requirements that were originally focused on for web technologies. In most cases, the WCAG2ICT document states that the requirements equally apply to mobile apps. NOTES help contextualize the transposition.

What about web apps?

Many apps contain largely web content that is wrapped in a native interface. Often, the navigation forms the native shell, while HTML content is brought in via web views. Does that mean that this content should be evaluated according to the web clause of the standard? The latest version V4.1.0 of the EN 302 549 (PDF) has settled this point by stating, at the beginning of clause 11 Software:

“When parts of non-web software, such as mobile apps, are implemented with web views, such a view is embedded in the app and thus does not meet the definition of web page. The clause 11 "Non-web software" requirements are the appropriate requirements to be applied to these web views. There are no circumstances in which clause 9 requirements and the corresponding clause 11 requirements are both applicable. Where there is any doubt, clause 11 requirements have precedence.”

How can WCAG be applied to mobile?

When the European Web Accessibility Directive 2016/2102 mandated accessibility also for mobile apps, the question surfaced how these apps could be tested since they are not based on web standards like HTML, CSS and JavaScript (EcmaScript). There are a number of significant differences when testing native mobile apps:

• When testing web content, testers can explore, and even change on the fly, the source code of websites as it appears in the browser’s DOM (document object model). Press the F12 key, and most common browsers will open the developer tools alongside the current page to provide a view of its innards, the HTML source code. In contrast, the source code of native apps is usually not available (unless testing has full access to the development environment).
• When testing websites, a swathe of useful tools implemented as browser plug-ins or bookmarklets is available to interrogate the DOM and identify errors or issues. When testing mobile apps, there are fewer tools that help here, for example, or Android Accessibility Scanner, and they will cover fewer requirements.
• Several companies like Abra or evinced are offering platforms to facilitate mobile testing. By hooking up the mobile device to a computer, they give access to the accessibility tree and automate to some extent tasks like contrast measurement. The rather bare-ones Android Accessibility inspector is a free software that also provides access to the accessibility tree – that is, the hierarchy of elements with its roles names and attribute values.
• Several requirements that involve the browser as user agent for modifying the presentation of the web content, for example in text sizing or text reflow, do not apply in the same way to native app content. Here, the underlying platform, the mobile operating system, takes the place or user agent. 

Is there guidance for mobile testing?

The BIK BITV-Test / EN 301 549 (App) test procedure provides detailed steps for testing iOS and Android mobile apps. In the absence of Understanding texts and approved Techniques  for mobile testing, there is still some uncertainty on what exactly is required. The Github issues of the Mobile Accessibility Task Force and other places like the Slack channels mobile-testing and native-mobile show the ongoing discussions and disagreements.