Twitter is often a place of small, but thought-provoking bits of information or personal impression. Just today, Mick Curran, one of the NVDA core developers, tweeted this:

and followed it up with this:

Jamie Teh, the other NVDA core developer, replied to this and said:

And this question touches part of the problem, but not the whole. The questions can be continued:

  • Why are there native iOS and Android apps for so many offerings that originate on the web?
  • Why is it that even Google, a company with a clear web focus, creates native Android apps for its services like GMail or Google Plus?

I believe there are several parts to a possible answer:

Developing for mobile browsers is damn hard

Every web developer who has developed mobile sites or web applications ever, and tried to make the site work on as many devices and browsers as possible, knows what hard work this is. On Android alone, the native browser behaves differently in each major version. 2.2 and 2.3 support different stuff than 3.x (the tablet-only version) and 4.0 did. And then there’s Chrome and Firefox, which also run on each of these versions, but which have to be installed separately. Then there’s Android 4.1+ with Chrome preinstalled at least on the NEXUS 7 tablet, but possibly others. iOS, which has a high rate of current version usage, supports other things than Microsoft’s mobile version of IE which runs on Windows Phone. Animations in one browser run once while in another runs forward and backward the same amount, or in a third browser, doesn’t stop animating at all… You get the picture!

The result is that many mobile sites, to support the widest possible range, are cut down to a bare minimum. Many web devs are even afraid to use anything but basic JavaScript and CSS properties because the three year old version of Webkit that runs on a Gingerbread Android browser doesn’t know about these things.

So, for many companies, it is economically saner to produce one native app per platform instead that just talks to their backend on the web, but gives users a consistent user interface to deal with even if they upgrade to a newer device along the way.

Others, like Facebook, decide to cut down their hybrid web content strategy in favor of a more native app to improve the user experience that way, because they feel that they would otherwise get nowhere with what they had. On both iOS and Android, access to device features is easier than from the browser, or it is not possible to use many features from the browser at all.

Other factors also come into play, like how to manage multiple accounts from the same service, e. g., Twitter, through conventional web means like cookies. While the native apps for Android and iOS support multiple accounts, the web app does not, it instead requires one to sign out and in with a different user name and password manually.

Too much clutter

Let’s face it, there are hardly any mobile apps that aren’t either cut down to a point of excruciating pain, or overloaded with too much clutter like a whole bunch of navigation links that take away valuable space especially on small hand-held devices such as iPhones or other smartphones. Native apps do a much better job at providing a single point of focus for the user. Users either want to view a list of articles, do a search, browse categories, but not all at the same time on a 4 inch screen! Or in the case of social media, they want to view a list of posts, or they want to compose one. Trying to squeeze both into a single web page on a small screen is undoubtedly going to create a less than pleasant user experience. In a native app, a tabbed interface allows the majority of the screen estate to be used for a single purpose, a single task, a single point of focus. Links to a web site is only presented in the About section, where it belongs, along with a copyright notice etc. In almost all web presences for mobile and desktop browsers I know, a lot of cruft is being taken along onto every sub page one visits. A huge navigation side bar, a top bar, a search, a footer with a lot of meta data….While this is still relatively OK on desktop computers, mobile devices have much less space, or much more need to scroll and become inefficient if too much stuff is presented at once.

Efficiency is maybe the greatest factor of all. 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. I, myself, even though I work for a company that puts the web in front of all other stuff, find that I haven’t done shopping through the Amazon website in over a year because the native iOS app lets me do it so much faster. What I can shop for in the Amazon app within a minute, usually takes me at least(!) twice as long in any browser/screen reader combo. In other cases, like the one Mick describes in his tweets quoted earlier, the web site is marked up so badly that it is nearly impossible to place an order, whereas the native app makes it very easy to do.

And then there’s the browser UI itself. It takes up some valuable portion of the screen and is a constant reminder that one is not inside a mobile app but rather a web page. In a native app, this aspect becomes completely transparent. The user does not need to care what’s working behind the scenes. They get their job done, they simply launch the app, they simply interact with what they want to accomplish.

The Mozilla market place goes a long way to alleviate this last aspect, by launching the installed web app in a Firefox runtime on one’s Android device that leaves out all the typical browser UI pieces, and gibes a full screen view of the web app.

But all the web apps I’ve tried still remind me that it’s web pages I’m dealing with. They have links they carry onto every sub page I move to while working the app, and they always clutter up parts of my valuable screen estate. And yes, they get in the way! They either require me to explore past them, remember that they’re there and that I should start exploring somewhere one third down from the top, or not move too far to the left to not encounter them, etc.

And interaction models often require new pages to load. 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.

There’s only one mobile web app that I know of that mimics the look and feel of its native Android counterpart, and that’s Mobile Twitter. Unfortunately, its markup is rather wild, so it is barely accessible. I have no access to the Compose button in Firefox for Android, for example. But in principle, that’s what a mobile app should be. it removes all the clutter of a typical web page, gives a tabbed interface and doesn’t bother the user with a composition form that would take up valuable space that can now be used for more relevant content.


Yes, this is often a deciding factor, too, whether I, or other blind users, choose to use a native app rather than the web site or mobile offering. And as the above mentioned Facebook example shows, their switch to a native app allowed them to provide a much better accessibility experience for visually impaired users on iOS.

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.

Like with many things on the web, implementing accessibility is not an easy task especially for more complex compound widgets. Fortunately many UI libraries now offer accessibility for free, but how many of them can actually be used efficiently on mobile devices nowadays? In short, the danger — and yes, I use this word consciously — of encountering wild-west web coding in accessibility terms is quite high. This becomes an important factor for Mozilla as we venture into the mobile app space more and more with our own Firefox OS offering. I’m seeing a lot of evangelism work ahead actually, starting with our own implemented apps and expanding that to the author base on the Market Place.

In summary

The theme of too much clutter impacts a big range of people, not only visually impaired ones. People with cognitive disabilities, for example, are also often frustrated and confused by too much navigation or other “webby” stuff on small mobile screens. “Regular” sighted people I talked to prefer native apps for the same reason.

Many web app developers need to become much more conscious of what the actual focus point for their end users is at any given point in their application, and center the whole interaction of a single screen around that. The relevant content must always come first, and things that we used to take for granted like navigation bars etc. need to recede into the background or get their own special corner inside the app to not take up valuable screen estate and constantly get in the way of the user.

If some of these paradigms settle into the minds of a majority of mobile web app developers, the debate of whether the web is the better platform or not may take a more positive turn for the web from the user’s point of view.

Exactly on this day five years ago, on Monday, December 3, 2007, I started work at Mozilla as the QA engineer for Accessibility. I’d like to take this small anniversary to look back and look ahead.

When I started, Mozilla Messaging had just been formed to drive and oversee the development of Mozilla Thunderbird. Mozilla Messaging has been folded back into the main Mozilla entity, and Thunderbird has just seen its last major release.

When I started, Google Chrome wasn’t even in existence yet. Today, Firefox is reaffirming its second place in the worldwide browser rankings again, after having struggling a bit in the adjustment period following the long awaited Firefox 4 release and the switch to a six week major release cycle in early 2011. I can certainly feel the Mozilla comeback myself!

When I started, Windows Vista was becoming Microsoft’s big failure. I struggled with it on more than one occasion, and stuck with Windows XP for my main development and testing work until Windows 7 was released in October 2009.

In the last five years, NVDA, whose core developers had just started to implement in-process (fast) virtual buffers, has grown into a real free and open alternative to commercial screen readers in many use cases, and their momentum is still carrying forward! The continuing collaboration between Mozilla and NVDA has led, by testimonials from many users given to me in written and spoken form, to the most rock-solid web surfing experience in Microsoft Windows for blind users. The NVDA team was also never afraid to take chances, question approaches to how certain content should be rendered and interacted with, and innovate on those ideas and questions.

The GNOME desktop was a promising alternative to Windows desktops, and distributions like Ubuntu had the potential to become real end-user alternatives, not just aimed at nerds who weren’t afraid of the terminal. Unfortunately, non-cohesive strategies in the various groups have led to much confusion and frustration, over-all weakening the Linux desktop for end users a lot, distributions changing designs in a major fashion with every release, etc.

The Mozilla accessibility module had no automated test coverage when I started. With the help of other Mozillians, Alexander Surkov and I worked very hard for the first year to lift a mochitest suite off the ground, and shortly before Christmas of 2008, we succeeded, and since then, accessibility has had major, and always improving test coverage on Mozilla’s build machines. It helps to catch accessibility regressions not only in our module, but also in other Gecko code that might negatively impact us.

And then, there was the mobile story, which, when I started, was hardly a story yet. At my first work week in Mountain View, with Mozilla’s headquarters still located in buildings K and S of 1981 Landings Drive, I wrote a blog post about what I thought mobile accessibility might look like in the near and not so near future. Reading this article today, it is very clear that I am not going to be a fortune teller anytime soon. 😉 The actual development played out a lot differently than I had anticipated. But let’s take a look at what the Mozilla mobile story has been since then:

I first saw mobile Firefox in action at the Mozilla Summit 2008 in Whistler, BC, Canada. It ran on Nokia N800 devices on a mobile operating system called MAEMO. MAEMO was Nokia’s parallel effort at a smartphone operating system based on Linux and KDE. Their other strong smartphone arm, based on Symbian, never really played a role here. Today, Symbian is history, more or less, and MAEMO is just having a resurrection attempt somewhere else. Nokia is building Windows Phones now and struggling to survive.

The struggle Nokia was going through with the smartphone operating system business also didn’t leave Mozilla unaffected. They changed the name once or twice until they duck away in hiding some time in 2010. Mozilla has since abandoned MAEMO and its cousins I believe.

Later, there was also a Windows Mobile 6.x version of Firefox, which never saw an actual release, and was discontinued when Microsoft announced Windows phone 7 and its major changes in architecture, which made it apparent that Mozilla couldn’t do anything useful with it afterwards. With the release of Windows 8, this changes again, at least for the X86 part of the story.

And then, there’s Android. It rose at the same time as iOS gained momentum. Both of them totally turned the tables on mobile operating systems over the last four years. And so did Mozilla’s efforts. Firefox for Android has been in development since some time in late 2009, and it saw its first, not very well received, releases.

Our struggle with Firefox for Android, always being very slow to start and very sluggish to use, took a massive turn for the better when the team took chances and decided to completely throw away the XUL-based UI and replace it with one written in native Android widgets and Java. The only view that is not Android is the one that’s displaying the important bits: The web content. After all, everything Mozilla does is about the web, and the surrounding UI is just the necessity to enable everyone to enjoy it.

As I wrote earlier this year, this opened up the possibility for accessibility for Firefox for Android. All previous efforts described had no, or only a little, chance to become accessible. But since the rewrite, since October 2011, the accessibility team, with the help from the mobile team, has managed to make Firefox for Android accessible to blind and visually impaired users on all versions of Android we support, including Android 4.1/4.2 Jelly Bean, with the recent release of Firefox 17 to the Google Play Store.

This, along with the fact that the accessibility module has test coverage, are probably the two biggest goals I have helped the project to accomplish. There are many others, like the accessibility of Firebug, which are definitely worth mentioning, but these are the two I consider most valuable for the project. The test coverage helped us strengthen our over-all module so that it nowadays is rock-solid and can support all the platforms we need it to. The different platform-dependent layers are also getting stronger, with Windows and Android probably being the most stable, with Linux following close behind.

And this brings me to the one thing that I consider the most problematic part of my work: OS X. While it does have basic VoiceOver support now, since version 16 even enabled by default, it’s still not nearly as good as it should be, certainly not nearly as good as Safari is on the Mac. In the last five years, I managed to drive only small improvements. While each of these is a great success in itself, it still needs a lot of attention.

There are other things that worry me, too, but those are not under my direct influence, but take several organizations to complete. WAI-ARIA 1.0, for example. It was almost at a recommendation level when I started five years ago, and it still hasn’t reached the 1.0 stage yet. Things are dragging and dragging, and it sometimes feels like this thing will never see the 1.0 release. I’m convinced that it will, eventually, but this is probably the longest release cycle I’ve been involved more or less heavily ever!

In the last five years, i also ventured out into different other areas. In 2011, a dedicated accessibility team was formed at Mozilla, which now consists of six members in total. I moved from the QA team to this accessibility team, and while QA is still the most important part of my work, it’s not the only one any more. I am also overseeing which of our work needs backporting to the Aurora and Beta branches, and work with release management to make this as smooth as possible for everyone, communicating what is needed and why. With not everybody as fluent in accessibility as our team is, communication is key to success here.

Speaking of “accessibility literacy”: I’m happy to see that over-all awareness of accessibility requirements has spread widely throughout the Mozilla project. I’ve always been available across all teams for questions and input on accessibility matters. While in the beginning, this was mostly me being proactive in reaching out to others and plant the seeds, I’m nowadays being pinged from everywhere and anywhere within the massively grown organization on matters and projects. This is absolutely awesome!

As for the outlook on 2013, the one big exciting piece is going to be Firefox OS. This is a project that will be our companion at work for quite some time to come. And here, it’s not just going to be reactively adding accessibility to something that’s already there, but actively designing, implementing and testing new interaction models while taking the Mozilla platform to its own level of an operating system. I’m excited as hell, my brain is continually super-charged with ideas, and I can’t wait to talk about first results on this blog!

Also, Firefox OS work will involve a lot of evangelism with web app developers to make sure they have the right tools and documentation to deliver accessible Firefox OS aps and provide a seamless experience for all their potential users.

Let’s rock!