A few months ago, in "UI Fail: How Our User Interfaces Help to Ruin Lives" (https://lauren.vortex.com/archive/001112.html), I discussed the many ways that modern Web and app interfaces can be frustrating, useless, and even painful for vast numbers of users who don't fit the "majority" category for which app and Web designers tend to build their user interfaces.

This doesn't just include rapidly growing population segments such as older users, but pretty much anyone without perfect vision and motor skills, or involving the many varying levels of literacy, or slow and unreliable Internet connectivity. It's a long, long list.

The topic is in focus again with the introduction of Google's new version of Google+, which so far, frankly, is an accessibility disappointment, in key respects seemingly moving backwards.

However, the G+ redesign is not my focus for today, since it is currently opt-in (and easily opt-ed out later if desired) and is very much a work in progress as the G+ team receives user feedback. There have already been some associated improvements in that regard, and I hope to see more. So a detailed discussion of the new G+ UI can wait for now.

What can't wait are the overall problems of how user interfaces can easily create accessibility problems and resultant discrimination against vast numbers of users and potential users.

This is by no means a Google-only problem -- it cuts across the entire Internet industry.

And in most cases it's not a purposeful decision to discriminate -- it's the natural outgrowth of mostly relatively young persons (who else could keep up with the coding loads fueled mainly by strong coffee!?) who build interfaces that they believe will well serve the "bulk" of their users.

Of course, at the scale of these companies, those users outside that "bulk" can represent hundreds of millions of individuals who can be easily left behind, users who in many cases could most benefit from these technologies.

An obvious question one might ask is why aren't there usually options on these interfaces to serve different kinds of users? Why not an option for higher contrast text? Or for easier scanning by audio screen readers, or larger targets for mouse clicking?

The short answer is that in many quarters of our industry, options per se are something of an anathema, to be avoided whenever possible.

Interface designers tend to feel that with enough effort and study data, they can create a singular interface to serve everyone (or at least, everyone they feel really matters at the moment).

What's more, options do add complexity of their own to UIs -- potentially confusing to users -- and can make code maintenance more difficult and expensive.

Yet "universal" interfaces are increasingly showing their fundamental limitations.

Do we need to invent some sort of new technology to solve this problem?

No.

Because the solution, while not a panacea in and of itself, already exists.

That solution is the A-P-I: Application Programming Interface.

Simply put, APIs are mechanisms through which programs and systems permit other programs and systems access to various of their internal functions.

APIs already keep much of the Net running, one way or another.

A visit to Google's API Explorer (https://developers.google.com/apis-explorer") yields a long list involving ads, maps, email, files, security, content, and much more -- all of which exist to permit third parties to write software that can access key aspects of Google systems and then read/write/process/display settings and data in direct conjunction with those third-party systems.

By now you likely see where I'm leading.

If stable, supported user interface API access were available for services like Google+ -- and the many other firms' systems around the Net that currently put users at an accessibility disadvantage -- it would be possible for third parties (commercial, nonprofit, individuals, etc.) to write their own customized interfaces for these services to meet specific accessibility needs.

Visually enhanced high contrast interfaces? An interface much easier for someone with limited motor skill acuity? There are a vast range of possibilities for customized interfaces to help an enormous number of users, all of which could operate via the same essential kinds of API mechanisms.

Without APIs, such customized interfaces are usually impractical. Attempts to create customization based on "screen scraping" and techniques like page display CSS modifications are subject to potentially breaking at any time, whenever the underlying format or structure of displayed pages are altered.

You must have stable user interface APIs to make this work.

And you can also probably guess why APIs for user interfaces are often resisted by firms.

Such APIs have to be built and maintained, and kept compatible as their mainstream interface and backend systems evolve and change.

There's also some loss of control. What's emphasized on a page. Where ads are placed (and how easily ads might be blocked). What's shown? What's hidden? Does any given API-based interface actually make things easier or more confusing for any given user? Can API-based interfaces be leveraged to falsify data or enable scams?

So the calculus around all this is decidedly nontrivial.

But these are all solvable issues, given the will and resources to do so. User interface API guidelines and usage standards can be promulgated. Methodologies for the inspection and certification for such API-based UIs are relatively straightforward to postulate.

One thing is certain. These accessibility issues must be solved. The status quo is increasingly untenable, leaves enormous numbers of persons in the dark, and potentially invites both litigation and heavy-handed regulatory actions.

Universal "one size fits all" user interfaces are no longer acceptable from the major Web players.

Properly designed and managed, APIs provide us with a practical and potentially highly fruitful way forward.

Let's get to work.

--Lauren--
I have consulted to Google, but I am not currently doing so.
My opinions expressed here are mine alone.