Why Are There No Mobile Accessibility Guidelines in WCAG?

How do you test mobile apps for accessibility?

In some ways, the answer is straightforward. The Web Content Accessibility Guidelines (WCAG) are widely understood to apply to mobile apps as well. WCAG makes clear that its success criteria are intended to be technology-agnostic. (This will be reflected in the upcoming WCAG 3.0 which will be the W3C Accessibility Guidelines rather than Web Content Accessibility Guidelines).

And skilled accessibility practitioners should have no problems translating WCAG guidelines for mobile apps. W3C has also published supplemental documentation outlining how to map WCAG to mobile apps and there are open source resources around testing methodologies. But if you read this document, it quickly becomes clear that mobile app accessibility isn’t nearly as straightforward as it should be.

Why this matters?

Mobile accessibility testing is underprovisioned. HTML and DOM are exposed in the browser, which allows tools like aXe and WAVE to partially automate the accessibility testing process. While these tools aren’t comprehensive, being able to find and fix 25% of issues is a huge deal. 

In contrast, mobile apps start at a disadvantage. Apps are compiled and there aren’t really equivalent tools. There are developer tools that can be used for accessibility but mobile app accessibility testing is much more of a manual process. Here’s how you can tell. Overlay companies are all about trying to fully automate the testing and remediation process. Even they will still try to sell you a manual audit when it comes to your mobile app.

Anecdotally we see many fewer companies that offer mobile app accessibility testing. (Access Armada is proud to be one of the few.) There could be any number of reasons for this, but it’s plausible that the funnel is just a lot smaller. It’s harder for accessibility professionals to dip their toes in the water and it’s harder for the companies developing apps to get a smell test of their app accessibility without an investment.

This is a big shame because mobile app accessibility testing is especially important for users with disabilities. The most recent WebAIM screen reader user survey showed that well over half of respondents are more likely to use mobile apps over websites for common online tasks such as banking or shopping.

Mobile accessibility is a lower investment

But while mobile app testing may feel like a larger investment, the opposite is usually true. While websites can be displayed on multiple OS, browsers and screen readers, there’s usually only one option per app. For example, a native iOS app often only needs to be tested in one OS and one screen reader.

Keeping all of this in mind, it’s to our advantage if we can reduce the barriers to entry by providing crystal clear guidance to the extent possible. WCAG tries but it requires a bit more analysis to map it to mobile.

Mobile is an awkward fit in WCAG

The mobile guidance we referenced above relates to WCAG 2.0 and was published nearly 10 years ago. Since then, there have been two more WCAG versions and additional criteria have been added that more explicitly address mobile-specific scenarios. But it’s hard to escape just how much WCAG is built around web content. (And even within web, how much the criteria assume computer users with access to a keyboard as opposed to touchscreen inputs.) This has become more apparent as non-web modes of content have expanded over the years. The Mobile Accessibility at W3C page now folds these various types of devices together:

• Phones and tablets
• Digital TVs
• Wearables
• Card dashboard devices
• Airplane seatback screens
• Household appliances and other Internet of Things

This list doesn’t even include other related technologies like augmented reality (AR), virtual reality (VR) or AI.

The overall principles and specific success criteria in WCAG are extensible and mostly applicable. But the web-centric perspective leaves gaps.

Mobile-specific issues are underspecified

The original mobile accessibility mapping document from 2015 acknowledges that there are accessibility issues that are unique to mobile devices and that WCAG does not provide testable success criteria for some of these issues. WCAG 2.1 and 2.2 have addressed many of these gaps by adding in criteria for device orientation, single finger pointer gestures, target sizes that account for touchscreens, and motion actuation. It’s beyond the purview of this article to opine on how these best practices and considerations affect what is required to have a “compliant” accessible mobile app. But it is important to keep in mind that W3C notes that even those mobile-specific considerations that are not expressly addressed in WCAG are not optional.

Missing techniques

The bigger issue related to the web-centric perspective of WCAG is how to successfully implement accessibility in conformance with relevant guidelines. The latest version of WCAG shares hundreds of techniques for how to build accessible features in conformance with WCAG. Some of these are general techniques that are more conceptual but many are technology-specific. And just about all of these technologies (most prominently HTML, CSS, ARIA) are web-specific.

There are no techniques for mobile apps.

Who sets the standards for mobile apps?

Mobile is a walled garden. Or two walled gardens to be exact. And the landlords are Google and Apple.

Each respective OS has its own accessibility features built in and that includes the provision of certain techniques, elements, and documentation related to accessibility. These can be mapped to WCAG (more on that later) but have no normative status here. When the relevant guidance is followed, the outcome should be accessible but there is automatically some added complexity in attempting to map these techniques to web-centric success criteria.

How web is different from mobile?

Unlike mobile apps, web is still (for now at least) an open standard with some centralized management. There’s some fascinating history behind how this came to be. But practically this means that that W3C is a governing consortium with membership and support from major technology players. W3C sets technical standards for HTML, DOM, CSS and other protocols related to the web. Browsers and other user agents are developed against these standards. And shockingly it all pretty much just works.

This also includes setting standards for web accessibility.

But it’s not just a question of which technology standards W3C controls. WCAG also includes techniques for making PDFs accessible, which are also aligned to the PDF/UA (Universal Accessibility) standard.

Why are there no mobile standards?

Apple and Google both manually review apps before they are allowed to join the app store. Apple is famously not shy at all about denying submissions based on security, quality or other criteria. That includes blocking apps that take payments without using the built-in OS payment feature with a 30% commission for Apple on all transactions.

The quality criteria often appear arbitrary. I was fascinated by the story of the HEY Calendar app that was initially rejected by Apple earlier this year on the grounds that “it doesn’t do anything”. I don’t think Apple (only) rejects apps for self-interested reasons. But it was interesting to me that accessibility is not one of the criteria Apple uses to determine whether an app should be available to its users.

Apple and Google both do important work to facilitate accessibility on their devices and operating systems. But as the sole gatekeepers on their systems, they could both single handedly impose real accessibility standards and requirements on their app stores. Not doing so is a choice.

Will we ever get mobile accessibility standards?

Some of that is up to Apple and Google. Either one could introduce and enforce their own criteria at any point.

But in the absence of centralized leadership, it was interesting to read about this new effort by Evinced, introduced at the CSUN conference this year, to create a draft open source Mobile Content Accessibility Guidelines (MCAG). It attempts to bridge the Apple Human Interface Guidelines and Android Accessibility Principles with WCAG. It is definitely a worthwhile reference for developers and testers looking to validate mobile app accessibility.

That said, it doesn’t quite feel ready for prime time. Mobile developers would benefit from a more explicit documentation of Android and iOS techniques for conformance along the lines of what WCAG already offers for web technologies.

I’m also ambivalent about the MCAG success criteria organization. MCAG is structured as an interpretation of WCAG and cross-references equivalent WCAG success criteria but it is organized and numbered internally based on the Android and iOS guidelines. This feels like a significant barrier to adoption for users that may already be familiar with WCAG guidelines.

It also reproduces some of the weaknesses of WCAG in closely reflecting the status quo of how most mobile apps are currently developed. It would be better to have an MCAG that can be adapted to new form factors that don’t yet exist as well as applications that bridge the gap between mobile and web like PWA or hybrid apps with web wrappers.

Why I’m optimistic

The MCAG organizers have expressed an interest in having the mobile guidelines incorporated directly into WCAG eventually. Earlier this year, the W3C Mobile Accessibility Task Force announced a change of direction to creating guidance for Android and iOS apps. Let’s hope there’s more (and better) guidance for mobile app accessibility soon!

In the meantime

Access Armada can help your team interpret the existing WCAG guidelines for mobile so you can build, test and remediate your mobile apps to be accessible. We've supported many organizations in incorporating accessibility into their mobile workflows. Contact us today to review how we can help you start your mobile accessibility journey.