On Hidden Accessibility in Software Design

What I really want to talk about is the issue of accessibility in an age where we tend to take data for granted at a systemic and developmental level, and the trade offs that we make in accessibility in order to achieve a given level of data availability and consistency, and why web structures tend to translate so terribly to mobile and desktop app design, but before I can really do that well I have to first talk about what accessibility is in the first place.

Usually when we talk about accessibility, we talk about it in the context of disability or physical handicap, or lump it together as An Annoying Thing To Do Later, mostly for some small subset of the population that we don't ever really think about. This is, generally speaking, a very dumb way of thinking about things, and the narrow conflation of accessibility = disability is probably the biggest reason that we let Accessibility with a capital A go to heck while still pretending that we really do care about users, or that of course UX is important, or that if I don't notice anything then no one else will either.

And so while "lowercase a" accessibility is ultimately concerned with the (usually physical) ability of the users to experience stuff, "capital A" Accessibility looks at all the ways that an experience actually delivers value to its users, in turn allowing us as developers and designers to make smarter decisions in building out better experiences. And it turns out that our software delivers value in a lot of ways. And yes, some of it relies on the physical ability of our users, but it also relies on a bunch of other really really obvious stuff that's maybe so obvious that we somehow ignore it entirely.

Hardware-level Accessibility

Hardware requirements, for one, seem like something that modern software development processes have more or less abandoned completely. When was the last time you saw a list of hardware requirements for anything? Twenty years ago, when software was sold on disks, came in boxes, and was sold in real life stores, the list of hardware requirements lived in its own comfortable real estate on the bottom right corner of the back cover. Now, most software companies couldn't care less about what the minimum hardware requirements for their products are, because shame on you for having anything else but the latest generation of smartphone. The irony of today is that as the gap of technology widens at an increasing pace, so does the apparent refusal of software companies to address this gap as a real limitation in writing software, and subsequently, in capital A Accessibility. In all likelihood, the real reason why that 7-year old phone feels slower than you remember is because modern software is written exclusively for and tested on modern hardware and was never really meant to be accessible from older hardware at all, and so the luxury of all that extra power they've managed to squeeze into chips in the past 7 years is pretty much taken for granted.

Protocol-level Accessibility

Another oft-overlooked aspect of Accessibility, and a bit closer to what I really want to talk about with regards to native app architecture, is accessibility at the protocol level. Steve Yegge touches on it here in his legendary Google Platforms Rant, but it turns out that maintaining accessibility of your systems to, and from, other systems (and even from within your own system) is super important.

In many cases, we default to building for web accessibility because we know that users need to be able to access our software from browsers, but protocol-level accessibility doesn't, and shouldn't stop there. Building out an RSS feed for your blog is an example of this protocol-level accessibility, because it takes a stance on how your users are actually interacting with your systems. Does your backend need to be accessible to other servers or services? Great. Then your RESTful APIs are another form of protocol-level accessibility. Obviously not every product needs to supply all of these forms of access, but until we can recognize the importance and ubiquity of the need for broader discussion and intelligent design around these different aspects of accessibility, we won't be able to address the problems at large within the way we build good software.

Now, for the record, I'm not advocating for somehow turning up every possible Accessibility knob to 100, whatever that means. My main point with all this discussion around accessibility is to point out that the decisions we make as developers exist with a set of inherent tradeoffs, and that recognizing the full extent of these tradeoffs when we make decisions is incredibly important.

Resource-level Accessibility

The last type of accessibility I want to talk about here is what I'm going to call resource-level accessibility, but to be honest I'm not exactly sure what to call it. Even more specifically, I'm talking about data accessibility, or considering what happens when data, and/or other resources, are limited. In a web app, we can reasonably assume that our users have access to some form of data, because the app itself is served over some data connection. But what about mobile apps? This is what I was alluding to in the beginning of this post, but assuming that mobile apps always have access to data is not an assumption we can make with the same reliability as on the web. The real problem arises when we build mobile apps the same way that we build web apps, relying on assumptions of data availability, because when these assumptions are untrue, mobile apps stop working in situations where they could work but good accessibility prevents them from doing so.

More technically, mobile apps whose core functionality is contingent on data connections in order to synchronize remote data sources are making a decision to prioritize consistency over availability. In cases where consistency of data or retaining some strict order of sequential operations is important, this is definitely the way to go. But there's also about a million mobile apps out there that abuse this kind of design pattern, and that I suspect are only built this way to reuse REST APIs or lazily wrap an existing web app for mobile publication.

As a casual example, I recently downloaded a handful of mobile apps for logging running/cycling routes as part of competition research for some client work. Most of them have associated web apps as well, but the problem is that almost none of these mobile apps allow you to actually save any entries unless you're connected to the internet and their outgoing POST requests are cleared. This is fine for the web apps, but an absolutely trash design for a mobile counterpart. By restricting app functionality to a data connection, these apps are essentially taking the stance that the availability of core features to the user is secondary to figuring out how to sync data sources on the backend.

Granted, simply requiring a data connection is much easier from a technical level than having to figure out how to synchronize data at large, but the main point here is that these app developers sacrifice accessibility, and therefore, good user experience, to get there. There is really no excuse for building a running app that requires users to start and end their runs in places with a good data connection instead of saving data locally and syncing when available, and I'm convinced that the only way this happens by deliberately ignoring user experience and reusing prebuilt web architectures and minimal effort.