Mobile App Accessibility, Native vs. Web

Marco Zehe, accessibility QA engineer at Mozilla, asks “Why do native mobile apps seem to win all the time?” I’ve written before about native vs. web apps (more here), but the accessibility angle is not as widely discussed, so I’m glad Zehe wrote this. That said, there are some points I disagree with and feel need clearing up.

Zehe theorizes that the answer to his question lies with browser differences and the complexities inherent to supporting multiple browsers across the mobile platforms, each with different levels of support for different things. This is certainly a big part of the challenge, but Zehe overlooks certain aspects which skew his assessments towards the inaccurate. For instance:

Native apps do a much better job at providing a single point of focus for the user. … If I want to order a pizza, or shop on Amazon, I want to stay focused and not be distracted by ads, too many offerings, bells and whistles, etc. I want to get the job done.

You can make a native app incredibly cluttered and a web app incredibly focused; the principle of focus is not an inherent trait or benefit to either platform from a technical point of view. Where native does benefit in this regard are Apple’s and Google’s approval processes, which provide strong guidelines and which will even outright reject apps that are badly designed or developed. Web apps have no such approval process to benefit from, so there is a greater onus on the web designer & developer to get it right. (aside: an opportunity for Mozilla reveals itself here)

Zehe writes:

Loading pages is a very webby thing that can take quite some seconds before the app becomes useable again. A lot could be accomplished by putting everything in one bigger HTML file plus CSS and JS, and show and hide the currently not focused areas dynamically. Compiled JS is fast enough even on mobile devices that the delays are much much less than actual page loads.

This is a fallacy, which Zehe actually touches upon when talking about why native apps have better accessibility:

The reason in many cases is that both iOS and Android have UI components that give a lot of accessibility for free just by using them. iOS and Android app developers only need to do comparably few things to make their even a little more than simple UIs accessible to the assistive technologies preinstalled on those operating systems.

The stuff that native apps get free is not insignificant, and that matters for both general usability as well as (or even more so) their accessibility. These are frameworks of several hundreds of megabytes worth that native apps can make use of to render their UIs with, become more accessible through, and hook interactions and UI views together with. On the web, you simply cannot put 100MB worth of code in your page to get similar benefits. We’re allowed whatever the browser itself offers, and the code we use in the web app (or website).

This is why it’s so important that browser vendors—mainly Apple, Google and Microsoft as the owners of the mobile platforms’ built-in web environments—are adding native-inspired features to their browsers: so that we as web authors can benefit from them without having to recreate them manually in HTML, CSS and JavaScript, all of which the user has to download along with our actual app code, before she can benefit from them.

Zehe is absolutely right that accessibility is better in native apps in large part because of the stuff those apps get for free from the OS, but I question that it’s “economically saner” for companies to produce one native app per platform. The only economically sane approach there is to still use web technologies and use PhoneGap to turn them into native apps, lest you spend triple design and development efforts in addition to providing a mobile-friendly website experience, which you should do regardless.

So what is my recommendation? Learn how to design and develop properly for the mobile web; it’s not impossible or significantly harder, it’s just different from the desktop web which you’re used to. Use cleaner libraries that don’t come with legacy browser support which you don’t need for this environment. Take advantage of what built-in accessibility support browsers do have, which largely revolves around using clean, semantic markup and HTML5 widgets rather than shims or polyfills. There’s a lot you can do on mobile browsers with the basic building blocks and some smart design.

I also recommend these three books:

Disclosure: I have no direct affiliation nor kickback to those books, but I am an A Book Apart reviewer.

People may come to your (mobile or desktop) website directly in their phone or tablet browser, or in a webview inside of a Twitter or Facebook application or an RSS reader. Even if you do offer a native app for iOS, Android and Windows Phone users, your site should still allow the user to do what she has come to your site to do, and have a good, accessible experience doing so. No amount of native apps, no matter how much better they can be regardless, justifies you having an outright bad web experience.

If you liked this, you should follow me on Twitter!